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

[Christian Huitema <[e-mail]>]

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/0b83dfa304bcd9750b67e6297416ce493d9fb5b1
>
>   - 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