[Iccrg] update to cc-rfcs draft

Thu Sep 6 14:55:10 BST 2007

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

==========================================================================
"...

                            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.

"

Even if you don't want to include all the QoS RFCs (which I think is a 
reasonable scoping decision) I don't think you should try to make out the 
distinction between QoS and congestion control is so clear-cut.

I suggest a distinction needs to be made between closed loop QoS (which is 
surely NOT a side-note to congestion control) and open loop QoS (which is 
built completely differently to congestion control).

Open loop QoS through provisioning (like classic Diffserv) is clearly easy 
to separate off as a distinct field.
But admission control is closed loop (through the signalling protocol) and 
directly notifies congestion at short time scales on each queue to the 
application (ie admission is denied when resources would otherwise be 
exhausted - congestion). So strictly, this draft should say its scope is 
congestion control SOLELY for elastic apps (at packet granularity), and 
congestion control for inelastic apps at flow granularity is out of scope.

This suggests even the title might need clarifying.

You only have to look at the pre-congestion notification (PCN) w-g to see 
how congestion control protocols designed for elastic apps (ECN) can be 
re-used edge-edge to create an admission control behaviour for inelastic 
apps. If you wanted to point to this similarity, you could refer to the the 
first w-g I-D on its architecture that was published 3wks ago:
         draft-ietf-pcn-architecture-00.txt.
See <http://tools.ietf.org/wg/pcn/> for more.

"

    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.

"
Certainly I agree QoS in the MAC layer whould be out of scope for the same 
reasons it should be at the network layer...

But, as Tim Shepperd (correctly) argued at the last ICCRG mtg, congestion 
can cause losses in queues at any layer. Also AQM like RED is just as 
useful and possibly just as common in lower layer queues as in IP queues. 
And not just AQM for drop. AQM with ECN is relevant in lower layers where a 
network can be built.

Which brings me on to exceptions to the rule that the MAC layer isn't 
discussed at IETF. For instance the tsvwg has just requested publication of 
ECN in MPLS as a proposed standard: 
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-mpls-01.txt>.

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

HTH

Bob

At 15:18 27/08/2007, Wesley Eddy wrote:
>Michael and I completed an update of the cc-rfcs document that surveys
>the published RFCs dealing with congestion control:
>
>http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-02.txt
>
>Most of the changes come from the detailed review that Gorry sent us,
>along with some other comments from Sally Floyd, Mark Allman, Stephen
>Farrell, and Lars Eggert.  We also added a few more RFCs to the list.
>
>We realize that since RFC 5033 was *just* published, we need to add
>this to the draft, but aside from this, we'd also like to know if
>the update suffices to address people's comments.  A colorized rfcdiff
>is available for efficient checking:
>
>http://roland.grc.nasa.gov/~weddy/shared/iccrg/cc-rfcs-01-to-02-diff.html
>
>If possible, we'd like to finish revision of this within the RG by the
>end of September and move it forward.  Thanks for your comments and
>reviews :).
>
>--
>Wesley M. Eddy
>Verizon Federal Network Systems
>
>_______________________________________________
>Iccrg mailing list
>Iccrg at cs.ucl.ac.uk
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
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  