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

[<[e-mail]>]

On Wed, 2019-11-20 at 07:19 +0800, Christian Huitema wrote:
> I am willing to do the same in Picoquic, but I would really like to
> get
> the transport parameter defined first.

Sure, working on it :)
By the way, in what shape is the IANA registry announced for TPs ? Is
it opened yet ?

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

One way would be to just decrement the "yet unreported loss"  counter
whenever the stack decides a loss was spurious. This may when the
counter is zero, bringing it to negative values. This does not affect
the rule for setting L=1, namely that the counter be >0. This way,
assuming spurious events are a fraction of genuine ones, the total
count at the end of the connection is accurate (except for spurious
after the last genuine).

A refinement would be to somehow delay sending L=1, to let a chance to
the counter to become >=0 again. The problem being, of course, that we
can't guarantee to have enough outgoing packets before the end of a
connection, leading to underestimation of loss at the end; this may be
workable in practice, as the Q halfperiod granularity has a similar
effect for upstream loss anyway.


> 
> -- 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/0b83dfa304bcd975
> > 0b67e6297416ce493d9fb5b1
> > 
> >   - Dmitri.
> > 
> > On Tue, Nov 19, 2019 at 10:08:29AM -0500, Dmitri Tikhonov wrote:
> > > On Tue, Nov 19, 2019 at 03:49:08PM +0100, alexandre.ferrieux@oran
> > > ge.com 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
> 
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.