Re: [tcpm] ECN+SYN

On Feb 21, 2008, at 1:53 PM, Stefanos Harhalakis wrote:

> 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 suggest that the draft:
> a) Do not forbid ECT for SYN segments
> b) Propose the usage of ECT for SYN segments

I am sorry, but I would still be strongly opposed to this.

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

(1) The current Internet is not ECN-enabled.  In particular, most
TCP end nodes today are not using ECN.

If a new protocol was proposed that was ECN-capable from day one,
I think it would be fine for SYN packets in this new protocol to
be sent as ECN-Capable.  (Because there wouldn't be any
backwards-compatibility problems with receivers from that protocol
that didn't agree to use ECN.)

This is not the case with TCP, however.

(2) SYN packets can in fact be a factor in congestion (e.g., consider
SYN floods).

(3) If all SYN packets were sent as ECN-Capable, and routers marked
rather than dropped these SYN packets in times of congestion, and the
ECN mark was ignored by the TCP responder (because the TCP
responder was not using ECN), this could significantly increase the
level of congestion.  Even if the SYN packets themselves weren't
a significant part of the load.

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

- Sally
http://www.icir.org/floyd/

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm