[e2e] "congestion" avoidance...

[Jon Crowcroft]

In message <3ADC3EE3.E34A950A at cs.columbia.edu>, Henning Schulzrinne typed:

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

i'm wondering whether this is because you have used conservative
parameters for the access capacity?

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


so my model is this

we have a range of social models users can choose ferom - they can
subscribe to a "social model" server - it could be like napster or
better like gnutella, and offers a market in capacity for peoppe in 
that social - the SUM of the usersd capacity is "tcp like" but within
this ,they get to choose,. based on which server they subscribe to

one server might offer stable price over session life, anoher might
offer dynamic price on a packet timescale.

servers can implemnt a range of different strategies  - e.g. it might
schedule each persons session over a long period (i.e. n sessions arrive
at once, but are scheduled to compelteion, one oafte th other serialy)
or it might interleave them in burst,s or it might be RAP or TCP Like
or otherwise....

now, some users WANT to have different rules than others (e.g. a set
of multiple sources in a game versus a set of independant web
downloaders or browsers)

so thisis a market of markets, where we make the current rule (TCP) a
meta rule but peopel can have local divergence...
 >>
 >>> 
 >>> 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.
 >>>  >>

 cheers

   jon