[Tsvwg] (no subject)

Bob -

Here is some feedback on your email:

>Just confirmation that you've got rough agreement on draft-03 from me.
>Hence I'm sending this to the list, not to the IESG in response to their
>last call.
>
>It's rough, because 
>1/ On marking behaviour, I don't actually agree with the way the router
>behaviour is described, embedding 'mark=drop' in your implementation
>suggestions. IMHO, the prediction that future research might change things
>is too vague to warn implementors how to protect themselves from future
>changes per diffserv class. But it's your document, so such questions of
>emphasis are yours to decide.

We have to disagree on this one.  To my mind, the equivalence of
marking and dropping for the default ECN semantics, in terms of the
congestion control response of the end nodes, is the key contribution
of RFC 2481 and of this draft.  See more about this below.

>2/ On non-compliance, the argument that non-compliant use of ECN is no more
>of a problem than for discard is wishful thinking, in my opinion. I
>explained at IETF-50 initial ideas on a 'drop=drop' scheme that would fix
>this and is particularly suited for real-time (and hence mostly UDP)
>buffer-starving diffserv classes. But, let's give 'mark=drop' a shot for
>TCP and see if non-compliance becomes a problem.

I don't think we said that "non-compliant use of ECN is no more
of a problem than for discard".  That is not how Section 7 reads to me.

>3/ On fragmentation, I don't understand why 'SHOULD set DF' has been
>demoted to 'MAY set DF', and I'm not fully convinced that a few badly
>configured fire-walls that prevent path MTU discovery are sufficient reason
>not to say 'MUST set DF'. But, I don't really care about this strongly
>enough to argue, as it's implementors that will suffer the extra complexity
>and so if they're not fighting, I'd better shut up.

The argument made in the Working Group was that one does not need a reason
to say MAY instead of SHOULD;  instead, one needs a strong reason if
one is going to say SHOULD instead of MAY.  I agree with this.

>Arguments 1 & 2 need an academic paper from us. Then, if we convince
>everyone, we have a way to change ECN later in specific diffserv classes.
>But we need to move ECN on now, despite this. Hence, rough concensus.
>
>I just read through the whole thing in one sitting to check for
>inconsistencies given the recent fiddling around with it. I found some bugs
>you might want to change with the RFC editor (don't think we need another
>last call to do this?, but two of the inconsistencies I've found might?,
>unfortunately). 
>
>Details:
>
>Bugs
>----

Many thanks, we will try to take care of all of these bugs in the
final changes with the RFC editor.  None of these should delay the
progress to Proposed Standard.

>Lack of clarity 
>---------------
>(We can live with these, but if you go to draft 04 for other reasons,
>consider these).

We will see if we can add the clarifications in the final changes
with the RFC editor.

>p18 Sec 6.1.2 & section 6.1.3: Is it valid to refer to academic papers
>[Floyd94] and [Floyd98] for the fine details of an IETF standard?

I think this is OK, since those references do not specify any
standards, but are just illustrative.  (It is a little borderline,
I agree, since [Floyd98] illustrates the following:  "Some care is
required if the TCP sender is to avoid unnecessary reductions of
the congestion window when a window of data includes both dropped
packets and (marked) CE packets."  But I think it is OK not to
include all of the detail from [Floyd98] in this document.  We didn't
say the sender MUST NOT have any unnecessary reductions of the
congestion window...)

>Self-inconsistencies
>--------------------
>(But I know what you probably mean, so others should too, however the first
>two really do need to be resolved.)
>
>p2: "...all the mechanisms specified here are incrementally deployable."
>p24 sec 9.1: 
>  "When ECN
>   becomes widely deployed, then simple tunnels likely to carry ECN-
>   capable traffic will have to be changed."
>p37 sec 12:
>  "All IP tunnels MUST implement one of the two alternative approaches
>   described above."

We can rephrase p37 sec 12 to the following:
"To be compliant with this standard, all IP tunnels MUST implement one
of the two alternative approaches described above."
That seems clear to me.

>Section 5 mandates the behaviour of ECN-capable transports in general, but
>section 6 says "This document only addresses the addition of ECN Capability
>to TCP..."
>  "Upon the receipt by an ECN-Capable transport of a single CE packet,
>   the congestion control algorithms followed at the end-systems MUST be
>   essentially the same as the congestion control response to a *single*
>   dropped packet."
>(Also repeated for emphasis at the start of section 5.1).
>I suggest you use the phrase "...transports that are TCP-compatible ...
>MUST...".
>If you really did mean to be this draconian for *all* transports, I would
>object strongly.

We mean this, for the default semantics of ECN.  This is in Section 5, 
and does not apply only to TCP.  For TCP and for other congestion
control mechanisms, such as equation-based congestion control or
multicast congestion control, the congestion control response to
a packet mark MUST be essentially the same as the congestion control
response of that congestion control mechanism to a single dropped
packet.  This is the key to RFC 2482, and to this draft, that these
are the default semantics of ECN.  And, in my opinion, this is the
key to ECN having made it this far in the standards track, is that
there was a clear default semantics for the ECN indication, namely,
do what you would have done, in terms of congestion control, if
the packet had been dropped.

However, a separate diff-serv class would be free to define alternate
semantics for ECN for that diff-serv class, but that is not addressed
in this document, except for the one paragraph about Differentiated
Services Per-Hop Behaviors in Section 5.

>Section 5.2 (picky):
>  "...the congestion response of the end nodes to a dropped data packet is
>   at least as strong as the congestion response to a received CE
>   packet."
>If being picky, this implies the response to CE may be stronger than to drop.

Nope, but I agree that this could be clarified.  An example of when
the congestion response to a dropped packet is *stronger* than the
congestion control response to a marked packet is in TCP, for a
congestion window of two packets, without Limited Transmit.  The
congestion control response to a dropped packet might be a retransmit
timeout, while the congestion control response to a marked packet
might only be the halving of the congestion control window.

>p12 sec 5.2 "..."pure" ACK packets MUST NOT indicate ECN-Capability..."
>p19 sec 6.1.4 "...pure acknowledgement packets ... should be sent with the
>not-ECT codepoint"
>I assume this latter is strictly a MUST.

Yep.  We will do this.

>p22 sec 7:
>  "We argue that the addition of ECN to the IP architecture will not
>   significantly increase the current vulnerability of the architecture
>   to unresponsive flows."
>p35 sec 10:
>  "We recommend that any "penalty box" ... 
>   first change from marking to dropping packets"
>If it's not advantageous to mark, why is switching to dropping a
>punishment? Oops! This is rather fundamental - as I said, we'll attack this
>in the research community - no need to resolve now.

I don't think we said that it isn't advantageous to mark.  We only
argued that ECN "will not significantly increase the current
vulnerability of the architecture to unresponsive flows."  It seems
clear to me.

>p54 sec 20.2:
>  "The assignment of the fourth ECN codepoint to ECT(1) precludes the
>   use of this codepoint for other purposes."
>Strictly, the multicast use should be separately listed, as it is not
>precluded - it can be made compatible.

We will leave this to be addressed in a later document.

>Final thought
>-------------
>Would it be sensible to use a next draft, if there is one, to set aside one
>of the TCP reserved bits for ECN nonce experiments? 

This is being addressed in draft-ietf-tsvwg-tcp-nonce-00.txt.

- Sally

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
http://www1.ietf.org/mailman/listinfo/tsvwg