Re: [tcpm] Thank you for the QUIC session in tcpm

[Yoshifumi Nishida <[e-mail]>]

On Thu, Nov 8, 2018 at 4:37 PM Yuchung Cheng <ycheng=
[e-mail]> wrote:

> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <[e-mail]> wrote:
> >
> > I just wanted to thank Jana for explaining QUIC loss recovery to us (and
> QUIC CC as far as it goes).
> > And thank you Jana, Ian, the chairs of both WGs (and anyone else
> involved) for setting it up.
> >
> > If one is not full-time on QUIC, it's very difficult to keep up with all
> the changes. But now we have a checkpoint to start from, I feel I will not
> be wasting people's time if I try to get involved - at least I only might
> say something un-QUIC occasionally, rather than nearly always. This has
> allowed people who understand how TCP cold be improved to help with QUIC,
> when working on QUIC isn't their day job.
> >
> > Again, Thank you.
> I like particularly that QUIC only reduces cwnd to 1 after the loss is
> confirmed not upon RTO fires. It should be very feasible for TCP (at
> least Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd
> reductions!
>

+1

>
> Also IMHO TCP w/ quality timestamps are almost as good as QUIC
> pkt-ids. Google internally uses usec. We wish we could upstream it but
> RFC needs to be updated.
>

I agree using timestamp for the purpose.
But, if we try to utilize the TS like pkt-id, I personally think it'll be
similar to use it as extend seqno like draft-bagnulo-tcpm-esn-00 rather
than fine grade TS. :)

In any cases, it seems to me that many people think 7232 TS is not being
very efficient for today's internet.
it might be good time to think about extending TS option just like what
we're doing on ECN..  TS++?
--
Yoshi