Re: [tcpm] ECN+SYN

[Stefanos Harhalakis <[e-mail]>]

On Thursday 21 February 2008, Sally Floyd wrote:
> In summary, I would be *strongly* opposed to any proposal
> for TCP SYN packets to be sent as ECN-capable.

Hello Sally and thank you for your detailed and explanatory reply!

(I'm replying to the whole mail as a whole)

  After carefully reading your mail a couple of times, re-examining 
draft-ietf-tcpm-ecnsyn-05.txt and having in mind RFC3168, I still believe 
that the draft should be modified a bit regarding the SYN+ECT case. For the 
rest of the mail I'm using the term ECT when referring to flags in IP packets 
and ECN when referring to TCP flags.

  First of all, partially in contrast with RFC3168, the draft indirectly 
suggests that ECT should be used in SYN/ACK packets as:
a) an improvement for detecting congestion a little bit earlier and starting 
with a reduced window size (smaller initial window) (p.8, bottom)
b) a method of QoS that will result in less SYN/ACK looses when operating on 
an ECN enabled network (p.5, bottom (2)) (p.7, top).

Point (a) has to do with ECN(+ECT) and (b) has to do with ECT. 

  Also, the draft:
a) Proposes ECT for SYN/ACK segments
b) Forbids ECT for SYN segments

  I argue that the exact same reasons specified in point (b) (regarding QoS) 
apply to SYN segments too. In fact, if you imagine an ECN enabled Internet 
that uses RED everywhere then the only dropped segments of a TCP session 
because of congestion may be the SYNs (!!). Also consider that loosing the 
first SYN of a session MAY result in a ECN-less connection (RFC3168 
6.1.1.1) - which increases its importance.

  I suggest that the draft:
a) Do not forbid ECT for SYN segments
b) Propose the usage of ECT for SYN segments

  Since on an ECN enabled Internet that uses AQM everywhere the ECN bits in IP 
will (most probably) also work as a kind of QoS, we should not consider ECT 
only as a congestion indication method. We should have in mind the effects of 
not using ECT which will result in poorer performance. I totally agree that 
most probably we will not benefit from congestion indication in SYN segments 
and I understand that RFC3168 explicitly says that "an ECT codepoint MUST NOT 
be set in a packet unless the loss of that packet in the network would be 
detected by the end nodes and interpreted as an indication of congestion" 
(RFC3168 5.2) but on the other hand, SYN and SYN/ACK segments are not exactly 
data (for normal operations) and (I believe that) they are only a very small 
fraction of the whole internet traffic (either as packet count or byte 
count).

  So, it may be wise and harmless to also propose in this draft that "when a 
host sends a SYN segment it MAY set the ECT codepoint to prevent intermediate 
routers from dropping it instead of marking it"

  Regarding security considerations: I fail to see why ECT+SYN may be a 
threat. Of course a malicious user may use it to prevent intermediate routers 
from dropping those packets but trying to prevent this:
a) Is not what we're doing everywhere else
b) Is like disallowing fast and reliable internet connections to prevent 
malicious users from performing SYN flooding.

  Hope that this clarifies my thoughts... and that they are not (totally) 
wrong :-)

Best regards,
Harhalakis Stefanos
_______________________________________________
tcpm mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/tcpm