[Tsvwg] ECN-nonce changes after London

[Neil Spring <[e-mail]>]

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
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg