Re: [Tsvwg] ECN-nonce changes after London
Neil Spring <nspring@cs.washington.edu> Thu, 04 October 2001 20:36 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24566 for <tsvwg-archive@odin.ietf.org>; Thu, 4 Oct 2001 16:36:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03406; Thu, 4 Oct 2001 16:26:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03374 for <tsvwg@optimus.ietf.org>; Thu, 4 Oct 2001 16:26:30 -0400 (EDT)
Received: from poplar.cs.washington.edu (poplar.cs.washington.edu [128.95.2.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24415 for <tsvwg@ietf.org>; Thu, 4 Oct 2001 16:26:24 -0400 (EDT)
Received: from nspring by poplar.cs.washington.edu with local (Exim 3.22 #1 (Debian)) id 15pF4d-0004Qu-00; Thu, 04 Oct 2001 13:26:27 -0700
Date: Thu, 04 Oct 2001 13:26:27 -0700
From: Neil Spring <nspring@cs.washington.edu>
To: tsvwg@ietf.org
Subject: Re: [Tsvwg] ECN-nonce changes after London
Message-ID: <20011004132626.A16965@cs.washington.edu>
References: <20010910101753.A15633@cs.washington.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20010910101753.A15633@cs.washington.edu>
User-Agent: Mutt/1.3.18i
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: tsvwg@ietf.org
I thought I should re-post this call for comments on the ECN-nonce before asking Allison to start working group last call. thanks, -neil -- At the TSVWG meeting in London, the following issues were brought up about draft-ietf-tsvwg-tcp-nonce-01 to be addressed before working group last call: 1) Fragmentation text was unclear; partially redundant with draft-ietf-tsvwg-ecn-04. 2) That the ECN-nonce is optional was unclear: you can implement ECN without the nonce. 3) Note that senders can decide not to send ECN-capable packets if the receiver doesn't return nonce sums. To re-cap the highlights of the presentation, the following issues that will not be handled in the draft were also raised (feel free to correct me if I misunderstood): 1) A request was made for an enumeration of ways that ICMP filtering has thwarted the DF bit and the good that could come from Path-MTU discovery. It was agreed that this is outside the scope of the ECN-nonce draft. 2) Christian would like a proof (or at least simulation results to support) that the ECN-nonce works under the standard IP service model assumptions of loss, reordering and duplication. Pointers or help with this would be appreciated, though folks keep telling me the proof shouldn't be hard. Finally, the specter of TCP re-segmenting middle-boxes making ULP framing more difficult suggested some text to specify sender behavior when acknowledgements do not match original transmission boundaries. I believe that a re-segmenting TCP proxy has sufficient state to engineer proper receiver behavior. However, I'm wary of specifying the behavior of such a device in this draft, so only sender behavior is specified. A small, slightly edited 'diff -u' between the troff for draft-...-01 and the updated version is below. Lines prefixed '-' were removed, '+' were added, and lines without a prefix are unchanged. The edited version, for those of you who don't read diff or haven't read the draft, is available at: http://www.cs.washington.edu/homes/nspring/papers/draft-ietf-tsvwg-tcp-nonce-01b.txt Comments are welcome on any aspect of the draft. thanks, -neil --- draft-ietf-tsvwg-tcp-nonce-01.troff Mon Aug 13 09:32:47 2001 +++ draft-ietf-tsvwg-tcp-nonce-01b.troff Tue Aug 28 15:11:50 2001 @@ -54,9 +54,9 @@ .ti 0 Abstract -This note describes the ECN-nonce, a modification to ECN +This note describes the ECN-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network @@ -322,6 +322,9 @@ packets arrive and return the current nonce sum in each acknowledgement. Receiver behavior is otherwise unchanged from [ECN-draft]. +Returning the nonce sum is optional, but recommended, as +senders are allowed to discontinue sending ECN-capable packets +to receivers that do not support the ECN-nonce. As packets are removed from the queue of out-of-order packets to be acknowledged, the nonce is recovered from the @@ -479,6 +482,14 @@ The sender should ignore the nonce sum returned on any acknowledgements bearing the ECN-echo flag. +When an acknowledgment covers only a portion of a segment, +such as when a middlebox resegments at the TCP layer +instead of fragmenting IP packets, the sender should accept +the nonce sum expected at the next segment boundary. +In other words, an acknowledgement covering part of an +original segment will include the nonce sum expected when +the entire segment is acknowledged. + Finally, in ECN, senders can choose not to indicate ECN capability on some packets for any reason. An ECN-nonce sender must resynchronize after sending such ECN-incapable @@ -493,7 +504,9 @@ The sender's response to an incorrect nonce is a matter of policy. It is separate from the checking mechanism and does -not need to be handled uniformly by senders. +not need to be handled uniformly by senders. Further, +checking received nonce sums at all is optional, and +may be disabled. If the receiver has never sent a non-zero nonce sum, the sender can infer that the receiver does not understand the @@ -547,16 +560,13 @@ .ti 0 7.1 Path MTU Discovery -Because a receiver could reconstruct the original nonce from -unmarked fragments to conceal a mark on a fragment, senders -SHOULD set the Don't Fragment bit and use Path MTU -discovery. This contrasts with [ECN-draft], which says that -ECN-capable packets MAY have the DF bit set. Some senders -may not be able to use Path MTU discovery successfully because -ICMP messages are blocked by middle-boxes on the return path. -The ECN-nonce cannot protect against misbehaving receivers -that receive marked fragments, so some protection is lost by -disabling Path MTU discovery. +As described in [ECN-draft], use of the Don't Fragment bit with +ECN is recommended. Receivers that receive unmarked +fragments can reconstruct the original nonce to conceal a +marked fragment. The ECN-nonce cannot protect against +misbehaving receivers that conceal marked fragments, so some +protection is lost in situations where Path MTU discovery is +disabled. When responding to a small path MTU, the sender will retransmit a smaller frame in place of a larger one. _______________________________________________ tsvwg mailing list tsvwg@ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg
- [Tsvwg] ECN-nonce changes after London Neil Spring
- Re: [Tsvwg] ECN-nonce changes after London Neil Spring