[e2e] "congestion" avoidance...

[Graham Cope]

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


Curiously, one of my little research topics (aka : headaches) is
delivery of high quality real-time video traffic for DSL networks.
Current operators use ATM backhaul networks and putting the video on
demand (VoD) traffic over CBR and the IP over VBR does nicely, although
you need some admission control for the VoD.
  Some operators are moving towards IP only backhaul networks (from the
DSLAM to the service centre). I'm yet to find an IP QoS mechanisms that
will give me the same assurance as the ATM, although Diffserv over MPLS
looks hopeful.
  Also, I estimate that over half the traffic in the core backhaul
network will be the brittle VoD traffic (2+Mbps per stream), with the
other other half elastic/BE IP. Overprovisioning looks uneconomic.

  Now let me add the next requirements from some customers...
    They want to send broadcast TV over the same network. This is best
multicast at a number of points, including the DSLAM itself. So, if we
use a diffserv over MPLS architecture this then gives a requirement for
Diffserv/MPLS Multicast QoS. 
   ...and BTW, the response time for channel zapping must be good (I'm
not sure of the KBHCA limit for IGMP messages in core routers).

In the short term we are sticking with ATM!
  ... but if anyone has a proposal for the equivalent IP solution I
would be very interested.

However, one advantage of this architecture is that it is all under one
administrative domain (perhaps with the operator and the service
provider working closely together) - from end customer to service node.
It therefore would need to rely on whatever the 'public Internert' does.


Just a thought,


Graham