Subject: [tcpm] A possible simplification for AccECN servers

From: Bob Briscoe <[email-masked]>
Date: Sat, 23 Nov 2019 19:27:48 +0800

tcpm-ers, Mirja, Richard,

draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled 
server MUST support both classic ECN and non ECN. However, that's not 
actually necessary for interoperability. Certainly, when an AccECN 
server receives a non-ECN-setup SYN, it MUST fall back to a 
non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone 
object if we change it from MUST to SHOULD respond with an ECN-setup 
SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?

Potential reasons for a server only supporting AccECN and non-ECN (which 
we can put in the draft):
* lightweight server to minimize code complexity;
* to allow for the possibility that AccECN clients might one day have 
widely replaced classic ECN, and some servers might choose to remove 
their classic ECN code to save having to maintain it.

FYI, the other way round, no such simplification of the client is 
possible. 'Cos there's no space for an AccECN SYN to say "I support 
AccECN but not ECN". So the client has to be able to support all three 
(AccECN, Classic ECN and non-ECN).

Bob

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

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 23 Nov 2019 16:06:54 +0200

I believe that taking advantage of such a provision would result in a
violation of RFC-3168, as seen by a server supporting that specification
but not AccECN.

If I happen to be wrong about that, could you explain how the server gets
to know that the connection has reverted to Not-ECT mode after sending a
SYN-ACK confirming RFC-3168 support in response to a valid RFC-3168 SYN?

- Jonathan Morton

---

From: Neal Cardwell <[email-masked]>
Date: Sat, 23 Nov 2019 15:16:03 -0500

> SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?

I think removing that MUST and replacing with SHOULD or MAY is an
important change. Many servers are situated in datacenter networks
where the datacenter switches are CE-marking using shallow-threshold
DCTCP-style ECN. I don't see a way for such servers to feasibly
participate in classic/RFC-3168 ECN, because to do so would risk
interpreting shallow-threshold DCTCP-style CE marks as deep-threshold
classic/RFC-3168 CE marks, causing overreaction to the CE marks and
thus poor performance.

For servers in such networks it seems important to preserve the option
to participate only in non-ECN, DCTCP-ECN, and L4S-ECN conversations,
and decline classic/RFC-3168 ECN conversations.

best,
neal

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 24 Nov 2019 07:20:15 +0200

> 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 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.

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.

I should point out here that datacentres are a special case - a contained environment in which it is permissible to bend certain rules for the sake of performance, in ways that would not be acceptable for Internet traffic.  I think this is one of these cases, like DCTCP itself.

 - Jonathan Morton

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Sun, 24 Nov 2019 19:55:11 +0100

Yes i think a tcp server in a DC accepting only accecn (possibly w/ option to switch to dctcp style reflection), and no-ect does make sense.

There is gear deployed already, which ONLY supports shallow ce marking - which breaks 3168 entirely. Behind such a switch, a server would be better off going only with non-ect (no ecn at all), or accecn. So that state transition should be allowed (and i think it is) by the accecn draft.

(Non-ect is classified into a different Q on the one example i could name, so no q sharing w/ drop class cc)

Gesendet mit der GMX Mail App

Am 24.11.19 um 06:20 schrieb Jonathan Morton

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Sat, 23 Nov 2019 15:43:18 +0100

Syn - accecn
Syn-ack no ect

The handshake is only complete (and the server continues to use ip ect in the final ack), if the client responded by either non-ect synack(ae/esce =0, cwr=0, ece =0), a rfc3168 
Synack(ae/esce=0, cwr=1, ece=0), or one of the four synack accecn codepoints;

The only violation would be a server trying an ecn++ / accecn handshake with a ect0/ect1 marked syn...

Am i missing something?

Richard

Am 23.11.19 um 15:06 schrieb Jonathan Morton

---

From: Neal Cardwell <[email-masked]>
Date: Mon, 25 Nov 2019 10:21:27 -0500

On Sun, Nov 24, 2019 at 12:21 AM Jonathan Morton <[email-masked]> wrote:
> I should point out here that datacentres are a special case - a contained
> environment in which it is permissible to bend certain rules for the sake
> of performance, in ways that would not be acceptable for Internet traffic.
> I think this is one of these cases, like DCTCP itself.

IMHO it is worth emphasizing that much of the traffic that travels
over the public Internet is sent by servers that are situated in
datacenter networks where the datacenter switches are CE-marking using
shallow-threshold DCTCP-style ECN. So that "datacenter traffic" and
"public Internet traffic" are, in some sense, overlapping categories,
rather than disjoint categories.

neal

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 25 Nov 2019 16:46:14 +0100

Hi all,

Replying to Bob initial message because I have another point.

I need to double-check what the exact context of the sentence Bob mentions below is in the accECN draft but probably this should not be a normative requirement in this draft at all. I’m actually further not sure what exactly is meant with “support” in that sentence, but the question if a server replies to a RFC3168 SYN with an RFC3168 SYN-ACK is solely a question for RFC3168 and not AccECN.

Mirja

> On 23. Nov 2019, at 12:27, Bob Briscoe <[email-masked]> wrote:
> 
> draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled server MUST support both classic ECN and non ECN. However, that's not actually necessary for interoperability. Certainly, when an AccECN server receives a non-ECN-setup SYN, it MUST fall back to a non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone object if we change it from MUST to SHOULD respond with an ECN-setup SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?
> 
> Potential reasons for a server only supporting AccECN and non-ECN (which we can put in the draft):
> * to allow for the possibility that AccECN clients might one day have widely replaced classic ECN, and some servers might choose to remove their classic ECN code to save having to maintain it.
> 
> 
> 
> FYI, the other way round, no such simplification of the client is possible. 'Cos there's no space for an AccECN SYN to say "I support AccECN but not ECN". So the client has to be able to support all three (AccECN, Classic ECN and non-ECN).
> 
> 
> 
> 
> Bob
> 
> 
> 
> --

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 25 Nov 2019 18:35:03 +0200

> On 25 Nov, 2019, at 5:46 pm, Mirja Kuehlewind <[email-masked]> wrote:
> 

As far as I can tell, the requirement is not worded precisely as Bob put it, but is implied in Section 3.1.1:

   +--------+--------+------------+-------------+----------------------+
   | A      | B      |  SYN A->B  |   SYN/ACK   | Feedback Mode        |
   |        |        |            |     B->A    |                      |
   +--------+--------+------------+-------------+----------------------+
   |        |        | AE CWR ECE |  AE CWR ECE |                      |
<snip>
   | Nonce  | AccECN | 0   1   1  |  0   0   1  | classic ECN          |
   | ECN    | AccECN | 0   1   1  |  0   0   1  | classic ECN          |
   | No ECN | AccECN | 0   0   0  |  0   0   0  | Not ECN              |

[...]

   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.

> rather than disjoint categories.

I imagine that any individual flow going out to the general Internet would occupy only a small fraction of a datacentre switch's capacity on any given link, and so would be unlikely to trigger CE marking even with a basic shallow threshold marking policy.  If it did, that would suggest that the link is indeed at capacity, and a reduction of send rate is therefore justified to avoid subsequent packet loss from the tail of the queue.

It is also, strictly speaking, a violation of RFC-3168 to apply differing policies for CE marking on ECT packets versus dropping Not-ECT packets, in this case by using the ECN field as a traffic classifier.  That a performance problem then arises when RFC-3168 traffic passes through an RFC-ignorant AQM is perhaps unsurprising.  Again, this sort of thing is acceptable in a closed and carefully controlled environment, but what is described here is not.

Absent such special interests, I think the existing language (quoted above) is correct.

 - Jonathan Morton

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 25 Nov 2019 17:43:54 +0100

Hi Jonathan,

I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode. 

Even if you implement classic ECN or AccECN, you can of course always configure your machine to not use ECN. So for me that is an interface question which we don’t address in the draft.

Mirja

> On 25. Nov 2019, at 17:35, Jonathan Morton <[email-masked]> wrote:
>

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 25 Nov 2019 18:48:09 +0200

> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <[email-masked]> wrote:
> 

I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:

>       Therefore, as soon as an

 - Jonathan Morton

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 25 Nov 2019 18:02:05 +0100

Hi Jonathan,

Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me. 

Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.

Mirja

> On 25. Nov 2019, at 17:48, Jonathan Morton <[email-masked]> wrote:
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 25 Nov 2019 17:12:15 +0000

Jonathan,

>> My reading of bob’s suggestion is
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.

> 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 com…
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…
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 
half connections into the classic ECN feedback mode as shown in the 
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 
a SYN from a client in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both 
its half connections into the No ECN feedback mode as shown in the 
rightmost column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0).

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 25 Nov 2019 21:41:58 +0000

Mirja,

> Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.
In the spec of AccECN, it's necessary and reasonable to state normative 
requirements for a node "that is AccECN-enabled". That doesn't mean that 
an AccECN implementation has to always support AccECN - it can always 
disable AccECN. But we do have to say what it is expected to do if it is 
following the AccECN protocol.

This draft has included that normative language for the negotiation 
phase in all 16 revisions since the first individual draft (that you 
wrote!).

The table shows only cases where one end or the other is AccECN-capable, 
and the text preceding and following the table gives normative 
requirements solely for the AccECN node(s) in those cases. It doesn't 
give any normative requirements for non-AccECN nodes.

In block 3, the server is AccECN capable, so in the AccECN spec. it's 
perfectly reasonable to say what it ought to do in response to various 
types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 
the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.

The only case that is in question, AFAIC, is whether we have to say what 
an AccECN-capable server does in response to a SYN from an RFC3168 
client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can 
respond with a SYN-ACK that is either RFC3168 or non-ECN.

I just proposed respectively SHOULD and MAY, but I can now see there is 
no need to make that judgement call. However, it is still important to 
say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).

It's also important that the spec defines all three bits in the SYN-ACK 
responses, not just the 2-bits defined in RFC3168 - so that the 
combinations with AE=1 are ruled out and therefore remain available for 
future use.

Bob

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 26 Nov 2019 10:02:35 -0800

Hello,

> On Nov 25, 2019, at 9:12 AM, Bob Briscoe <[email-masked]> wrote:
> 
>  Jonathan,
> 
>> 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 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.
>> 
> 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):
> 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.
> 
>        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 half connections 
>        into the classic ECN feedback mode as shown in the 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 a SYN from a client 
>        in No ECN mode (AE,CWR,ECE = 0,0,0) it MUST set both its half 
>        connections into the No ECN feedback mode as shown in the rightmost 
>        column and return the SYN-ACK shown (AE,CWR,ECE = 0,0,0). 

I support this proposed change for all the reasons that have been outlined by Bob and Neal.

Christoph

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 26 Nov 2019 11:49:53 -0800 (PST)

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

> >> My reading of bob?s suggestion is
> >>
> >> Syn - accecn
> >> Syn-ack no ect
> >> I don?t see any problem there ;

classic -> RFC3168 

> half connections into the classic ECN feedback mode as shown in the 

ditto

> 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

-- 
Rod Grimes                                                 [email-masked]

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 28 Nov 2019 12:34:32 +0100

Hi,

I support the new text that Bob has suggested to allow a AccECN server
to choose to not support RFC3168 ECN.

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

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