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

[Ingemar Johansson S <[e-mail]>]

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.

/Ingemar

From: Ryan Hamilton [mailto:[e-mail]]
Sent: den 26 oktober 2016 15:47
To: Ingemar Johansson S <[e-mail]>
Cc: Jim Roskind <[e-mail]>; Ian Swett <[e-mail]>; Kyle Rose <[e-mail]>; Christian Huitema <[e-mail]>; Spencer Dawkins at IETF <[e-mail]>; marcelo bagnulo braun <[e-mail]>; Jana Iyengar <[e-mail]>; [e-mail]
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: den 26 oktober 2016 06:09
To: Jim Roskind <[e-mail]<mailto:[e-mail]>>
Cc: Ian Swett <[e-mail]<mailto:[e-mail]>>; Kyle Rose <[e-mail]<mailto:[e-mail]>>; Christian Huitema <[e-mail]<mailto:[e-mail]>>; Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>; marcelo bagnulo braun <[e-mail]<mailto:[e-mail]>>; Jana Iyengar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [QUIC] Drafts structure and split



On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/quic


_______________________________________________
QUIC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/quic