Re: [tcpm] A possible simplification for AccECN servers

[Jonathan Morton <[e-mail]>]

> On 25 Nov, 2019, at 5:46 pm, Mirja Kuehlewind <[e-mail]> wrote:
> 
> 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.

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.

Now considering Richard's and Neal's points:

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

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

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