Subject: RE: QoS and adaptive end protocols

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 21 Jun 2000 11:28:46 -0400

> -----Original Message-----
> From: Dan Grossman [mailto:[email-masked]]

I had written:

> > It seems that
> > protocols which adapt at Layer 4, mainly TCP, do very 
> poorly when the lower
> > layers adapt on their own. What results seem to show is 
> that allowing TCP do
> > do its thing over a best effort network is preferable to 
> TCP over something
> > fancier, like ABR ATM.
> > 
> This seems to be an urban myth.  I did a quick search through 
> netbib a few months ago on this subject, and found that there 
> was no consensus in the published literature.   A lot 
> depended on whether the ATM network did explicit rate or EFCI 
> control, how much buffering was present in the edge 
> router/ATM end system (or host/ATM end system) devices (I did 
> not see any papers that showed the effects of active queue 
> management in these devices) and the usual simulation issues. 
> I don't think that there is any basis for conclusion based on 
> the existing literature.

Several years ago, when ABR was being implemented, I distinctly remember
reading articles which showed that UBR with EPD/PPD did consistently better
than TCP over ABR. Maybe it is an urban myth, but it seems to have become a
popular myth.

> I have been told that there are large deployments of IP over 
> ATM with ABR, and that they have excellent goodput (sorry, 
> that's about as much as I can talk about).  Unfortunately, I 
> don't expect to see any published measurement results from 
> these networks.

Nor comparisons with what they could do with plain old UBR and EPD/PPD.

It doesn't surprise me, though, that TCP would not do well with another
feedback loop under it. Why is that surprising? It's the same thing that
occurs with _any_ control system with layered feedback loops. Unless you
know exactly what you're doing, you can easily get into oscillating or
unpredictable behavior. For example, if the time constant of the underlying
feedback loop is longer than that of the upper layer loop, you're in
trouble.

Bert
[email-masked]

---

From: Dan Grossman <[email-masked]>
Date: Wed, 21 Jun 2000 13:49:40 -0400

<snip>
> than TCP over ABR. 
Sure.  But remember that a lot of advocacy pieces were being written to either 
tout or debunk the benefits of various approaches.  Some of them were not what 
you'd call very good science.  I recollect a few papers of the kind you 
describe.  These were all assuming EFCI-based ABR, at early stages of 
development.  Some of them also assumed very small buffers at the edge router, 
and none that I'm aware of had active queue management of any kind in the edge 
routers.  On the other hand, Raj Jain's group at OSU did a number of advocacy 
papers, at least one of which showed _better_ performance for TCP over ABR 
with their algorithms than for TCP over UBR.
> Maybe it is an urban myth, but it seems to have become a
> popular myth.
All the more reason to try to clear it up here.  A couple of months ago, I 
privately took an author (for whom I otherwise have great respect, else I 
wouldn't have bothered) to task for a journal paper which repeated this myth 
without references.   Unfortunately, these claims, repeated over and over 
without validation, become accepted as truth.

> Nor comparisons with what they could do with plain old UBR and EPD/PPD.
Sure, but those are well characterized in the literature.  If we had a good 
characterization of ABR performance in sensible implementations, comparison 
would be an exercise for the reader.

> feedback loop under it. Why is that surprising? 
It's not surprising,   It's just a poorly tested assertion.  Perhaps it's 
true, perhaps not, perhaps results will vary based on assumptions and 
parameters.

> It's the same thing that
But of course the opposite is the case here.  ABR with ER has a time constant 
of 1 RTT across the ATM network. In order to prove your point, you'd have to 
come up with a control-theoretical model.  Which I understand would be very 
hard to do. 

Dan