The IP over ATM Mailing List Archive by date

[Tim Dwight <0006078043@mcimail.com>]

Joel said:

> Jon asks for some interesting possible services/packets/... for
> operation over ATM.  In doing so, he suggests and explicit congestion
> bit for the operation of TCP/IP on AAL5/ABR.
> 
> While I sympathise with the request, I am not sure, particularly in an
> explicit rate scheme, what it means.  Given that one is periodically
> getting allocations of bandwidth, what is the indication that some
> change in allocation should be considered "congestion"?  Any decrease
> in ones allocated rate?  A decrease of 50%?  Or something else.  In
> some sense the system is designed to operate in an environment that is
> always partially congested.  THe whole point of the system is to keep
> the operation away from the knee of the behavioral curve where congestive
> collapse occurs.  So what point along the allowed region is "congestion"?


Joel:

It seems to me this is a proper issue for an IP/ATM interworking function.

The network may convey congestion to the interworking function (the
point at which IP becomes ATM) in a number of ways.  The simplest is
a single bit ("Explicit Forward Congestion Indication" - EFCI).  The
ATM Forum's draft ABR specification also allows the network to communicate
a specific rate which the end-system is requested not to exceed.

So the question becomes, "what should the IWF *do* when it receives
such an indication?".  The common response is "nothing", but that's
not quite optimal behavior.

An alternative is "shape the outgoing traffic to conform to the indicated
rate".  This is possible, in fact some equipment does it, and has
the advantage of not requiring communication with higher layers.  But
it may not be desirable in all circumstances.  Maybe we don't always want
the higher layers to continue to blast away while the IWF chokes the
traffic down to a trickle.

This was how I interpreted Jon's suggestion - that maybe as yet another
alternative, the IWF could inform the higher layers and ask them to
slow down.  This is harder for a number of reasons (requires communication
between layers, possibly over a network, requires changes to established
upper layers) so we ought to make sure it's worth the effort.  If it
is, I'd like to see us tackle it.

Maybe the work belongs in another group, though;  that depends on how
general we make the solution.  I apologize for being relatively ignorant
of work going on in other WG's;  perhaps this is already being dealt
with somewhere?


Best Regards,

Tim Dwight
MCI