Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split)

Yes, clock synchronization is an issue, but QUIC makes an attempt to deal
with it. The receipt "time" in the ACK frame is not an actual wall time,
but is instead a time delta since the connection is established. Assuming
that the clocks are moving forward at roughly the same rate, this means
that the relative skew in these deltas is the time it took for the CHLO to
reach the server, and the peers can account for this in subsequent
calculations.

On Wed, Oct 26, 2016 at 4:06 AM, Ingemar Johansson S <
ingemar.s.johansson@ericsson.com> wrote:

> Hi
>
>
>
> Ryan. You are right that the QUIC ACK frames already contains the
> necessary information to compute the one way delay. It is of course not
> possible to deduce the true one way delay unless the sender and receiver
> clocks are synchronized. What is easy to determine is the queue delay that
> can be used in a way similar to how LEDBAT does it, there are some pros and
> cons with that approach.
>
> https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/ describes
> a modification to Cubic that is based on this principle.
>
>
>
> /Ingemar
>
>
>
>
>
> *From:* Ryan Hamilton [mailto:rch@google.com]
> *Sent:* den 26 oktober 2016 06:09
> *To:* Jim Roskind <JimRoskind@gmail.com>
> *Cc:* Ian Swett <ianswett@google.com>; Kyle Rose <krose@krose.org>;
> Christian Huitema <huitema@huitema.net>; Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com>; marcelo bagnulo braun <marcelo@it.uc3m.es>;
> Jana Iyengar <jri@google.com>; quic@ietf.org
> *Subject:* Re: [QUIC] Drafts structure and split
>
>
>
>
>
>
>
> On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind <JimRoskind@gmail.com> wrote:
>
> On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett <ianswett@google.com> wrote:
>
> ...
>
> It's worth noting that BBR is only a change to the congestion controller,
> ....
>
>
>
>
>
>
>
> BBR relies on getting estimates of transit time, so as to estimate
> variations in buffer sizes.  As a relatively rough estimate, I believe BBR
> in TCP relies on traditional-TCP RTT calculations, which includes the round
> trip sum of transit times in both directions.  I expect that better one-way
> transit time estimates can be harvested in QUIC, by changing the data
> included in ACK frames to better illuminate transit times in each
> directions (or more precisely, illuminate changes, from one packet to the
> next, in one-way transit times).
>
>
>
> Correct me if I'm wrong, but QUIC ACK frames already have this
> information. The contain the arrival time of each packet at the peer, which
> provides the one-way transfer time.
>
> 
>
>
>
>  Such modifications appear at first blush to be notably larger than just a
> change to the congestion controller.
>
>
>
> Similarly, I'd expect modifications to support ECN in QUIC to run much
> deeper than a congestion controller.
>
>
>
> Jim
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>