Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split)
"Christian Huitema" <huitema@huitema.net> Wed, 26 October 2016 17:31 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2399B129BF4 for <quic@ietfa.amsl.com>; Wed, 26 Oct 2016 10:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVe0zy41SbYA for <quic@ietfa.amsl.com>; Wed, 26 Oct 2016 10:31:00 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1D8129BF0 for <quic@ietf.org>; Wed, 26 Oct 2016 10:31:00 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1bzS2U-0007Zw-Ti for quic@ietf.org; Wed, 26 Oct 2016 19:30:59 +0200
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bzS2E-0000ww-49 for quic@ietf.org; Wed, 26 Oct 2016 13:30:57 -0400
Received: (qmail 31471 invoked from network); 26 Oct 2016 17:30:40 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ianswett@google.com>; 26 Oct 2016 17:30:40 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Ingemar Johansson S' <ingemar.s.johansson@ericsson.com>, 'Ryan Hamilton' <rch@google.com>
References: <DBXPR07MB35198069351E83CC0BE9014C2AB0@DBXPR07MB351.eurprd07.prod.outlook.com> <CAJ_4DfQZw3dOjutqxbtOcAut_iM4FVbYEh2EUNsE9XbPChHiWw@mail.gmail.com> <DBXPR07MB351274DBBCBD2FA7655D83BC2AB0@DBXPR07MB351.eurprd07.prod.outlook.com>
In-Reply-To: <DBXPR07MB351274DBBCBD2FA7655D83BC2AB0@DBXPR07MB351.eurprd07.prod.outlook.com>
Date: Wed, 26 Oct 2016 10:30:32 -0700
Message-ID: <01de01d22fae$aae5fd60$00b1f820$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJTvvtNddwsWfPUrqYmx9pI+hNh5gHR9U4MAdLzP4afmrOQMA==
Content-Language: en-us
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD7uZ KMJk9LiVgPPkshSRLnLde0HWylRewVJRNXBiyUOcdcmtTcWSOKD5RASVzg27in97Vz6IRLbhBYyX 7lr6B6d5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdbNYJZHmTztvoh1m9SAwL4/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokd0uMbDf1yoqZkUeJni0+RQZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVKnG+eTs8kbKBy2XcsLzqKfmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV6YO2/mqpOb7Q80SeXyngcEZA0ovkdUHlhxng/6M5IV+I73x9yTpqy088VxyqIsKLEe bp9tI6dJK7GvNGOBzee8
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.234
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.17)
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gO1FuL8os-f70BwXow2csNdMBEA>
Cc: 'Ian Swett' <ianswett@google.com>, 'Kyle Rose' <krose@krose.org>, 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>, 'Jim Roskind' <JimRoskind@gmail.com>, 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, 'Jana Iyengar' <jri@google.com>, quic@ietf.org
Subject: Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2016 17:31:02 -0000
On Wednesday, October 26, 2016 10:10 AM, Ingemar Johansson wrote: > That was interesting. > I probably need some pen and paper exercise to figure out how good synchronization > one can get this. If it is within 20-30ms (rough figure) then it can be useful. Otherwise > it can still be useful as it can help to remedy for instance late comers advantage and > base-delay inflation issues that is a known problem for LEDBAT. If an implementer really feels ambitious, there is enough information in the ACK to run an NTP style algorithm and compute skew and lag. That will drive the precision in the millisecond range. Of course, that's not really necessary for any practical purpose. The receiver measured ACK delay is quite sufficient. -- Christian Huitema
- [QUIC] QUIC ACK frames and one-way transfer time … Ingemar Johansson S
- Re: [QUIC] QUIC ACK frames and one-way transfer t… Ryan Hamilton
- Re: [QUIC] QUIC ACK frames and one-way transfer t… Ingemar Johansson S
- Re: [QUIC] QUIC ACK frames and one-way transfer t… Christian Huitema
- Re: [QUIC] QUIC ACK frames and one-way transfer t… Ted Hardie