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