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

["Brian Trammell (IETF)" <[e-mail]>]

Hi Igor, all,

Sent from my iPhone

> On 20 Nov 2019, at 07:56, Lubashev, Igor <[e-mail]> wrote:
> 
> 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)

FWIW I agree that these are the right semantics.

With these semantics, if I follow correctly, the L bit is basically signaling that the sender has detected a loss _to which it will react_ (or rather, to which it would react if it were already network limited), by reducing the congestion window, updating its loss estimate or capacity model, or whatever sending-rate-relevant parameters its congestion control and avoidance scheme uses. 

This makes the condition it is signaling pretty close to the CWR bit (if the CWR bit covered all such reactions, not just those triggered by ECN), which is basically the proposal I (poorly and cryptically) alluded to in the issue and the mic.

(Two nice properties of exposing loss reaction as opposed to raw loss: one, you’re closer to measuring what you actually care about — poor transport performance — and two, since the signal is correlated with the time series of the sending rate, statistical techniques are applicable to verifying the signal: it’s harder to lie.)

Cheers, B

> "
> 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
> 
>