<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:10pt"><DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">Wesley,</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"><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.</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">Rgds,</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">Dirceu</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">PS: Could you kindly add <A href="mailto:dirceu@ndrc.kyutech.ac.jp">dirceu@ndrc.kyutech.ac.jp</A> to iccrg mailing list?<BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- 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>
<DIV>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" target=_blank>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</A></DIV></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1>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.
</body></html>