Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-end ECNandedge-to-edge ECN
Sally Floyd <floyd@icir.org> Fri, 18 November 2005 13:42 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6Vy-0004kN-1W; Fri, 18 Nov 2005 08:42:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecy0g-000216-JU; Thu, 17 Nov 2005 23:38:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20288; Thu, 17 Nov 2005 23:37:28 -0500 (EST)
Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcyIR-0008LN-G9; Thu, 17 Nov 2005 23:56:24 -0500
Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id jAI4bpmr059278; Thu, 17 Nov 2005 20:37:52 -0800 (PST) (envelope-from floyd@cougar.icir.org)
Message-Id: <200511180437.jAI4bpmr059278@cougar.icir.org>
To: Georgios Karagiannis <karagian@cs.utwente.nl>
From: Sally Floyd <floyd@icir.org>
Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between end-to-end ECNandedge-to-edge ECN
Date: Thu, 17 Nov 2005 20:37:51 -0800
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-Mailman-Approved-At: Fri, 18 Nov 2005 08:42:52 -0500
Cc: tsvwg@ietf.org, nsis@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Sender: nsis-bounces@ietf.org
Errors-To: nsis-bounces@ietf.org
Just a note about DCCP's use of ECN: DCCP uses ECN by default with both of the currently-defined congestion control mechanisms, CCID2 and CCID3, unless the end-nodes negotiate the connection as being ECN Incapable. The use of ECN Incapable is "NOT RECOMMENDED". From Section 12.1 of draft-ietf-dccp-spec-11.txt: "ECN incapability both avoids ECN's possible benefits and prevents senders from using the ECN Nonce to check for receiver misbehavior. A DCCP stack MAY therefore leave the ECN Incapable feature unimplemented, acting as if all connections were ECN capable." That is, the current ECN Nonce is useful to the sender in checking for receiver misbehavior, in terms of not reporting dropped packets, even in an environment where none of the routers are ECN-capable. This is described in Section 9 of draft-ietf-dccp-ccid3-11.txt. - Sally http://www.icir.org/floyd/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis