[e2e] "congestion" avoidance...

[RJ Atkinson]

At 03:40 19/04/01, Jon Crowcroft wrote:
>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?

        On the residential networks I'm familiar with, a recurring
problem is that *most* of the actual IP multicast traffic observed
is non-responsive to congestion.  Our working theory was that 
the traffic was from multi-player computer games, but it was
never quite nailed down.  

        Having some mechanism for dealing with such traffic 
to externally make it responsive to congestion would be 
both interesting and useful, IMHO

Ran