Subject: [Tsvwg] [Digest] ECN & diffserv

From: Bob Briscoe <[email-masked]>
Date: Thu, 08 Mar 2001 10:55:39 +0000

tsvwg,

Here's a continuation of the digest of the off-line discussions 
that went on between:
1/ two of the authors of standards track "The Addition of Explicit 
Congestion Notification (ECN) to IP" 
(draft-ietf-tsvwg-ecn-{01|02}.txt Ramakrishnan, Floyd, Black) 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-01.txt
and 
2/ the new "An Open ECN Service in the IP layer" 
(draft-ietf-tsvwg-ecn-ip-00.txt Briscoe, Crowcroft).
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-ip-00.txt

The 5 digests are:
1. Fourth ECN code-point
2. ECN & diffserv (this one)
3. ECN & fragmentation
4. IP's ECN service to other congestion control protocols
5. Summary

    DB> = David Black
    JC> = Jon Crowcroft
    SF> = Sally Floyd
    BB> = Bob Briscoe

BB>>Sally,
BB>>
BB>>At 11:58 21/02/01 -0800, Sally Floyd wrote:
SF>>>Sorry, this is the final feedback email, on Section 5.2 of your
SF>>>draft.  The ECN web page at "http://www.aciri.org/floyd/ecn.html"
SF>>>says the following, and has for quite some time now:
SF>>>
SF>>>"We welcome research about proposals for alternate uses of the ECN
SF>>>field that could be associated with different diff-serv classes of
SF>>>traffic."

BB>>I'm aware of that. But it's not said in the I-D. That's why 
BB>>I prepared words to put in there. I'm trying to help :-(

SF>>>However, I don't think that this draft is the place to address these
SF>>>issues - my assumption has been that they can be addressed in a
SF>>>separate draft.  I also think that it is not necessarily going
SF>>>to be simple and straightforward (as the default ECN turned
SF>>>out not to be simple and straightforward)...

BB>>I agree the I-D isn't the place to discuss the issues. 
BB>>I was giving examples of the issues, not addressing 
BB>>them. Without this minimal motivation, it would have 
BB>>had no meaning. If you don't agree with the examples, 
BB>>we can use other ones. But what you've said about 
BB>>diffserv on the Web page surely has to be said in the 
BB>>Proposed Standard. As it stands, the Proposed Standard 
BB>>could be interpreted as applying to all DS 
BB>>code-points, or all TCPs regardless of DSCP, or 
BB>>DSCP=0. It's just unstated assumptions. You endorse 
BB>>further experimentation, but the way I read it, it 
BB>>wasn't clear how the space to do it would be managed. 
BB>>I've spelled out the framework for experimentation. 
BB>>Surely this is reasonable?

SF>It makes sense to me to add in the equivalent of the sentence from
SF>the web page, saying that in the future DS codepoints might be
SF>defined with alternate semantics for ECN, and not saying anything
SF>else about it, if I can convince my co-authors.  I can't see saying
SF>more than that in this document.  But I will try to read that
SF>section one more time.

BB:Important bits:
BB:- a reminder to operators that diffserv PHBs need to 
BB:specify both drop & marking behaviour.
BB:- the constraint that markable/unmarkable equivalence 
BB:must be per DSCP.
BB:- clarify whether all your statements about mark=drop 
BB:apply to all DSCPs; DSCPs that could support TCP apps 
BB:(whatever that means); or just BE.

BB>>>David,
BB>>>
BB>>>At 20:56 21/02/01 -0500, [email-masked] wrote:
DB>>>>After reading Bob's draft, here are my comments.
DB>>>>Apologies in advance for the bluntness in some of
DB>>>>these due to writing rather quickly ...
DB>>>>
DB>>>>-- Section 5.1
DB>>>>
DB>>>>With my diffserv header/architecture RFC co-author
DB>>>>hat on, Section 5.1 ventures into the dangerous territory
DB>>>>of having diffserv specify queuing behavior (e.g., first
DB>>>>and last paragraphs discussing RED and virtual queues).
DB>>>>This is not a good idea, as there are not just landmines,
DB>>>>but thermonuclear devices with tripwires in there.  The
DB>>>>diffserv WG has had to carefully skirt this to avoid
DB>>>>specifying things in a fashion that would cause some
DB>>>>existing router vendor's queuing implementation to
DB>>>>not comply.  IMHO, this situation is best left alone,
DB>>>>but one could also consult the diffserv WG chairs
DB>>>>(Brian Carpenter, Kathie Nichols) about this and the
DB>>>>scars they've acquired from it.

BB>>>My wording doesn't say what you say it does. 

