Subject: Re: [tcpm] A possible simplification for AccECN servers

From: Bob Briscoe <[email-masked]>
Date: Thu, 12 Dec 2019 16:37:01 +0000

Richard,

On 28/11/2019 11:34, Scheffenegger, Richard wrote:
>
> Hi,
>
> I support the new text that Bob has suggested to allow a AccECN server
> to choose to not support RFC3168 ECN.
Can you give reasons - I'm trying to understand what to do given 
conflicting preferences.

>
> I also support Rod's suggestion to replace references to "classic" ECN
> with RFC3168 ECN.
Ditto. Reasons?

Bob
>
> However, as bob also pointed out, "ECT" is usually interpreted in the
> context of the IP header, but the AccECN draft only concerns itself with
> the TCP layer, where "ECN mode" / "non ECN mode" is the correct
> description of the state of the TCP sessions feedback...
>
> Best regards,
>   Richard
>
>
> Am 26.11.2019 um 02:49 schrieb Rodney W. Grimes:
>> tcpm'ers:
>>
>>          I believe the more common terminology is "Not ECT" (Not
>> ECN Capable Transport), rather than Non ECN.  Many new
>> instances of "Classic" has crept in with the new text, which I
>> do think we should avoid.
>>
>>          Comments inline marked [RWG].
>>
>> Regards,
>> Rod
>>
>>> Jonathan,
>>>
>>> On 24/11/2019 13:20, Jonathan Morton wrote:
>>>>> On 23 Nov, 2019, at 4:43 pm, Richard Scheffenegger 
>>>>> <[email-masked]> wrote:
>>>>>
>>>>> My reading of bob?s suggestion is
>>>>>
>>>>> Syn - accecn
>>>>> Syn-ack no ect
>>> I think Richard meant 'no ECN' at the TCP layer, rather than 'no ect',
>>> which implies the IP layer. I don't think this led to any confusion so
>>> far on the thread, but I've corrected it in case someone else gets 
>>> confused.
>>>
>>>>>
>>>>> I don?t see any problem there ;
>>>> That is indeed a valid transaction, but one which represents an 
>>>> AccECN client (that is, AE|CWR|ECE on SYN) and a Not-ECT server.  
>>>> Of course, it is also legal by protocol to request RFC-3168 ECN 
>>>> (that is, CWR|ECE without AE on SYN) with a Not-ECT server.
>>>>
>>>> What the draft currently (and correctly, IMO) forbids is for an 
>>>> AccECN server to downgrade RFC-3168 clients to Not-ECT. I don't see 
>>>> any reason for allowing this, because the difference in code 
>>>> complexity must be very small, and the benefit to the RFC-3168 
>>>> supporting clients which are ubiquitous today (even if they don't 
>>>> always advertise it) in terms of avoiding packet loss and 
>>>> retransmissions just for the sake of a congestion signal is 
>>>> significant.
>>> I also "don't see any reason for allowing this", but that isn't what
>>> motivates text in RFCs. If there is no interoperability reason to
>>> disallow such a downgrade, then we should not disallow it.
>>>>
>>>> It does appear that I missed part of Bob's proposal through trying 
>>>> to read it on a phone at the airport.  It made me think that he was 
>>>> proposing that AccECN *clients* might not support RFC-3168 as 
>>>> well.  I now see that he was proposing this only for servers.  I 
>>>> still think this is wrong-headed, but it technically doesn't break 
>>>> the protocol on the wire.
>>> Yes, that's my point.
>>>
>>> If it doesn't break the protocol, it's not up to the IETF to tell
>>> implementers what is "right-headed". The two examples I gave are
>>> possible valid reasons an implementer might have (but even if no-one
>>> could think of a valid reason now, there's no need to preclude this):
>>> i) a cut-down lightweight TCP implementation
>>> ii) an implementer wishing to rationalize the server code she has to
>>> maintain when, in the long term future (recall that RFCs last for ever)
>>> AccECN might have become pervasive and 3168 ECN hardly ever seen.
>>>
>>> Here's how I propose to alter the text:
>>>
>>> CURRENT:
>>>
>>>      3.  The third block shows the cases where the TCP server (B) 
>>> supports
>>>          AccECN but the TCP client (A) supports some earlier variant of
>>>          TCP feedback, indicated in its SYN.Therefore, as soon as an 
>>> AccECN-enabled TCP server (B) receives the SYN
>>> shown, it MUST set both its half connections into the feedback mode
>>> shown in the rightmost column.
>>>
>>>
>>> PROPOSED:
>>>
>>>      3.  The third block shows the cases where the TCP server (B) 
>>> supports
>>>          AccECN but the TCP client (A) supports some earlier variant of
>>>          TCP feedback, indicated in its SYN.When an AccECN-enabled 
>>> TCP server (B) receives a SYN from a client in
>>> classic ECN feedback mode (AE,CWR,ECE = 0,1,1) it SHOULD set both its
>>
>> classic -> RFC3168
>>
>>> half connections into the classic ECN feedback mode as shown in the
>>
>> ditto
>>
>>> rightmost column and return a SYN-ACK as shown (AE, CWR, ECE = 0,0,1).
>>> The "SHOULD" allows for the unlikely case where a server might not wish
>>> to implement classic ECN. When an AccECN-enabled TCP server (B) 
>>> receives
>>
>> Ditto
>>
>>> a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set 
>>> both
>>
>> No ECN -> Not ECT
>>
>>> its half connections into the No ECN feedback mode as shown in the
>>
>> No ECN -> Not ECT
>>
>>> rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).
>>>
>>>
>>> Bob
>>>>
>>>>    - Jonathan Morton
>>>
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe http://bobbriscoe.net/
>>>
>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 12 Dec 2019 18:00:11 +0100

> Can you give reasons - I'm trying to understand what to do given

I think it is not unreasonable to leave the decision, if a particular
server chooses to not fall back to ECN, if an RFC3168 client asks for
ECN support, to the deployer of the server.

By itself, ECT0 can already be seen as a classifier (we've had this
discussion with L4S and ECT1). In this light, non-ECT vs ECT0 (or ECT1)
can end up in different queues. If the server operates in an environment
that doesn't lend itself to good interoperability with RFC3168 ECN, the
server might want to not run ECN at all with a RFC3168 client. Thus
preferring to operate in loss-only congestion feedback rather than a
potenial problematic ECN feedback.

While at the same time, it may want to utilize the full potential when
in a session with another AccECN client...

>> I also support Rod's suggestion to replace references to "classic" ECN

This is mostly semantics and possible conotations of the prose-term
"classic". When I followed the discussion around this, it appeared to me
that while this is not objectable to native speakers, non-native english
speakers may have a different set of conotations attached to specific words.

In this context, RFC3168 is as neutral and specific as it can get. Thus
it appears to me, that this would be less contended reference.

Hope this helps.

Richard

---

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 15 Dec 2019 19:14:31 +0000

> it appears to me, that this would be less contended reference.

The TCPM chairs also got a (private) note from the TSVWG chairs that "RFC3168-ECN" is their preferred term. Probably TCPM documents should use the terminology preferred by TSVWG for ECN.

Does TCPM really need to run a formal consensus call on this kind of terminology?

Michael