Subject: [Tsvwg] (no subject)

From: Sally Floyd <[email-masked]>
Date: Tue, 10 Apr 2001 14:40:02 -0700

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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Apr 2001 14:48:42 +0100

Sally,

Sorry about the slow response time - I'm on holiday really.

Thank you for clarifying things. Below, I've highlighted points where
greater clarity seems to be needed in the document. That's the only type of
criticism we have left now, from my point of view.

>of RFC 2481 and of this draft.  See more about this below.

I have no problem with this as a default. There's no real problem with the
text, other than giving implementors no clues about what non-default might
mean.

I.e, where the default isn't chosen, say for diffserv class n, parameters
for *two* queuing behaviours will need to be configurable for class n
(not-ECT and ECT). This will require a change to the user and management
interfaces for configuring the router (with the two equal by default unless
a second is specified). Without explaining this, vendors are likely to
close off any non-default flexibility, by omission rather than intent.

In practice, it just means they'll have to produce two revisions to their
OS, which is probably OK, as no-one has yet proved the need for non-default
behaviour (other than my own conjecture). 

>>2/ On non-compliance, ...

OK - you're strictly right. I just felt the emphasis was trying to gloss
over the difference. You're allowed to do that though, as, by being careful
with your wording, you haven't actually told any untruths :)

>one is going to say SHOULD instead of MAY.  I agree with this.

Reasonable.

>of the two alternative approaches described above."

Nice try :) But then you can't say "all the mechanisms *described here* are
incrementally deployable", as all tunnels have to be upgraded at once to
comply, and there is no path for non-upgraded tunnels to interwork.

At one point you say "RFC 2481 recommended that ECN not be used with the
older simple IPsec tunnels". I assume you aren't making this part of the
proposed standard because the sender rarely knows its packets are going
through a tunnel.

I think the only honest path is to amend the statement of intent on p2, to
add an exception about simple tunnels. Perhaps also add in section 9 that
network infrastructure like tunnels is expected to be upgraded before the
majority of hosts? Also that, if congestion marking is being undone by a
simple tunnel egress in the transition, a congested ECN router in the
tunnel will eventually overload and discard, thus failing safely, if not
gracefully.

>>section 6 says "This document only addresses the addition of ECN Capability
...
>and does not apply only to TCP.  
...
>This is the key to RFC 2482, and to this draft, that these
>key to ECN having made it this far in the standards track
...

I also believe this was the key factor, giving a stepping stone from where
people were to where you were going. However, I think we both agree that
the path doesn't necessarily end here. There is the potential for the
Internet to have different operating points for different types of traffic.
This must be a good thing, as it allows different efficiency/performance
tradeoffs, rather than a single mega-compromise.

>Services Per-Hop Behaviors in Section 5.

OK, I was expecting flexibility in new transport protocols. But flexibility
within transport protocols per DSCP is cool. Bit odd, and difficult to
deploy incrementally, but more consistent with the stratification of router
flexibility.

A problem to grapple with in the future though. Can't let this hold up ECN,
even though it worries me - it's not fair to hold up ECN while we think
this all through.

However, this is definitely *not* what you have said: p10 sec 5:
  "The above discussion of when CE may be set instead of dropping a
   packet applies by default to all Differentiated Services Per-Hop
   Behaviors (PHBs) [RFC 2475]."
You definitely only say you are talking about router behaviour here. It is
counter-intuitive to think that you are talking about per-DSCP host
transport behaviour as well, unless you say so. Per-DSCP host transport
behaviour is not something that is currently within most people's
understanding of normality, so they won't guess this without an explicit hint.

So this moves from being a question of inconsistency, to one of clarity -
something I assume you can also deal with at RFC editing stage.

As well as clarifying the per-DSCP default applies to hosts as well as
routers, you need to make clear that the limitation of scope to TCP doesn't
apply to section 5.

>>If being picky, this implies the response to CE may be stronger than to
drop.

Sorry I don't know what I was thinking about. Your wording allows response
to drop to be stronger than to mark, not the other way round. Ignore me. 

>Nope, but I agree that this could be clarified.  

The earlier wording says "essentially the same as", so I think you're OK.
Clarify if you want.

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

I think you've misunderstood. I'm just saying that the multicast semantics
shouldn't be in your list of incompatible proposals. It's largely compatible. 

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

OK.

----------
Thanks for your patience.

Hopefully, this last episode has been worth it - any specification  of this
length (and with so much horse-trading in its making) is bound to be very
difficult to make clear and consistent. I admire the job that has been done.

Thank you.

Bob
________________________________________________________
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor 
commercial direction of British Telecommunications plc.
________________________________________________________
Bob Briscoe      http://www.labs.bt.com/people/briscorj/