[e2e] "congestion" avoidance...

[Jon Crowcroft]

In message <45FFD0863780BF48856035CBD7E450C10149FE39 at red-msg-02.redmond.corp.
microsoft.com>, Peter Key typed:

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

so anyhow, thinking more abotu the _scaling_ questions

lets say we want to offer the user
a shadow price for a packet, or a shadow price for a
flow/session - these have different timescales of variation

under what circumstances can we make the _same_ mechanism 
(i.e. RTT timescale feedback via ECN or loss or any congestio
nsignal) apply to both? 

i would assert that it is time to invert the usual wisdom about
CBR and VBR _ often, people assume somethign that is just historical
"accident"  -  that we design networks for circuit traffic, and then
notice that at low ebb, there's spare capacity , and it should be
avaialble for datagram/adaptive traffic...

lets assume we now design networks for datagram, with TCP "friendly"
adaption being the NORM, and that we look at the people that need
predictable throughput on the session timescale as the odd ones
out...(predictable price or predictable throughput are natural
duals of each other in this formulation)

now if we have _enough_ of these non-adaptive flows, actually, enough
rate of change of them, they can collectively be made to look like a
bunch of TCP-like flows quite easily - by varying the admission
probabiliyu (could do this by increasing the loss or ECN markign
probability for SYN or RTP equivalent packet - but thats an
implementation detail, - it could also just be done by varying the
price differently for these type flows as yo usay - e.g. the ECN to
price mapping for EF diffserve class might specifiy a different
fucntion than that for BE and AF, for example:-)

so then we can cause the aggregate of a set of CBR flows
to behave exactly like the aggergate of a set of TCP flows just by
varying the number of flows

what say we do some analysis...?

of course, on an access link (e.g. 56k modem, 30kbps GPRS, up to few
100kbps xDSL or cable modem) then there isn't a lot of room for this
sort of equivalenance, so we'd see soemthing more traditional....

what is the operating regime where this formulation makes sense?

j.