Re: [tsvwg] Review comments on a careful read of the L4S ID (#1: ABE)

[Michael Welzl <[e-mail]>]

Hi,

A comment below:

> On May 14, 2021, at 11:46 AM, Bob Briscoe <[e-mail]> wrote:
> 
> David, [Pls ignore previous email - had a better idea - see replacement text below]
> 
> A relevant place to refer to ABE is in S.1.3:
> 
> CURRENT:
>    This document is intended for experimental status, so it does not
>    update any standards track RFCs.  Therefore it depends on [RFC8311 <https://datatracker.ietf.org/doc/html/rfc8311>],
>    which is a standards track specification that:
> 
>    o  updates the ECN proposed standard [RFC3168 <https://datatracker.ietf.org/doc/html/rfc3168>] to allow experimental
>       track RFCs to relax the requirement that an ECN mark must be
>       equivalent to a drop (when the network applies markings and/or
>       when the sender responds to them);
> 
> PROPOSED to append:
>      For instance, an experimental ABE sender [RFC8511] responds less to ECN marks than to drops.
>      For instance, this permits an ABE sender [RFC8511] to experiment with responding less to ECN marks than to drops.

I disagree with “experiment with”. The specification is experimental, but this doesn’t entail that a sender would “experiment with responding less” - this sounds as if ABE would just specify that a reduced back-off is something cool to experiment with, and an ABE sender would then try this or that backoff, depending on their liking. That’s a misrepresentation.

Suggestion:
     For instance, this permits an ABE sender [RFC8511] to respond less to ECN marks than to drops.

I find it unnecessary to stress “experiment” again in this sentence because it describes an example of “updating the ECN proposed … to allow experimental track RFCs to … “ - i.e., it’s very clear from the context here that ABE is experimental.

Cheers,
Michael



> Regarding adding ABE to the first para of the introduction, I really don't want to go off into a side-remark right at the start.
> 
> 
> Bob
> 
> 
> On 13/05/2021 21:30, Black, David wrote:
>> Bob,
>>  
>> Let's see if we can come up with an intermediate approach that conveys useful info to the reader about ABE without endorsing it as an IETF standard.
>>  
>> Suggestion: No text changes for 1 and 22 (for 22, I agree that ABE does not affect marking), just add a sentence for 6 in the first paragraph of the Introduction that explains what ABE is/does and that ABE is an experiment.  No need to mention ABE again in the body of the draft (there's one mention in Appendix B.1).
>>  
>> Will that work?
>>  
>> Thanks, --David
>>  
>> From: tsvwg <[e-mail]> <mailto:[e-mail]> On Behalf Of Bob Briscoe
>> Sent: Thursday, May 13, 2021 2:04 PM
>> To: Gorry Fairhurst
>> Cc: [e-mail] <mailto:[e-mail]>
>> Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID (#1: ABE)
>>  
>> [EXTERNAL EMAIL]
>> 
>> See [BB]...
>> 
>> On 06/05/2021 07:52, Gorry Fairhurst wrote:
>> ================================================================= 
>> 1. Abstract needs to be corrected to accommodate ABE (RFC 8511).
>>   
>> Abstract text says:
>>    “ 'Classic' ECN marking is required to be
>>    equivalent to a drop, both when applied in the network and when
>>    responded to by a transport.”
>>   
>> ⁃           That’s no longer completely correct in light of ABE (RFC 8511), although the strong connection between this marking and reaction to drops is still the case.  Perhaps: ‘Classic’ ECN marking is an enhancement to drop-based congestion control, both when applied …
>> 
>> ================================================================= 
>> 6. Add text to acknowledge ABE (RFC 8511)
>>   
>> This text:
>>      “RFC 3168 required an ECN mark to be equivalent to a drop, both when applied in the
>>      network and when responded to by a transport.”
>> 
>> ⁃            ABE (RFC 8511) has already modified that drop equivalence.  Revise this text accordingly.
>> 
>> =================================================================
>> 22. Update to include ABE (RFC 8511)
>>   
>> This text:
>>      “   Note that, contrary to RFC 3168, a Dual Queue Coupled AQM
>>    implementing the L4S and Classic treatments does not mark an ECT(1)
>>    packet under the same conditions that it would have dropped a Not-ECT
>>    packet, as allowed by [RFC8311], which updates RFC 3168.  However, if
>>    it marks ECT(0) packets, it does so under the same conditions that it
>>    would have dropped a Not-ECT packet.”
>>   
>> ⁃            ABE (RFC 8511) has modified that drop equivalence.  Revise this text accordingly.
>> 
>> =================================================================
>> 
>> 
>> [BB] The quotes from the draft above refer to what the standards track [RFC3168] says, not RFC8311 experiments like ABE. I don't think it will be appropriate for this draft to specifically call out ABE as if it is now accepted IETF practice. That opens us to more controversy and delay if someone disagrees with the ABE experiment.
>> 
>> The quote in #22 is purely about marking in the network, which ABE doesn't change, so it's definitely not appropriate to cite ABE there.
>> 
>> The draft does refer to RFC 8511 from an informative appendix, which I think is appropriate.
>> 
>> Proposed resolution: No text changes.
>> 
>> 
>> Bob
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/ [bobbriscoe.net] <https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!zfPbqwU20-zdSS8IyP0GZ48zVTkiYuVPeCEerb_tyGCe-JXJAVzENUM6PA-5RaXE$>
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>