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

[Michael Welzl]

On Tue, 2007-08-07 at 13:14 +0100, 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).

Great!


> 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?

Thanks for "articulated well"  :-)   and interesting feedback...
indeed that would be a main point to focus on IMO


> 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).

yep


> 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.

Great, I appreciate that!


> I think we need a "Challenge 9: Multicast Congestion Control"
> Both streamed-media and messaging types of multicast.

Right!!! I knew that there were several things that we overlooked
so far, that's one that I didn't think of


> 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?)
> 
> 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)?
> - distinguishing per-packet congestion from per-byte congestion (similar 
> problem to distinguishing congestion from wireless transmission losses)?
> - ever-widening range of packet sizes: if design equipment for larger ave 
> pkt size, gets overloaded with flurries of small packets.

I must admit that I didn't give everything in the document a detailed
read yet - I was planning to do so in a general update which I wanted
to do, well, early this week  :(   so a little later, it seems ...

anyway, in that update, I'll see if I can somehow answer your questions
(or avoid them being raised  :)  )  - thanks!

Cheers,
Michael