Re: CONEX? (was: Re: Q and L loss bits)

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

> On 21 Nov 2019, at 15:23, Lubashev, Igor <[e-mail]> wrote:
> 
> A few things about the ConEx vs QL-lossbits
> 
> 1. ConEx has a mechanism that is similar to L-bit (we mention ConEx RFC7713 in the draft).  But it has no equivalent of the Q-bit signal.  It is very hard to tell upstream loss from downstream loss with ConEx.

Yep, at least when I talk about this proposal I mean "replace L with ConEx". We can leave Q as it is. (The question as to the independent utility of Q and L is a separate discussion).

> 2. ConEx reports bytes, while QL-loss reports packets.  There is a trade-off here, as bytes may be more valuable, but reporting bytes can be imprecise, if the packets marked are of different size from the packets lost.  Overall, both work well enough.

IIRC ConEx spent an inordinate amount of time on the bytes versus packets bikeshed so let's not :)

> 3. ConEx requires more bits than what we have in QUICv1, so it would be a significant disruption to QUICv1 header format to properly implement all ConEx bits.  The Q- and L- bits are enough for the purpose.

What I'd like to look at is a one-bit encoding for L that exposes the same signals ConEx did. It turns out this might be about the same thing as L as currently defined when L doesn't count losses determined to be spurious. 

> 4. CWR is an interesting signal, and I actually have a separate CWR bit (I call it "E-bit") in https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-02#section-5 -- the -tsvwg- version of the draft.  However, it is not very closely related to loss for networks with ECN.

This raises the other question: whether what we really want to measure is "this packet is lost" (which network operations activities use loss as an indication of lower-layer issues they need to fix) or "this packet caused the transport difficulty" (which is more of an indication of endpoint-visible performance, interesting to a different department in network operations). Or, "if a packet is dropped in the woods, and nobody cares about it, does it make a sound?"

On most networks with most deployed CC algorithms these generate basically the same metric, so the distinction is maybe philosophical. It is less true for nonelastic traffic and for newer CC algorithms.

Cheers,

Brian

>  On an ECN-capable network for ECN-capable flows, downstream loss would become indistinguishable from downstream congestion that marks CE.  Ultimately, it seemed that given just two bits to work with, Q-bit plus a pure loss bit seemed preferable to Q-bit plus "loss-or-CE_echo" bit.  But I am happy to discuss this!
> 
> - Igor
> 
>> On Thu, Nov 21, 2019 at 2:44 PM, Brian Trammell (IETF) <[e-mail]> wrote:
>> 
>> hi Lars,
>> 
>> This is kind of where I was going with the "expose CWR-like semantics for loss"
>> thing; "just do conex" is a much better shorthand for that.
>> 
>> Thanks, cheers,
>> 
>> Brian
>> 
>>> On 21 Nov 2019, at 14:42, Lars Eggert <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm wondering whether specifying a CONEX mapping for QUIC would satisfy
>> the needs that quic-lossbits attempts to address? We could reuse an existing
>> piece of IETF work.
>>> 
>>> See https://tools.ietf.org/html/rfc7713 for an overview and
>> https://tools.ietf.org/html/rfc7786 for the TCP mapping.
>>> 
>>> Lars
>>> 
> 
>