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

[Bela Berde]

-------- Original-Nachricht --------
Datum: Tue, 07 Aug 2007 14:36:11 +0200
Von: "Bela Berde" <Bela.Berde at gmx.de>
An: Bob Briscoe <rbriscoe at jungle.bt.co.uk>
Betreff: Re: [Iccrg] 	draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

Dear All,
The network element issue, as Bob identifies, is partly introduced in the unpublished version of the draft. 
This was in section Other Challenge 3.9.1 The text provides the idea of network elements for the specific support of the end-to-end congestion control. 
(The section is called "Distant Equipment for Congestion Control Support"; clearly distant means: not host-based.)
Here the word "support" can be broadened etc. 
Your comments are welcome.
Sincerely,
 
-------- Original-Nachricht --------
Datum: Tue, 07 Aug 2007 13:14:30 +0100
Von: Bob Briscoe <rbriscoe at jungle.bt.co.uk>
An: michael.welzl at uibk.ac.at, dimitri.papadimitriou at alcatel-lucent.be
CC: iccrg IRTF list <iccrg at cs.ucl.ac.uk>
Betreff: [Iccrg] 	draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

> 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?
> 
> 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).
> 
> 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.
> 
> I think we need a "Challenge 9: Multicast Congestion Control"
> Both streamed-media and messaging types of multicast.
> 
> 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.
> 
> 
> 
> 
> Bob
> 
> 
> ____________________________________________________________________________
> Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT
> Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
> 645196 
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger