[Iccrg] update to cc-rfcs draft

[[e-mail] (Wesley Eddy)]

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 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.  Current IETF work invoves 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!

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