The IP over ATM Mailing List Archive by date

[Tim Dwight <0006078043@mcimail.com>]

Joel said:

> Unfortunately, I know fo no good way to handle propagating the
> "congestion indication" outside of a box.
> 
> Inside a single box (host, etc), propagation is a local matter.  There
> might be some API work to help, but that is about it.
> 
> If we are talking about IWF  (say, for example, a router) then we get
> into a protocol problem.  IP does not have a "congestion experienced"
> bit, not does it have a "backwards congestion noticed" bit.  These are
> extremely unlikely to be added, even to IPv6.  (Someone tried recently
> to add them to IPv6, and did not get very far.)

Yes, I agree.  Protocol extensions are harder.  I suppose if you had
an API extension to handle intra-box communication, and you had a 
suitable protocol extension, then the protocol information would be
conveyed using this same API.  So maybe one is a subset of the other.
And I suppose we can consider, whether the API stuff needs to be
standardized/specified/whatever.

> 
> In addition, Source Quench is a serious network mistake.  It expands a
> problem even as it is occurring.  Bad behavior.

I know we had bad experience with source quench.  I hope we can avoid
debating that, also that we can avoid using this single experience
as some sort of "proof of the negative" (i.e., a supposed proof that
because we failed once, it can't be done).

I would rather consider generalizing the problem from "conveying
congestion" to "conveying available bandwidth".  This addresses, I
think, the problem of waiting until you're in trouble and then
generating more packets to try and recover.  I give suggestions below.

> 
> Hence, I am not sure what an IWF could do.  I would be interested in
> any viable (or even halfway viable and a quarter baked) ideas.


OK, here's a thought.  Suppose we defined a new ICMP message, to convey
the available bandwidth in the network.  Hosts which don't understand
it, ignore it.  IWF's somehow figure out which hosts support it (e.g.,
by configuration, or by a handshake of some sort, or by observing host
behavior) and modify their behavior accordingly (don't nag hosts
by sending unsupported messages, but also have some way to accomodate
host upgrades).  Hosts which support it, use it to modulate their
transmission so as not to exceed the network's capacity.

We would need to define:

     - what is the content of such a message?

     - what is a host supposed to do with it (Sally Floyd's paper
       ee.lbl.gov/papers/tcp_ecn.4.ps.Z has some ideas).  There may
       be multiple answers - e.g., what does IP do, what does TCP do,...

     - how does the IWF translate the types of congestion or explicit
       rate information it receives, into this new message.  It would
       be *real nice* to dovetail this with the ATM Forum's ABR spec.

     - how does the IWF treat hosts which support this mechanism, vs.
       hosts that don't.  For example, we wouldn't want non-supporting
       hosts to be rewarded.  Some sort of fairness mechanism at the
       IWF, seems useful.

     - how does the IWF figure out which hosts do/don't support this new
       message.

     - what are the expected improvements, both to the network and
       to the host.  How do they compare to what is achievable using
       either of the current mechanisms:

          - nothing
          - shaping applied by IWF at ATM layer, to all data on the
            associated connection

     - probably a host of other stuff.


Best Regards,

Tim Dwight
MCI