The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Feb> msg00128



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re : some experience on ip over atm....

  • From: Tim Dwight <0006078043@mcimail.com>
  • Date: Fri, 24 Feb 95 09:55 EST

Curtis said:

> There is a more difficult problem for ABR to face.  Last I looked at
> an ABR proposal (which may have cheanged), they were sending feedback
> on the order of milliseconds.  This may be OK for a LAN, but may cause
> terrible problems for a WAN, where the feedback loop is at least tens
> of milliseconds and can be 100 milliseconds.

Current ABR algorithms mandate end-system behavior but only provide
switch/network behavior as examples.  Of course some end-system behaviors
are based on assumptions of what switches can or will do;  for instance,
the Resource Management (RM) cell originated by the source contains
the source's allowed and actual sending rates, so that the switch can
approximate its instantaneous load and thus determine whether it's
congested.

Bad things happen if sources don't tell the truth (and because
there's no definition of how a source computes its "actual" rate, differing
implementations seem likely).  But I digress... 


> A problem that has been observed in the Internet already is
> sychronization of bursts in wide are TCP traffic.  I've tried to point
> out here that this can occur over an ABR ATM WAN causing a very large
> burst at an ATM switch.  If you are talking about a small number of
> high speed flows, this can very easily happen.  It has also been
> observed with a very large number of flows.

Your point is well taken, as is the one re. granularity of control
vs. length of control loop.  There is a conceptual difference between
ABR, which assumes a source's rate to be pegged at a given level until
feedback is received, and periodic sources like TCP which will likely
burst beyond their assigned rate, then back off voluntarily before
feedback arrives.

I wish I knew of an effective way to use TCP as is over ABR, but I
don't.  Suggestions are welcome.


> Simulating TCP over ABR would be a very useful exercise.  I have yet
> to hear of anyone who has done it and is willing to discuss the
> results.  If anyone has, please let me know.  (btw- poisson studies
> and studies using simulated bursty data don't count, simulated bursts
> don't tend to synchronize like protocols that employ long delay
> feedback.

I agree whole-heartedly.  For this reason my contribution atm95-0077 to 
the February ATM Forum, proposed a set of guidelines for modelling
TCP/UDP/IP over ATM (sorry, neglected RTP).  It was accepted as a baseline
for future work;  which means it's possible to improve it via further
contributions.  I hesitate to post the text here only because it's
a bit long;  but if anyone wants a copy please email me directly and
I'll forward it.

Helen Chen of Sandia Labs has simulated TCP-over-ABR, and she believes
she has a valid TCP model (I haven't seen it, have no reason to doubt
her).  However, the source above TCP was poissonian.  Granted such cases
probably occur;  but they don't in my opinion tell us much of interest about
TCP.  Worse, they give false hope to the uninformed (Helen's results showed
the source arriving at a steady state equal to its fair share of the
bandwidth, then staying there with zero packet loss.  Oh that it were so...)

Tim Dwight
MCI