Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Jonathan,

On 11/11/2021 00:21, Jonathan Morton wrote:
>> On 8 Nov, 2021, at 4:52 pm, Holland, Jake <jholland=[e-mail]> wrote:
>>
>> The current text, as far as I can tell, does not *require* any attempt
>> to detect problems due to "legacy queue" issues (only "SHOULD" language
>> here, I think?), and then makes the safety response of failing over to
>> classic CC conditional on "detecting problems".  Certainly if there is
>> a "MUST" or "SHALL" requirement, it's hard for me to nail down exactly
>> where.
>>
>> As has been discussed, without some quite complex detection efforts,
>> detection of problems is a major challenge with this technology, and
>> thus the current text overall seems too weak to me on this point.
>>
>> IMO, the docs need to make it clear that sending with this technology
>> comes with a mandatory duty to look for and respond to likely problems
>> caused to other senders due to the non-backward-compatible signaling
>> response.
> During Monday's session, I noted that L4S does not meet the requirements of RFC-4774 Option 3, and that this is not merely a matter of minor compromises from the letter of the definition.  Without having followed every single entry in this thread, I'd like to highlight the above as illustrative of what I meant.
>
> The very fact that L4S transports have a need to detect problems and respond to them by falling back to a compatibility mode is directly characteristic of RFC-4774 Option 2.  The fact that they cannot presently do so with any reasonable level of reliability places them in RFC-4774 Option 1.  Option 3 requires that friendly coexistence with conventional traffic (both ECT and Not-ECT) is inherent to the system, not merely a mode that is explicitly switched into.
>
> I do not believe that L4S can comply with RFC-4774 Option 3 without a fundamental redesign, starting with the signalling method.

[BB] RFC4774 was written at a time (2006) when FQ hadn't even been 
considered. And it was still believed that single-queue Classic RFC3168 
ECN AQMs (which were largely synonymous with RED at the time) would 
become widely deployed. It is now widely believed that all or nearly all 
the current and near-future RFC3168 deployments are likely to be FQ. FQ 
bottlenecks inherently address the coexistence problem, apart from the 
cases of VPNs and hash collisions. Your interpretation of RFC4774 
doesn't take this likelihood into account.

Because RFC guidance can be context dependent, David Black asked us to 
write down where L4S does not follow previous RFCs like 4774 literally, 
and to explain why not.
See 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-22#section-4.3.1



Bob

>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/