[e2e] "congestion" avoidance...

[Henning Schulzrinne]

<ad>
The trade-off between stability and incentives for
connections/flows/streams/... to back off under congestion has been the
motivation behind our RNAP work (see
http://www.cs.columbia.edu/~xinwang/public/projects/RNAP.html). I agree
that for anything more complicated than equal sharing, there needs to be
some monetary incentive (or a dictator that substitutes his/her
judgement for monetary incentives). We have looked at both IntServ-style
and DiffServ-style scenarios.
</ad>

Jon Crowcroft wrote:
> 
> 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)

I think the traditional examples are a bit flawed in one respect: their
pricing tends to be all-or-nothing, i.e., you can either fly to
Minneapolis for a certain price or you can decide not to fly. About the
only step in between is AirTran or other airlines where you trade
reliability and creature comforts for some decrease in fare. With
packets, we generally have a much larger operating regime. This would be
as if we could take out half the seats in a plane if the plane happens
to be empty.

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

At least from our simulations, this is not necessarily the case, as long
as you operate in a space where the capacity is large enough to
accommodate the minimal useful bandwidth for all comers. If you go
beyond this, the only alternative is to reject some flows altogether, to
prevent effective congestion collapse (where nobody gets beyond the
minimum usable threshold). The notion of this threshold obviously
differs between applications, with some having a more easily
identifiable lower bound than others. (For telnet, it's probably the
tail of the delay variation due to TCP timeouts that's the killer, not
raw bandwidth.)

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

We allow a trade-off: you can either get a price for the connection
duration or get a somewhat lower price if you adjust more frequently. As
long as the churn on the wire is sufficiently high, the adjustment
period is less important. The transit ISPs can act as a risk broker. If
you do have extremely large variations, so that the elastic part of the
demand cannot accommodate it, not admitting flows is about the only
alternative. (At least for now. Things get more interesting if the
congested ISP can buy another wavelength on the spot market.)

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

I'm not sure what kind of arbitrage you're talking about. Yes, you could
have somebody resell the bandwidth if they think that the long-term
price is a steal, but the downside risk is primarily a higher blocking
probability if too much of the capacity is locked up when the unexpected
demand arrives.

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

We have investigated both tatonnement and auctions, with different
trade-offs between efficiency and the amount of information you have to
reveal to the outside world.

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