Re: [tcpm] ECN+SYN

Sally Floyd <sallyfloyd@mac.com> Thu, 06 March 2008 02:42 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B1E28C1B2; Wed, 5 Mar 2008 18:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.397
X-Spam-Level:
X-Spam-Status: No, score=-100.397 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBG2d3dNuGBN; Wed, 5 Mar 2008 18:42:52 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8276B28C1E1; Wed, 5 Mar 2008 18:42:52 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A18F3A69FF for <tcpm@core3.amsl.com>; Wed, 5 Mar 2008 18:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K34WRt9yaD2 for <tcpm@core3.amsl.com>; Wed, 5 Mar 2008 18:42:49 -0800 (PST)
Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.69]) by core3.amsl.com (Postfix) with ESMTP id 9CBFB3A686F for <tcpm@ietf.org>; Wed, 5 Mar 2008 18:42:49 -0800 (PST)
Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout006/MantshX 4.0) with ESMTP id m262gdFC003913; Wed, 5 Mar 2008 18:42:39 -0800 (PST)
Received: from [192.168.1.85] (adsl-70-132-4-244.dsl.snfc21.sbcglobal.net [70.132.4.244]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m262gaTh027238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2008 18:42:37 -0800 (PST)
Message-Id: <F897DCB4-90B6-4BCB-B248-642B225C1035@mac.com>
From: Sally Floyd <sallyfloyd@mac.com>
To: Stefanos Harhalakis <v13@v13.gr>
In-Reply-To: <200802212353.09084.v13@v13.gr>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 5 Mar 2008 18:42:37 -0800
References: <200802200116.26451.v13@v13.gr> <AD614F47-6972-468C-B679-1ADA288B5C2C@mac.com> <200802212353.09084.v13@v13.gr>
X-Mailer: Apple Mail (2.919.2)
Cc: akuzma@northwestern.edu, tcpm@ietf.org
Subject: Re: [tcpm] ECN+SYN
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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