Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-ecn-03.txt

[Bob Briscoe <[e-mail]>]

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.

At 14:40 10/04/01 -0700, Sally Floyd wrote:
>
>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.

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, ...
>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.

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 :)

>>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.

Reasonable.

>>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.

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 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..."
...
>>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.  
...
>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
...

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.

>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.

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.

>>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.

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.

>>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.

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. 

>>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.

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/

_______________________________________________
tsvwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg