Negotiate use of timestamps in ACK frame

[janaiyengar]

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

[janaiyengar]

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

[huitema]

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.

[ianswett]

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.

[martinduke]

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 notifications@github.com wrote:

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

[janaiyengar]

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.

[IngJohEricsson]

I have found ACK timestamps quite useful, these makes it possible to implement LEDBAT style congestion controls, which we believe can be useful for e.g. low priority transport in wireless access. It is however not strictly necessary to have a timestamp for each and every packet in the ACKs. In addition I don't see either that a floating point representation is necessary.

[ianswett]

There was fairly strong consensus at the Seattle interim that timestamps should be negotiable in some way and when they are present, should be part of the QUIC ack frame.