[e2e] "congestion" avoidance...

[Jon Crowcroft]

In message <Pine.SOL.4.33.0104191145480.2847-100000 at green.csi.cam.ac.uk>, Tom
 Kelly typed:

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

ok, so i would suggest one more thing to look at (follows naturally
from section 6.2..)

currently, there's no explicit distance related charge to TCP,
just the implicit one...
whereas the expectation of VOIP users might (might!) be that there
would be an explicit (and possibly aggresively non linear), so in 
followup work,
you should look at the erlang stuff for the voice call 
distributions and see if it helps (i'd expect it to)
 >>
 >>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.

you need to have virtual buffer systems, which may be tricky for
some router h/w too...
 
 >>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.
 >>>
 >>

 cheers

   jon