[Iccrg] update to cc-rfcs draft

[Bob Briscoe]

Wes,

These look much better now. See inline for nits...

At 15:57 06/09/2007, Wesley Eddy wrote:
>On Thu, Sep 06, 2007 at 02:55:10PM +0100, Bob Briscoe wrote:
> > Wes,
> >
> > I'd just like to say I found the previous version of this draft extremely
> > useful - it is rare to have such a resource to ensure people don't forget
> > how much has already been done.
> >
> > Below are a couple of comments on the wording of the justification for why
> > the scope avoids QoS & MAC (in 1. Introduction). I agree your scoping is
> > reasonable, I'm just saying it's been justified and described in a way 
> that
> > I don't think is fitting...
> >
> > ...
> >
> > So this para really needs re-writing to say QoS is out of scope whether at
> > L3 or L2, but L2 notifying the endpoints using losses or ECN is in scope.
> > Obviously there will only be RFCs about specific link technologies if the
> > IETF is responsible for standardising that L2 technology (e.g. MPLS), but
> > as you've pointed out, there are RFCs giving design advice for how link
> > layers in general should interwork with congestion control (e.g. all the
> > PILC stuff you mention).
> >
>
>
>Thanks; those comments do help.  I'll suggest the text below as a fix, and
>appreciate if you can tweak anything that's still wrong with it :).
>
>Change this old incorrect text:
>
>- We specifically do not include the vast amount of QoS work
>- into the scope of this document, as it is a full field in its own
>- right, and deals with issues that are mostly orthogonal to end-host
>- congestion control and router queue management.  Although there can
>- certainly be interactions between QoS and congestion control
>- mechanisms, scheduling mechanisms used to implement QoS (on either
>- per-flow or an aggregate basis), for instance, can be used
>- independently of the end-host congestion control and queue management
>- functions also in use.  Similar arguments can be made for traffic-
>- shaping, admission control, and other functions that are intended for
>- QoS, and only side-notes for congestion control.
>
>into:
>
>+ We specifically do not include the vast amount of QoS work
>+ into the scope of this document, as it is a full field in its own
>+ right.  Some "open-loop" QoS mechanisms that do not involve
>+ signalling (e.g. classic DiffServ) can be used independently of
>+ specific queue management algorithms

I know what you meant, but the phrase "queue management algorithms" 
includes scheduling, which is very much in Diffserv land. How about 
replacing it with "load management algorithms"?

>and end-host congestion control
>+ mechanisms.  Closed-loop mechanisms designed for applications with
>+ less-elastic packet-sending rates that operate at per-flow granularity
>+ are out of scope for this document, which focuses on packet-level
>+ congestion control.  Some recent work has proposed re-use of existing
>+ congestion control protocols for elastic applications in order to
>+ support edge-to-edge admission control for inelastic applications
>+ [PCN-ARCH], however, no RFCs have yet been published on this work.
>
>and this old incorrect text:
>
>- A similar argument can be made for excluding consideration of the
>- media access control (MAC) layer protocols used by the links
>- throughout a path.  Although the MAC protocols implement various
>- forms of resolving contention for shared links (and sometimes offer
>- QoS services), these are also distinct from end-to-end congestion
>- control.  Furthermore, MAC protocols are not typically discussed in
>- the RFC series, but are defined in outside documents (e.g.  IEEE
>- standards), since the IETF does not generally work on link layers
>- themselves.  Few, if any, of the RFCs that describe mappings of IP
>- onto various link layers directly discuss congestion control.
>
>into:
>
>+ Since link layers have their own queues in addition to IP layer queues,
>+ congestion can manifest itself at the link layer, below the radar of
>+ IP-layer congestion detection and marking mechanisms.  Few, if any, of
>+ the RFCs that describe mappings of IP onto various link layers directly
>+ discuss congestion control, and we consider them out of scope for this
>+ document's purposes.

Just to be picky, I would suggest removing "if any" and the last clause 
after comma.
- "If any" isn't nec. because in the next sentence you mention one - MPLS.
- And if there were any in the IETF as opposed to IEEE, there would be no 
reason for them not to be in scope.
This leaves the sentence as:

"Few of the RFCs that describe mappings of IP onto various link layers 
directly discuss congestion control."

>Current IETF work invoves

Typo: involves

>use of IP-layer
>+ congestion notification for packets forwarded within MPLS [ECN-MPLS],
>+ which operates as a shim between the link and network layers.  Several
>+ of the RFCs discussed in Section 4 of this document discuss how general
>+ classes of link layers interact with congestion control.  Since link
>+ layer specifications are usually the product of bodies outside the IETF
>+ (e.g. the IEEE standards), tighter integration of congestion control with
>+ link layer technologies is a mostly open area.
>
>
>Please let me know if these can be improved; I won't be insulted at all
>if the paragraphs have to be redone from scratch.  As long as we still
>agree to not burden ourselves with QoS RFCs, I'll be happy!

They're fine as they stand, even if you don't want to take on my comments. 
Thanks

Bob


>It's probably off-topic for this RG, but I think someone should make up
>a similar "reader's guide"/"RFC roadmap"/"annotated bibliography" or
>whatever you want to call it for all the QoS RFCs ...
>
>--
>Wesley M. Eddy
>Verizon Federal Network Systems

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196