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

[Bob Briscoe <[e-mail]>]

David,

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.

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 Briscoe                               http://bobbriscoe.net/