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

[dimitri papadimitriou]

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.