Re: [tcpm] ECN and synCookie

["Scheffenegger, Richard" <[e-mail]>]

Hi Krishna,

as the exact way how a Syn-Cookie is formed is an arbitrary choice by the server doing this, I don’t see that this couldn’t be achieved. Also, it doesn’t need any standards action.


Changing the Semantics of the TCP ECN handshake however, would change the semantics; I’m one of the co-authors of the AccECN drafts, where a different signaling is to be defined. The point you make has not yet brought forward as a requirement to be included in http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-04. But as we have not yet settled on any specific encoding to go with these requirements, something along the lines below could probably be easily added.

For example, what you ask would probably be easy to implement both with http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-02 and http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option-01 .

You may also look into the work here http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-01 to see how it could interact.


As a side note, even within RFC3168, your (active open) client would have two (non-standard) options to convey the use of ECN again back to the (passive open) server. One would be to set the ECT(0) or ECT(1) codepoint in the ACK – though RFC1368 doesn’t allow that on pure ACKs; the other one would be to signal CWR in the pure ACK. However, as both approaches are not specific (and the use of ECT on pure ACKs may have other implications for the network), you cann’t rely on the server to react properly.

Of course, any data segment from the client to the server would legitimately contain ECT(0), ECT(1) or CE, and the server could “late” enable ECN support after receiving such a segment, if the session was set up using Syn-Cookies. Up to that point (the first ECN-marked segment from the client), the server could send regular, non-ECN segments, and I think such a session would be fully compliant – just not make use of ECN until the first indication of ECN from the client…


Best regards,

Richard Scheffenegger


From: tcpm [mailto:[e-mail]] On Behalf Of Krishna Khanal
Sent: Donnerstag, 28. November 2013 06:28
To: [e-mail]
Subject: [tcpm] ECN and synCookie


A server with synCookie support generally replies the important options received on SYN from
client on its SYN+ACK packet to client after encoding it in its ISS. Since the number of options
exchanged in SYN are growing, there are some alternate ways to remember this, like echoing
the options in timestamp so that it can be offloaded from ISS.

One of the option exchanged in handshake is ECN. When a server receives a SYN with ECE+CWR
set, it replies with ECE. if server has synCookie enabled, it must remember this on ISS as well.

What about echoing back the ECE option on final ack? If client receives SYN+ACK with ECE, it can
set ECE on final ack and send it to server.

With this, there are two advantages:
1. no need to encode the ECN capability on syncookie
2. if the path is asymmetric (though path can change anytime), client can inform server about it,
if the ECE is not set on final ack, server can ignore ECN even if its enabled.

Were there any discussions in the past on this? Does this make any sense?

Regards,
Krishna