Subject: A more nuanced QUIC timestamp extension negotiation

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 4 Aug 2020 11:06:04 -0400

Hello Christian,

I propose to change the timestamp extension [1] negotiation from a
simple boolean TP, meaning that both end will send and receive
TIMESTAMP frames, to some variant where each endpoint can express
its interest in TIMESTAMP frames:

    a) I would like you to send TIMESTAMP frames
    b) I can generate TIMESTAMP frames if you'd like
    c) (a) and (b)

The example here is lsquic [2]:  It can generate TIMESTAMP frames if
it is useful to its peer (such as picoquic), but it does not use the
information in incoming TIMESTAMP frames.  The annoying part is when
both endpoints are lsquic and they generate and exchange useless
TIMESTAMP frames!

  - Dmtiri.

1. https://tools.ietf.org/html/draft-huitema-quic-ts-02
2. https://lsquic.readthedocs.io/en/v2.19.3/apiref.html#c.lsquic_engine_settings.es_timestamps

---

From: Christian Huitema <[email-masked]>
Date: Tue, 4 Aug 2020 08:27:16 -0700

Yes, that make sense. Timestamps are useful if the congestion control algorithm uses them. That's the case for delay based protocols like LEDBAT or throughput based protocols like BBR, not so much for loss based or ECN based protocols.

-- Christian Huitema 

> On Aug 4, 2020, at 8:06 AM, Dmitri Tikhonov <[email-masked]> wrote:
> 
> Hello Christian,
>