dpapadimitriou at psg.com
Tue Aug 7 23:45:21 BST 2007
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
this will be part of the updated version (including the
> 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
> 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
> - 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 ?
More information about the Iccrg