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

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 26 Oct 2016 11:06:59 +0000

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:[email-masked]]
Sent: den 26 oktober 2016 06:09
To: Jim Roskind <[email-masked]>
Cc: Ian Swett <[email-masked]>; Kyle Rose <[email-masked]>; Christian Huitema <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; marcelo bagnulo braun <[email-masked]>; Jana Iyengar <[email-masked]>; [email-masked]
Subject: Re: [QUIC] Drafts structure and split

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

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 26 Oct 2016 06:46:51 -0700

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 <
[email-masked]> 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:[email-masked]]
> *Sent:* den 26 oktober 2016 06:09
> *To:* Jim Roskind <[email-masked]>
> *Cc:* Ian Swett <[email-masked]>; Kyle Rose <[email-masked]>;
> Christian Huitema <[email-masked]>; Spencer Dawkins at IETF <
> [email-masked]>; marcelo bagnulo braun <[email-masked]>;
> Jana Iyengar <[email-masked]>; [email-masked]
> *Subject:* Re: [QUIC] Drafts structure and split
>
>
>
>
>
>
>
> On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind <[email-masked]> wrote:
>
> On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett <[email-masked]> wrote:
>
> ...
>
> 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.
>
> ​
>
>
>
> [email-masked]
> [email-masked]

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 26 Oct 2016 17:10:17 +0000

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:[email-masked]]
Sent: den 26 oktober 2016 15:47
To: Ingemar Johansson S <[email-masked]>
Cc: Jim Roskind <[email-masked]>; Ian Swett <[email-masked]>; Kyle Rose <[email-masked]>; Christian Huitema <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; marcelo bagnulo braun <[email-masked]>; Jana Iyengar <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi

/Ingemar

From: Ryan Hamilton [mailto:[email-masked]<mailto:[email-masked]>]
Sent: den 26 oktober 2016 06:09
To: Jim Roskind <[email-masked]<mailto:[email-masked]>>
Cc: Ian Swett <[email-masked]<mailto:[email-masked]>>; Kyle Rose <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>; Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>; marcelo bagnulo braun <[email-masked]<mailto:[email-masked]>>; Jana Iyengar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [QUIC] Drafts structure and split

Jim

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 26 Oct 2016 10:30:32 -0700

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 28 Oct 2016 09:50:19 -0700

On Wed, Oct 26, 2016 at 10:30 AM, Christian Huitema <[email-masked]>
wrote:

> 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.

My employer may have IPR that covers this approach.  I'm working with our
legal folks to get a disclosure filed.

Of course, that's not really necessary for any practical purpose. The
> receiver measured ACK delay is quite sufficient.
>
>
I agree with this; while there are cases where you might want and need
this, I don't really think this is one of them.

regards,

Ted