[Iccrg] draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

Wed Aug 8 09:14:03 BST 2007

dirceu

Dirceu Cavendish wrote:
> Dimitri,
> 
> Comments on my first pass on you document follows. 

i will address along the the review (stay tuned)

> Quick question: 
> is the document main purpose to only raise CC questions/issues? 
> Or to also eventually capture/document answers to those issues?

main purpose is description/analysis of open problems/issues in Internet
congestion control (at least those known today) that have research 
potential

if a (partial) answer or initial results are progressively maturing i 
would then suggest to put them in perspective (but this document is not 
the place to describe the resulting research activities)

much thanks for commenting,
-dimitri.

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