<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:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Dimitri,</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Comments on my first pass on you document follows. Quick question: is the document main purpose to only raise CC questions/issues? Or to also eventually capture/document answers to those issues?</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Rgds,</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Dirceu</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">***Comments:draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">General comments:</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">1- There should be a session "CC objectives", discussing previous<BR>(e.g. TCP) and what is understood to be current/modern CC objectives.<BR>For instance, retransmission avoidance and stability were not previous<BR>objectives. Also, RTT fairness was not a concern in previous TCPs.<BR>As it is, the objectives are scattered all over the document<BR>(e.g., session 3.1.1). The clearer the objectives are, the easier the text<BR>discussion it will be.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">2- The document starts with router support as its first challenging topic.<BR>Assuming a low to high level of complexity organization, the first<BR>challenge should embrace address CC schemes that do not involve router<BR>support at all. For instance, what are the limitation of CC schemes that<BR>do not have router support. How much can routers "get in the way" of<BR>such cc schemes. Another challenge/topic should be cc with support for<BR>specific applications' requirements (quick ramp up, no/minimum retransmissions, etc).</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">3- The material strikes to me to be biased towards new CC protocols with<BR>router support. It would be nice to have the "no router support" in the discussions<BR>of the various topics. For instance, "3.6 Challenge 6: Multi-domain Congestion Control"<BR>material assumes entirely ECN. An interesting question could be: "What type of CC<BR>can we have that does not rely on router support?"</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">"With increasing the per-flow bandwidth-delay product increases,<BR> ~~~~~~~~~~ ~~~~~~~~~<BR>TCP <BR> becomes inefficient and prone to instability, regardless of the <BR> queuing scheme. XCP, which generalizes ECN, has been developed to <BR> address these issues, using per-packet feedback. By decoupling <BR> resource utilization/congestion control from fairness control, XCP <BR> outperforms TCP in conventional and high bandwidth-delay <BR> environments, and remains efficient, fair,
scalable, and stable <BR> regardless of the link capacity, the round trip delay, and the number <BR> of sources."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>"[PAP02] shows that when flows with different RTTs are applied, XCP <BR> sometimes discriminates among heterogeneous traffic flows, even if<BR> ~~~~~~~<BR> XCP is generally fair to different flows even if they belong
to<BR> ~~~~~~~<BR> significantly heterogeneous flows."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">"- Is it possible to design robust mechanisms that offer significant <BR> benefits without additional risks?"<BR> ~~~~~ additional risks, or drawbacks?</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">"procedures one the one end, and additional per packet processing on<BR> ~~~ on<BR> the other end of the solution space."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">"The congestion control algorithms have to deal with this variety in<BR> ~~~^~~~ of conditions <BR> an efficient way."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>"In-band signaling can be considered to be an appropriate choice: <BR> Since notifications are piggy-packet along with data traffic, there<BR> ~~~~~~~~~~~~ piggybacked? <BR> is less overhead and implementation complexity remains limited. Path-<BR> coupled out-of-band signaling could however be possible, too."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">3.3 Challenge 3: Corruption Loss <BR> "The IETF has not yet specified how a congestion control mechanism <BR> should react to corruption."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">To me, transport layer CC reaction to corruption loss is a layer violation.<BR>I am not a purist on OSI layering, but there are practical consequences to<BR>layering violation. For instance, is L4CC to react to the corruption on<BR>every L2? If yes, should there be an standard way of L2/L3 to report upward<BR>packet/frame corruption? Should (and could) there be a single reaction way<BR>from a L4CC point of view to packet corruption?</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">3.5 Challenge 5: Pseudo-Wires</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">I think that when discussing different types of traffic, such as TDM, it should<BR>be mentioned how traffic priorities can be played into the problem. This is<BR>because indeed priority bits are available as a helper to differentiate packet<BR>delivery/interference. For instance, in the example of a second P2, TDM traffic could<BR>be mapped into a higher priority traffic, in a scenario where INTENTIONALLY P2 wants<BR>to squeeze "regular" TCP streams out if needed be. This is what traffic engineering<BR>is about, and it should not be ruled out as unlawful as TCP unfriendly. OF course,<BR>in this case, P2 would receive packets from P1 with their TOS/diffserv bits set<BR>accordingly.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>3.6 Challenge 6: Multi-domain Congestion Control </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">There seems to be a bias in the discussion towards explicit support of routers.<BR>Besides the multi-domain CC example mentioned earlier, implicit feedback could do<BR>away with proxy/gateway concerns on explicit feedback information across domains.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">3.7 Challenge 7: Precedence for Elastic Traffic</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">"The idea to distinguish several classes of best-effort traffic dates <BR> ~~~~~(drop)<BR> is rather old, since it would be beneficial to address the relative <BR> delay sensitivities of different elastic applications."</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR><BR> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: dimitri papadimitriou <dpapadimitriou@psg.com><BR>To: Bob Briscoe <rbriscoe@jungle.bt.co.uk><BR>Cc: iccrg IRTF list <iccrg@cs.ucl.ac.uk><BR>Sent: Tuesday, August 7, 2007 3:45:21 PM<BR>Subject: Re: [Iccrg] draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt<BR><BR>
<DIV>bob<BR><BR>thx for the feedback - see inline<BR><BR>Bob Briscoe wrote:<BR>> Michael, Dimitri,<BR>> <BR>> During the presentation of this at the last ICCRG mtg I identified some <BR>> extra challenges or adjuncts to the existing ones, which I'll record <BR>> here and add a few review comments too (tho I'll do a full review later <BR>> and at the same time I contribute some better thought-thru text if req'd).<BR>> <BR>> Challenge 1 sort of misses the top level question that you (Michael) <BR>> articulated well at the previous ICCRG mtg in LA:<BR>> - What's the minimum support in network elements for future-proofed <BR>> (incl hi-speed) congestion control?<BR><BR>i would consider this as a baseline issue was probably overlooked<BR>in the text but needs to be indeed spelled out<BR><BR>> Note the term "network elements" not "routers" - as Tim Shepard said, we <BR>> have to work with congestion in lower layers too
(and if doing explicit <BR>> congestion notification, we have to propagate congestion info up the <BR>> layers).<BR><BR>this will be part of the updated version (including the<BR>terminology)<BR><BR>> I can probably contribute text to "Challenge 8. Misbehaving S&Rs". For <BR>> instance, I have a fair idea of which aspects of the DoS problem might <BR>> be solved by better congestion control.<BR><BR>ok. any contribution along this challenge would help progressing<BR>the document.<BR><BR>> I think we need a "Challenge 9: Multicast Congestion Control"<BR>> Both streamed-media and messaging types of multicast.<BR><BR>agreed. a second cut should also look at higher hanging fruits.<BR>topic was (side) discussed also with other contributors.<BR><BR>> Other more detailed questions:<BR>> <BR>> An additional question in 3.1.4 (which should probably be entitled <BR>> feed-forward notification, not feedback)<BR>> - what's the
minimum information intensity of congestion notification <BR>> (More than 1-bit per packet? Is sensing congestion delay variation a <BR>> sufficient alternative?)<BR><BR>yes this is imho an important point. would deserve additional discussion<BR>on this list. i would distinguish intensity from encoding granularity <BR>and significance.<BR><BR>> Also:<BR>> - Is a good system & equipment design goal to sacrificially throttle <BR>> bit-rate to avoid CPU overload (so the brain can still work out what to <BR>> do about congestion)?<BR><BR>what do you mean with "sacrificially throttle" ?<BR><BR>> - distinguishing per-packet congestion from per-byte congestion (similar <BR>> problem to distinguishing congestion from wireless transmission losses)?<BR><BR>you made that comment during the "corruption loss" discussion, do you <BR>see this as a separate discussion point now ? note also relationship <BR>with the packet size
(former).<BR><BR>> - ever-widening range of packet sizes: if design equipment for larger <BR>> ave pkt size, gets overloaded with flurries of small packets.<BR><BR>you made that comment during the "small packet size" discussion -> i<BR>guess this would like to see a discussion about impact wrt relative avg <BR>size and range ?<BR><BR>thx,<BR>-d.<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: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1><a href="http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&s=Y&s2=EM&b=50">Pinpoint customers </a>who are looking for what you sell.
</body></html>