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

Wed Aug 8 03:09:12 BST 2007

Dimitri,

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070807/5638fb57/attachment-0001.html