Re: [tcpm] ECN and synCookie

[Krishna Khanal <[e-mail]>]

Thanks Richard for the details and these link to the drafts.


On Thu, Nov 28, 2013 at 4:11 PM, Scheffenegger, Richard <[e-mail]>wrote:

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