DB>>If this is just about wording, we may be close to
DB>>violent agreement.  The problem is that (IMHO) your goal
DB>>"for the marking behavior of routers to be predictable
DB>>for the hosts using them" to the level of "the best
DB>>effort (default) PHB might be standardized by specifying
DB>>its congestion marking behavior as the RED algorithm
DB>>and giving its parameters" is not achievable in the
DB>>short term as the diffserv WG currently exists.
DB>>Attempting this will hit tripwires attached to
DB>>thermonuclear devices.  Some more generic language
DB>>indicating only that PHB authors may want to
DB>>think about ECN ought to avoid this.

BB>Reasonable.

BB>>>I only say as much as the 
BB>>>diffserv architecture says on *who* sets PHBs (para 4). The fact is, 
BB>>>they are described (passive voice). The diffserv architecture says how 
BB>>>to describe them. I'm just pointing out that the list of what's in one 
BB>>>of these descriptions, needs to have 'marking behaviour' added. Even 
BB>>>if the description contains "not ECN-capable". It still has to be said 
BB>>>by whoever says it. It's just a reminder of the interactions that 
BB>>>adding ECN to IP will cause.

DB>>>>Setting this aside, the remainder of Section 5.1 adds a
DB>>>>guideline to PHB definitions requiring that the use of ECN
DB>>>>be defined by any PHB definition that defines conditions
DB>>>>under which traffic may be discarded.  I have mixed feelings
DB>>>>about this - OTOH, deciding whether to drop vs. mark and
DB>>>>forward sounds like the sort of forwarding behavior that
DB>>>>is in diffserv's domain, but OTOH, ECN and diffserv are
DB>>>>currently orthogonal and keeping them that way avoids
DB>>>>complications and consumption of additional diffserv
DB>>>>codepoints (e.g., for ECN and non-ECN versions of a PHB).

BB>>>No. The whole point is, 'ECN capable' acts as this switch. Don't need 
BB>>>extra DSCPs. And not having mentioned how they interact doesn't mean 
BB>>>they are orthogonal. They aren't. The reason for me writing this was 
BB>>>to point that out. DS includes discard behaviour. And marking is a 
BB>>>type of this. If an ECT packet arrives with any DSCP, the router has 
BB>>>to know what to do with it. A typical provider policy when ECN is 
BB>>>enabled first off might be to say, all DS code-points except 0 don't 
BB>>>implement ECN. But they have to say that. They can't bury their head 
BB>>>in the sand.

DB>>We agree on the goal of not consuming additional DSCPs.
DB>>How about:
DB>>- PHB definitions SHOULD NOT prohibit the use of ECN.
DB>>	SHOULD rather that MUST provides an escape if the
DB>>	EF folks decide that ECN is incompatible with EF.

BB>A PHB MAY define a behaviour that ignores ECN (i.e. treats it 
BB>like unmarkable traffic). I wouldn't use the words 'prohibit 
BB>ECN'. That would mean routers rejecting packets, requiring a 
BB>new ICMP Destination unreachable message, etc. etc. Yuk.
BB>
BB>My previous wording:
BB>"In future, PHBs MUST also define the congestion marking 
BB>behaviour of markable traffic if they define the discard 
BB>behaviour of unmarkable traffic. This UPDATES the guidelines 
BB>in the diffserv architecture."
BB>
BB>...was always intended to allow such a definition to be 
BB>"Marking behaviour of DCSP=x is to treat marable packets as 
BB>unmarkable". I shall make this explicit by adding:
BB>
BB>A PHB definition of marking behaviour MAY simply state that 
BB>markable traffic is treated as unmarkable, but this MUST be 
BB>defined (if it has already been considered necessary to 
BB>define the discard behaviour of unmarkable traffic).

DB>>- PHB definitions MAY describe the conditions under which
DB>>	ECN marking is used instead of dropping - in the

BB>Redundant surely? The conditions are that the packet is 
BB>markable and then the previous point covers it.

DB>>	absence of such description, implementations are
DB>>	free to choose whether and when ECN marking is used
DB>>	instead of dropping

BB>This is reasonable - in my wording above, there is still the 
BB>case where the PHB wasn't saying either the discard or the 
BB>marking behaviour. Then the only place left to decide this is 
BB>the implementation. I'll add this.

DB>>- PHB definitions SHOULD NOT use additional DSCPs to
DB>>	indicate ECN usage or communicate parameters for
DB>>	ECN marking algorithms.

BB>Don't think we need to say this either. ECN provides a 
BB>mechanism to do this without consuming DS code points. If an 
BB>operator wants to consume their code-points unnecessarily, 
BB>that's up to them. I could say that the ECN mechanisms don't 
BB>require any more code-points to be consumed to do the above.

