Re: [tcpm] A possible simplification for AccECN servers

[Bob Briscoe <[e-mail]>]

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 
>>>>> <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>

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