[e2e] "congestion" avoidance...

[Tom Kelly]

Jon,

I've done some work on the viability of integrating TCP and non-TCP
traffic in an ECN enabled IP network where the non-TCP flows get turned
away when there is not spare capacity. It is available from:
http://www-lce.eng.cam.ac.uk/~ctk21/papers/dacprobe.ps.gz

With the endpoint admission control scheme described in the paper,
non-adaptive flows do behave adaptively in aggregate, exactly how they
adapt is set with one endpoint parameter (which in effect is the
threshold at which you decide a network has spare capacity).
The routers only need to use simple ECN marking algorithms; varying the
marking scheme dependent on packet type or looking for flow initiations
appears unnecessary. The study also considered a variety of operating
conditions; in particular it appears to work when a network is carrying a
large amount of web traffic.

In effect the scheme allows you to carry non-adaptive real-time traffic
when there is spare capacity in an IP network (which is ECN enabled) with
a simple end to end control mechanism.

There are still some open issues:
- How does the scheme degrade as the aggregates/links become small?
- How do you ensure that endpoints use congestion control? (Also how
do you ensure that endpoints use a sensible admission parameter).
- The scheme is premised on ECN being widely deployed and using sensible
marking algorithms. This may not be a fair assumption.

Hope that helps,
Tom

On Thu, 19 Apr 2001, Jon Crowcroft wrote:

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