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

[Michael Welzl]

Hi all,

Just a quick comment (and only my personal opinion): somehow,
this discussion ended up on the ICCRG list, but I think that
this document is not even in shape for a broader review from
the group up to now.

Personally, my suggestion would be not to waste your time
with half baked stuff, and just give it some more time
before we get back to you with it.

But that's of course only my very personal opinion...

Cheers,
Michael


On Wed, 2007-08-08 at 10:14 +0200, dimitri papadimitriou wrote:
> 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
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg