<html>
<body>
Dirceu,<br><br>
I've changed the subject line...<br><br>
At 19:25 06/09/2007, Dirceu Cavendish wrote:<br>
<blockquote type=cite class=cite cite>Wesley,<br><br>
About the last paragraph discussed, I dont know how much you want to
dwelve into L2 considerations in the document. However, there are two
initiatives within IEEE 802 standards about congestion control in
Ethernets: 802.1au congestion notification
(<a href="http://www.ieee802.org/1/pages/802.1au.html">http://www.ieee802.org/1/pages/802.1au.html</a>
), and 802.3ar congestion management
(<a href="http://www.ieee802.org/3/ar/index.html">http://www.ieee802.org/3/ar/index.html</a>
). I can provide some level of detail about the creation and intent of
these groups, if needed, as I was somehow involved with them up to late
last year.<br>
</blockquote><br>
BTW, Lars Eggert invited Pat Thaler of Broadcom to give a talk to the
IETF tsvarea about these (mostly about 802.1au) - a couple of IETFs ago.
You can find it in the proceedings.<br><br>
BTW2, for anyone interested, I've recently written an I-D including
general advice about when and where any connectionless lower layer
technologies might need to do AQM and congestion marking and how best to
do it if it is intended to interact with e2e congestion control. It
covers security, control and management issues
<<a href="http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-ecn-tunnel-00.txt" eudora="autourl">http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-ecn-tunnel-00.txt</a>>.
<br><br>
This is separate from , but related to, the ECN in MPLS I-D I mentioned
earlier (now on its way to the RFC Editor). MPLS was a specific example,
while the above layering and tunnelling I-D is intended to give the
reasoning and more general guidance.<br><br>
We believe the approach we took to get MPLS interacting with e2e
congestion control could carry over nearly unchanged to IEEE802
protocols, complementing the two 802 approaches above. <br><br>
Cheers<br><br>
<br>
Bob<br><br>
<br>
<blockquote type=cite class=cite cite> <br>
Rgds,<br>
Dirceu<br>
PS: Could you kindly add
<a href="mailto:dirceu@ndrc.kyutech.ac.jp">dirceu@ndrc.kyutech.ac.jp</a>
to iccrg mailing list?<br>
----- Original Message ----<br>
From: Wesley Eddy <weddy@grc.nasa.gov><br>
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk><br>
Cc: iccrg@cs.ucl.ac.uk<br>
Sent: Thursday, September 6, 2007 7:57:57 AM<br>
Subject: Re: [Iccrg] update to cc-rfcs draft<br><br>
On Thu, Sep 06, 2007 at 02:55:10PM +0100, Bob Briscoe wrote:<br>
> Wes,<br>
> <br>
> I'd just like to say I found the previous version of this draft extremely <br>
> useful - it is rare to have such a resource to ensure people don't forget <br>
> how much has already been done.<br>
> <br>
> Below are a couple of comments on the wording of the justification for why <br>
> the scope avoids QoS & MAC (in 1. Introduction). I agree your scoping is <br>
> reasonable, I'm just saying it's been justified and described in a way that <br>
> I don't think is fitting...<br>
><br>
> ...<br>
><br>
> So this para really needs re-writing to say QoS is out of scope whether at <br>
> L3 or L2, but L2 notifying the endpoints using losses or ECN is in scope. <br>
> Obviously there will only be RFCs about specific link technologies if the <br>
> IETF is responsible for standardising that L2 technology (e.g. MPLS), but <br>
> as you've pointed out, there are RFCs giving design advice for how link <br>
> layers in general should interwork with congestion control (e.g. all the <br>
> PILC stuff you mention).<br>
> <br><br>
<br>
Thanks; those comments do help. I'll suggest the text below as a fix, and<br>
appreciate if you can tweak anything that's still wrong with it :).<br><br>
Change this old incorrect text:<br><br>
- We specifically do not include the vast amount of QoS work<br>
- into the scope of this document, as it is a full field in its own<br>
- right, and deals with issues that are mostly orthogonal to end-host<br>
- congestion control and router queue management. Although there can<br>
- certainly be interactions between QoS and congestion control<br>
- mechanisms, scheduling mechanisms used to implement QoS (on either<br>
- per-flow or an aggregate basis), for instance, can be used<br>
- independently of the end-host congestion control and queue management<br>
- functions also in use. Similar arguments can be made for traffic-<br>
- shaping, admission control, and other functions that are intended for<br>
- QoS, and only side-notes for congestion control.<br><br>
into:<br><br>
+ We specifically do not include the vast amount of QoS work<br>
+ into the scope of this document, as it is a full field in its own<br>
+ right. Some "open-loop" QoS mechanisms that do not involve<br>
+ signalling (e.g. classic DiffServ) can be used independently of<br>
+ specific queue management algorithms and end-host congestion control<br>
+ mechanisms. Closed-loop mechanisms designed for applications with<br>
+ less-elastic packet-sending rates that operate at per-flow granularity<br>
+ are out of scope for this document, which focuses on packet-level<br>
+ congestion control. Some recent work has proposed re-use of existing<br>
+ congestion control protocols for elastic applications in order to<br>
+ support edge-to-edge admission control for inelastic applications<br>
+ [PCN-ARCH], however, no RFCs have yet been published on this work.<br><br>
and this old incorrect text:<br><br>
- A similar argument can be made for excluding consideration of the<br>
- media access control (MAC) layer protocols used by the links<br>
- throughout a path. Although the MAC protocols implement various<br>
- forms of resolving contention for shared links (and sometimes offer<br>
- QoS services), these are also distinct from end-to-end congestion<br>
- control. Furthermore, MAC protocols are not typically discussed in<br>
- the RFC series, but are defined in outside documents (e.g. IEEE<br>
- standards), since the IETF does not generally work on link layers<br>
- themselves. Few, if any, of the RFCs that describe mappings of IP<br>
- onto various link layers directly discuss congestion control.<br><br>
into:<br><br>
+ Since link layers have their own queues in addition to IP layer queues,<br>
+ congestion can manifest itself at the link layer, below the radar of<br>
+ IP-layer congestion detection and marking mechanisms. Few, if any, of<br>
+ the RFCs that describe mappings of IP onto various link layers directly<br>
+ discuss congestion control, and we consider them out of scope for this<br>
+ document's purposes. Current IETF work invoves use of IP-layer<br>
+ congestion notification for packets forwarded within MPLS [ECN-MPLS],<br>
+ which operates as a shim between the link and network layers. Several<br>
+ of the RFCs discussed in Section 4 of this document discuss how general<br>
+ classes of link layers interact with congestion control. Since link<br>
+ layer specifications are usually the product of bodies outside the IETF<br>
+ (e.g. the IEEE standards), tighter integration of congestion control with<br>
+ link layer technologies is a mostly open area.<br><br>
<br>
Please let me know if these can be improved; I won't be insulted at all<br>
if the paragraphs have to be redone from scratch. As long as we still<br>
agree to not burden ourselves with QoS RFCs, I'll be happy!<br><br>
It's probably off-topic for this RG, but I think someone should make up<br>
a similar "reader's guide"/"RFC roadmap"/"annotated bibliography" or<br>
whatever you want to call it for all the QoS RFCs ...<br><br>
-- <br>
Wesley M. Eddy<br>
Verizon Federal Network Systems<br><br>
_______________________________________________<br>
Iccrg mailing list<br>
Iccrg@cs.ucl.ac.uk<br>
<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br><br>
<br>
<br>
Be a better Heartthrob. <a href="http://us.rd.yahoo.com/evt=48255/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545433">Get better relationship answers </a>from someone who knows.<br>
Yahoo! Answers - Check it out. </blockquote>
<x-sigsep><p></x-sigsep>
____________________________________________________________________________<br>
Bob Briscoe, <bob.briscoe@bt.com> Networks Research Centre, BT Research<br>
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196</body>
</html>