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

[Bob Briscoe <[e-mail]>]

Michael,

On 14/05/2021 11:07, Michael Welzl wrote:
> Hi,
>
> A comment below:
>
>> On May 14, 2021, at 11:46 AM, Bob Briscoe <[e-mail] 
>> <mailto:[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.

[BB] I am being asked to stress the status of experimental drafts.
I agree with your point about "experiment with" tho, so I'll take a 
middle line:

     in the ABE experiment [RFC8511] this permits a sender to respond 
less to ECN marks than to drops


Bob

>
> 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]> *On Behalf Of * Bob Briscoe
>>> *Sent:* Thursday, May 13, 2021 2:04 PM
>>> *To:* Gorry Fairhurst
>>> *Cc:* [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 Briscoehttp://bobbriscoe.net/ [bobbriscoe.net]  <https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!zfPbqwU20-zdSS8IyP0GZ48zVTkiYuVPeCEerb_tyGCe-JXJAVzENUM6PA-5RaXE$>
>>
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>

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