DB>>From a process standpoint, anything along these lines will
DB>>have to be reviewed in the diffserv WG, and has the potential
DB>>to hold things up, as I believe the diffserv WG would like
DB>>to avoid reopening the diffserv architecture RFC (which is
DB>>where the PHB definition guidelines are) at the moment.
DB>>I could see putting the first and third bullets into the
DB>>ECN RFC if that would make a real difference.

BB>I think the only thing needed to be added to diffserv is the 
BB>bit where I said 'This UPDATES the guidelines in the diffserv 
BB>architecture.' As they are guidelines, I'm not sure of 
BB>process (they are in the architecture, which is 
BB>INFORMATIONAL.)

DB>>>>My gut feeling about ECN definition in a PHB is that
DB>>>>the most likely definitions are "ok to use in accordance
DB>>>>with the ECN RFC" or "prohibited" - I don't think these
DB>>>>add much value, and the latter could be the source of
DB>>>>controversy (e.g., should EF prohibit ECN?  Those
DB>>>>who have survived the recent "EF wars" would prefer
DB>>>>not to have to ask).

BB>>>When you run a network, you can't just stick your head in the sand 
BB>>>when valid packets arrive that you hadn't planned for.

BB>At 20:28 23/02/01 -0500, [email-masked] wrote:
DB>>
DB>>On the few things that are left:
DB>>
DB>>-- PHB guidelines (5.1):
DB>>
DB>>On a procedural basis, I'm now convinced that the
DB>>proverbial "right" home for this is a diffserv
DB>>RFC 2475 update, and I'd like to avoid getting the ECN
DB>>draft mixed up in that.  Hence I don't plan to write a
DB>>formal guideline but rather note that PHB definitions
DB>>SHOULD NOT require that all markable packets be treated
DB>>as unmarkable, but MAY recommend conditions under which
DB>>ECN marking SHOULD or SHOULD NOT be used instead of
DB>>dropping packets.  Note that the use of SHOULD (rather
DB>>than MUST) provides the right bias while leaving an
DB>>escape hatch available for those who are absolutely,
DB>>positively sure that they know better.

DB>>>>-- Section 5.2
DB>>>>
DB>>>>Section 5.2 is essentially asking to relax the
DB>>>>requirement that marking and end node behavior match TCP's
DB>>>>current response to congestion in order to "ensure space
DB>>>>for future experimentation".  While research and
DB>>>>experimentation are good things, mucking with this sort
DB>>>>of fundamental aspect of the Internet (if it weren't
DB>>>>for TCP's response to congestion, the Internet would
DB>>>>not work) to encourage those activities seems like
DB>>>>the wrong tradeoff.  Much as the discussion of what
DB>>>>might be possible is interesting, but knowing what
DB>>>>will happen seems important enough here to not make
DB>>>>this change - the research and experimentation
DB>>>>can go on regardless.

BB>>>Whoa! I think you've just removed much of the point I can see in 
BB>>>adding ECN for the future. You don't want to drop from EF, say. You do 
BB>>>want very early ECN to avoid it. Pls consider this a bit more, I 
BB>>>suggest. I was much happier with Sally's answer.

DB>>I don't think I'm disagreeing with Sally.  My opinion is
DB>>that we ought to have the experiments in hand before
DB>>making or allowing modifications to congestion control
DB>>in standards documents rather than the other way around.
DB>>It seems to me that you want to do things in the other order.

BB>Sally's saying space is needed to experiment. I reacted to 
BB>your wording which said the experiments would be invalid if 
BB>they resulted in finding different points of equivalence 
BB>between markable and unmarkable behaviour (e.g. a drop for a 
BB>drop to use Old Testament language). 
BB>I was giving a framework to isolate the experiments from each 
BB>other and from the operational space. 'Experiments' includes 
BB>operators doing tech & market trials, after research projects 
BB>on isolated testbeds have finished.

DB>>-- Relaxing ECN marking equivalence to drop (5.2)
DB>>
DB>>We disagree - you'll have to make your case for allowing
DB>>this sort of congestion control change to the tsvwg.  As
DB>>noted previously, I disagree with the intermediate position
DB>>of mandating this equivalence only for BE traffic.

DB>>>>-- Section 5.3
DB>>>>
DB>>>>Section 5.3 on specifying service level agreements
DB>>>>should be taken up with the community working on this sort
DB>>>>of thing (e.g., see the sls BOF agenda from the San Diego
DB>>>>IETF), rather than tacked on to this ECN document.

BB>>>Perhaps our draft should be seen as an agenda of interactions with 
BB>>>other w-gs in many cases. I don't mind that. I guess the IESG and IAB 
BB>>>will find it useful.

DB>>I think we agree that the specification of ECN in service
DB>>level specifications needs attention in some forum - I wouldn't
DB>>fold it into the current ECN draft, though.

BB>OK. Our I-D can be the start of that.

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