Subject: [quicwg/base-drafts] Negotiate use of timestamps in ACK frame (#774)

From: janaiyengar <[email-masked]>
Date: Tue, 12 Sep 2017 21:46:03 +0000 (UTC)

@huitema points out (and I agree with him) that timestamps serve an optional purpose, and probably ought to be treated as an extension that is negotiated. 

A receiver could simply set num_timestamps to 0 (as someone noted earlier) effectively making it optional anyways. Having an explicit negotiation upfront means that a sender might be able to choose a congestion controller based on this information, rather than trying to figure out what to do in case this information isn’t available later.

We could also use a separate frame for timestamps.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/774

---

From: janaiyengar <[email-masked]>
Date: Tue, 12 Sep 2017 23:52:39 +0000 (UTC)

Recording here that @martinduke also suggested using a separate frame for timestamps on the mailing list.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/774#issuecomment-329016955

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Sep 2017 03:59:19 +0000 (UTC)

Yes, I indeed said that. In fact, "negotiating timestamps" is not a binary yes-no question. It is important to state what time stamps to send, and for what purpose. So far, I have heard three such purposes:

* Estimating one way delays, which is useful in delay based congestion algorithms;

* Estimating the max reordering delay, which is an important parameter of RACK style retransmission 
   algorithms;

* And, estimating the "bunching" of packets that may occur in the network.

It is not clear to me that these three usages require the same set of timestamps. One way delay measurements would probably do OK with just adding to the ACK the timestamp of the largest acknowledged packet. Max reordering estimation would require adding the timestamp of the 
max out-of-order packet. Bunching estimation leaves me puzzled, but I am sure there can be 
a simple rule for selecting which stamps to send. In any case, we must do the clarification work before
mandating time stamps.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/774#issuecomment-329052352

---

From: ianswett <[email-masked]>
Date: Mon, 18 Sep 2017 16:14:33 +0000 (UTC)

Negotiating timestamps sounds good to me, though I'd hope we can agree on one format for most use cases.

I can see the use case for requesting only 1 timestamp per ack frame vs requesting one timestamp for every newly acked packet.

I would really like to keep timestamps(and ECN when it's added) as parts of the ack frame because it's much more challenging to implement congestion control if the information arrives in sequence(even in different packets) instead of at the same time.  Timestamps in particular are closely related to the acked packets, and given we'll likely want to support multiple ack frames in a single packet in the future, having multiple ack frames and multiple timestamp frames would become really complex.

It does make acks 'more complex' but the overall complexity is lower.

Timestamps are already forbidden from unprotected ack frames, so it should be simple enough to negotiate timestamps and only use them post-handshake.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/774#issuecomment-330274043

---

From: martinduke <[email-masked]>
Date: Tue, 19 Sep 2017 13:15:11 -0700

I believe the separate timestamp frame only makes sense if we take Subodh's
idea of making timestamps an implicit ack. It is somewhat strange to
include a bunch of ack blocks when the timestamps contain all the new
information.

At one of these meetings, we're going to have to have a thorough discussion
about timestamps, and if the full-scale design is frequently (or ever)
worthwhile. Personally, I haven't done much with the timestamps and have no
strong opinion on it.

On Mon, Sep 18, 2017 at 9:14 AM, ianswett <[email-masked]> wrote:

> I can see the use case for requesting only 1 timestamp per ack frame vs
> requesting one timestamp for every newly acked packet.
>
> I would really like to keep timestamps(and ECN when it's added) as parts
> of the ack frame because it's much more challenging to implement congestion
> control if the information arrives in sequence(even in different packets)
> instead of at the same time. Timestamps in particular are closely related
> to the acked packets, and given we'll likely want to support multiple ack
> frames in a single packet in the future, having multiple ack frames and
> multiple timestamp frames would become really complex.
>
> Timestamps are already forbidden from unprotected ack frames, so it should
> be simple enough to negotiate timestamps and only use them post-handshake.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/774#issuecomment-330274043>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AXRMERxBaWv7uAJ2vEjM3ovD_zdp4O92ks5sjpbpgaJpZM4PVTN0>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/774#issuecomment-330660198

---

From: janaiyengar <[email-masked]>
Date: Tue, 19 Sep 2017 14:34:27 -0700

Per-packet timestamps *may* be useful, which is why it makes sense to make them negotiable. Christian lists some use cases above, and we are planning to use it the BBR congestion controller to separate forward path delay variance from reverse-path. This is useful for delay-based congestion controllers in general.

Ian's point about receiving congestion control information "in sequence" instead of all at once has convinced me that having a separate frame would actually hurt, so I'm on board with having it be part of the ACK frame.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/774#issuecomment-330680339