RE: Q and L loss bits: which is which?

["Lubashev, Igor" <[e-mail]>]

Christian, I actually thought about this, and decided that the recommendation is not to decrement L counter.  It is in the -tsvwg- version of the draft but somehow did not have it into the -quic- version (keeping two versions in sync is apparently hard), sorry. (https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-02#section-3.2)

"
If the protocol is able to rescind the loss determination later, the Unreported Loss counter SHOULD NOT be decremented due to the rescission.
"

I thought this rule would limit the confusion of the observer who is trying to correlate Q and L bits. I'm happy to hear alternative opinions on this.

- Igor

> -----Original Message-----
> From: Christian Huitema <[e-mail]>
> Sent: Wednesday, November 20, 2019 7:19 AM
> To: [e-mail]; IETF QUIC WG <[e-mail]>
> Subject: Re: Q and L loss bits: which is which?
> 
> I am willing to do the same in Picoquic, but I would really like to get the
> transport parameter defined first.
> 
> Also, I would like some clarification. The loss counter is supposedly
> incremented using Quic's loss detection machinery, but the loss detection
> mechanism sometimes err on the false positive side. This is detected if an ack
> arrive late for a packet that was supposed lost, and the loss is classified as
> spurious.
> 
> Any guidance on how to handle spurious loss detection?
> 
> -- Christian Huitema
> 
> On 11/20/2019 3:26 AM, Dmitri Tikhonov wrote:
> > I added a loss bits server on
> >
> >     http3-test.litespeedtech.com:4440
> >
> > Feel free to give it a shot!
> >
> > Both lsquic server and client can be compiled with loss bits support
> > by doing
> >
> >     EXTRA_CLFAGS=-DLSQUIC_LOSS_BITS=1 cmake ....
> >
> > The code is on a branch for now:
> >
> >
> >
> https://github.com/litespeedtech/lsquic/commit/0b83dfa304bcd9750b67e62
> > 97416ce493d9fb5b1
> >
> >   - Dmitri.
> >
> > On Tue, Nov 19, 2019 at 10:08:29AM -0500, Dmitri Tikhonov wrote:
> >> On Tue, Nov 19, 2019 at 03:49:08PM +0100,
> [e-mail] wrote:
> >>> Thanks for your offer: experimentations are very welcome !
> >>> You're right we forgot to just define which is what, we'll fix the
> >>> draft shortly. We'll choose: 0x10 for Q and 0x08 for L.
> >>> This means the first byte layout becomes:
> >>>  |0|1|S|Q|L|K|P P|
> >> Thank you!
> >>
> >> I also assume that these two bits would now be outside of the header
> >> protection?  That is, the short header header protection mask [1] is
> >> now 0x7 instead of 0x1F?  This is not mentioned in your draft, but I
> >> don't see how an observer could get at those bits otherwise.
> >>
> >>   - Dmitri.
> >>
> >> 1. https://tools.ietf.org/html/draft-ietf-quic-tls-24#section-5.4.1