The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re : some experience on ip over atm....
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 |
|