Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt

[Roberto Peon <[e-mail]>]

I should have known you were already on top of it, lol!
-=R

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Lubashev, Igor <[e-mail]>
Sent: Tuesday, February 11, 2020 1:04:50 PM
To: Roberto Peon <[e-mail]>; Erik Kline <[e-mail]>
Cc: Lars Eggert <[e-mail]>; HAMCHAOUI Isabelle IMT/OLN <[e-mail]>; IETF QUIC WG <[e-mail]>; [e-mail] <[e-mail]>; Dmitri Tikhonov <[e-mail]>
Subject: RE: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt


Thanks for not laughing… ??



Yes, that’s how I read the question, too.  Hence I replied: “I agree that the draft could benefit from the explanation of why we use QUIC v1 reserved header bits instead of some bits in a lower layer (or more bits outside of the header in the QUIC packet).”  And I added an issue to this effect, too (https://github.com/igorlord/draft-ferrieuxhamchaoui-lossbits/issues/37).



But, since the reasoning was, indeed, missing from the draft, I kind of summarized it after.



  *   Igor



From: Roberto Peon <[e-mail]>


Not laughing over here…

@Igor—I think the question was if we could put the reasoning into the draft!
-=R



From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Erik Kline <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 11, 2020 at 12:47 PM
To: "Lubashev, Igor" <[e-mail]<mailto:[e-mail]>>
Cc: Lars Eggert <[e-mail]<mailto:[e-mail]>>, HAMCHAOUI Isabelle IMT/OLN <[e-mail]<mailto:[e-mail]>>, IETF QUIC WG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Dmitri Tikhonov <[e-mail]<mailto:[e-mail]>>
Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt



On Tue, Feb 11, 2020 at 8:46 AM Lubashev, Igor <[e-mail]<mailto:[e-mail]>> wrote:

> From: Lars Eggert <[e-mail]<mailto:[e-mail]>>
>
> Hi,
>
> (chair hat off)
>
> the draft points to the CONEX work and says this:
>
>    This loss signaling is similar to loss signaling in [RFC7713], except
>    the Loss Event bit is reporting the exact number of lost packets,
>    whereas the Echo Loss bit in [RFC7713] is reporting an approximate
>    number of lost bytes.
>
> What it doesn't say is why the CONEX functionality is being proposed to be
> incorporated into QUIC, rather than staying at the IP level where it arguably
> belongs?

Thanks for the feedback. I agree that the draft could benefit from the explanation of why we use QUIC v1 reserved header bits instead of some bits in a lower layer (or more bits outside of the header in the QUIC packet).

The short answer is deployability.  There is no point in writing drafts that will sit on a shelf, because no one will want to deploy them for at least a decade.  CONEX is one example, plagued by the difficulty of getting IPv6 extension headers deployed.  And good luck with similar IPv4 extensions.

Hence we borrow CONEX ideas but try to implement them in a way that is still possible, while using greasing and anti-ossification techniques.

> Thanks,
> Lars

Best,
- Igor



Folks might laugh, but I think realistically we'll be looking towards UDP trailers at some point.