[e2e] "congestion" avoidance...

[Peter Key]

Jon,

You don't have to couple "ECN signalling" with "ECN pricing" so tightly.

For example, an ECN signal may reflect the correct "resource price" or
"congestion prices" based on packet or resource level dynamics, and
users may react accordingly (or not...).  How these are translated to a
users in terms of "real" or "vitual" money depends on charging models
etc, but could relate to an aggregate level if so desired.    For
example you can fit the bounded fixed-rate charging bands  of mobile
phones into this model.

The difference is between a fundamental metering unit and how you charge
for it etc etc (eg electricity).

As for democritising, you can push the "risk brokers" as far to the edge
as you want, eg for virtual circuits you can use the approach of
Distributed Admission Control (JSAC Dec 2000, pp2617-2628), where the
end-systems decide.  

If the metering signals are correct, the users can do what they  want
...



Cheers,

Peter



> -----Original Message-----
> From: Jon Crowcroft [mailto:J.Crowcroft at cs.ucl.ac.uk] 
> Sent: 17 April 2001 11:21
> To: David P. Reed
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] "congestion" avoidance...
> 
> 
> 
> 
> so the problem i have with the current "ECN pricing" thinking 
> is that it ignores users preferences for stability and 
> predictability over cheapness (and we have a LOT of evidence 
> gathered from mobile phone contracts, web and traditional 
> telewphony as well as airline procing 
> and so on i can cite)
> 
> the shadow price for a packet (smart market) is one model, 
> but leads to potential rapid fluctation in price aroudn flash 
> crowd periods, which are all to common in IP networks
> 
> the simple alternative  is a shadow price for a virtual 
> circuit - this gives a stable price for the throughput over 
> the "lifetime" of a session.....
> 
> 
> if you Mix this, you can get into nasty arbritrage 
> situations....and i don't buy into the story that yo ucan 
> offer users a choce via risk brokers - for the very reason 
> that the traffic is highly dynamic...
> 
> also, risk brokers form markets  themselves.....
> 
> what i was thinking ewas to "democratise" (disintermediate) 
> the risk broker and let users form their +own+ cartels dynamically...
> 
> i.e. we napsterise congestion pricing for packets and flows...
> 
> In message <5.0.2.1.2.20010417060401.03063510 at mail.reed.com>, 
> "David P. Reed" t
> yped:
> 
>  >>Interesting thoughts.  However, money or something like it 
> needs to enter 
>  >>into the thinking.  I.e. some notion of sharing 
> responsibility for costs 
>  >>imposed on others.
>  >>
>  >>IE: At a point of congestion, the "indirect channels" 
> among competing flows 
>  >>provide a way of signalling (at some bitrate) for a 
> bargaining scheme.  >>  >>What range of bargaining schemes 
> can be piggybacked on this signalling channel?  >>  >>For 
> example, what if a single (urgency) bit per packet (like the 
> ECN flag, 
>  >>but provided by the source to the congested queue) could 
> be modulated at 
>  >>the source, tracked in a state variable at a router queue, 
> and coupled into 
>  >>a bit in each outgoing packet that controls rate like ECN. 
>  >>  >>  >>At 10:06 AM 4/17/01 +0100, Jon Crowcroft wrote:  
> >>  >>  >>  >>>there have been some steps recently to look at 
> a range of rate and  >>>window based mechanisms for sharing 
> the net amongst a set of sources (or  >>>sinks if we include 
> receiver based multicast schemes) - i was looking  >>>at 
> these and wondering if it isnt time to revisit some of the  
> >>>congestion control and avoidance thinking  >>>  >>>some 
> schemes have been proposed that smooth the adjustment so that 
>  >>>over an RTT we creep up to the operating rate, and creep 
> down, on a  >>>packet by packet (inter-packet delay 
> adjustment) basis  >>>(RAP from Handley et al)  >>>  >>>other 
> schemes have proposed different powers for the increase 
> decrease  >>>function (and assert that so long as we decrease 
> x^n, and increase  >>>x^(n-1), we ought to be "ok" for some 
> definition of ok)  >>>(binomial adjustment etc from  >>>  
> >>>the TCP AIMD with fast retransmit scheme has several 
> motivating factors  >>>some intended, some lucky happenstance 
> (serendipitous)...  >>>  >>>1/ sampling network conditions 
> and eliminating noise:  >>>  >>>currently, this operates over 
> the RTT timescale, but is memoryless  >>>after 
> that....estimates for loss effectively im,plicit in the AIMD  
> >>>operation, but the noise filter (number of dupacks) is 
> somewhat  >>>rigid...  >>>  >>>2/ safe/stable operation:  
> >>>given feedback controller, its reasonable to operate this 
> over  >>>packet conservation/self clocking makes it more 
> smooth  >>>  >>>3/ relating end system rate adjustment 
> timescale to buffering provisioning  >>>the AIMD scheme has 
> the bandwidth/delay product wrth of network  >>>buffering as 
> a necessary side effect - other adjustment schemes might  
> >>>need less (some might need more but that almost certainly 
> means they  >>>are trouble:-)  >>>  >>>4/ social coupling - 
> we have a target operating point which will be  >>>some 
> fraction of a bottleneck link  >>>if we take a flow f, and a 
> flux (sum of flows into a bottleneck) F,  >>>then the idea is 
> that we get a share proportional to the _resource_ we  
> >>>use, which (approximately) includes 1/RTT as a factor 
> (kelly et al, le  >>>boudec et al)  the idea is that a set of 
> fs in an F are coupled by the  >>>loss or ECN feedback 
> function, and by some reaction period being at  >>>least in 
> the same ballpark....  >>>  >>>in fact, though we don't have 
> to have smooth functions at all, nor do  >>>we have to sample 
> only the average loss rate, nor choose the sample  >>>rate to 
> be an RTT - the RTT is a way of _loosely _ coupling things,  
> >>>but is perhaps too strong  >>>  >>>what if someone wanted 
> a _rate_ that persited for all (or a larger
>  >>>part) of a connection? how could we work out some sort of 
> congestion  >>>model that accommodated both packet and 
> connection timescales?  >>>  >>>at least one factor seems 
> missing, and that is some estimate of the  >>>number (and 
> rate of change of number) of flows....if we alter the  
> >>>sample period, and sample bot hte hcongestion feedback 
> Mean, AND its  >>>variance, we might be able to (assuming the 
> social coupling function  >>>was still "social") estimate 
> this  >>>  >>>obviosuly if people want to they can behave 
> anti-socially (but that is  >>>and wil lalways be true unti 
> lwe do pricing or othewr forms of  >>>admission control) - 
> letsassume they behave "nicely"....  >>>  >>>could someone 
> choose to operate a "very slow" congestion control  
> >>>scheme? why not? lets say i run a connection that takes 
> 1/10 of the  >>>capacity, but there are 5 other connections, 
> then why should i react  >>>to loss unless my longer term 
> loss (or ecn) rate  tells me that  >>>there's now 9+ other 
> flows? currently,  if i run any adjustment  >>>scheme based 
> just on average, i have a chance of adjusting wrongly...  >>> 
>  >>>more importantly, maybe  >>>secondly, how about 
> re-examining the social coupling function? why  >>>shouldn't 
> ten people _agree_ a different congestion partition function  
> >>>(e.g. they have an application that requires n sources)  
> >>>  >>>i guess this could be implemented via the Congestion 
> Manager type API,  >>>but i am interested in the general 
> family of functions that fit this  >>>more general model - 
> for example, it seems to me that you can have  >>>radically 
> different increase/decrease if you have
>  >>>a) a different sample period and a more accurate 
> deascripotion of the  >>>evolutuon of the loss/load process 
> over time (e.g. some sort of fancy  >>>bayesian predictor)
>  >>>b) a different share/social function - e.g. if we have 10 
> sources  >>>agreeing on a different load, then how do they 
> distribute this  >>>information and how do  we make sure they 
> aren't penalized by any  >>>extra fancy stuff people might 
> later add!  >>>  >>>j.  >>
> 
>  cheers
> 
>    jon
> 
>