Re: A more nuanced QUIC timestamp extension negotiation

[Christian Huitema <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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