Re: ATM Wide-Area Networks (was: sell shell accounts?)
"Good" ATM switches are doing Early Packet Discard and Partial Packet Discard. You can ask your favorite switch vendor for details, or look at the following for a nice summary: http://www.fore.com/html/atm-edu/whitep/FTBMWP.html -tjs I am not quite sure how an ATM switch becomes a "packet shredder," or even what a "packet shredder" is...
In message <199607232130.QAA20147@uh.msc.edu>, Tim Salo writes:
It becomes a packet shredder when it doesn't do EPD/PPD, dropping a small percentage of cells on overload but a large percentage of packets. You have to overprovision to start with. Also in the "dead horse dept" (I hope) unless you are dealing with boneheaded switch vendors. Some don't believe in EPD/PPD preferring ABR. Are any of them still entirely clueless in this regard and not doing either EPD/PPD or ABR? Curtis ps- still kind of partial to RED myself. :)
On Tue, 23 Jul 1996, Tim Salo wrote:
I am not quite sure how an ATM switch becomes a "packet shredder," or even what a "packet shredder" is...
An ATM switch shreds a 1500 byte IP packet into 29 ATM cells of 53 bytes each. If an ATM has a 5% loss, i.e. 1 in every 20 cells is lost, then 0% of the IP traffic will get through. This is a worst case kind of scenario but I'm sure you can see other scenarios where the 53 byte ATM transport could cause problems. For instance, if the first ATM cell containing a new IP packet gets lost, the switch may continue to transmit the other 28 cells in the packet even though these are now useless garbage data that don't need to be forwarded. The 7 layer model can be useful as an intellectual tool to separate the different mechanisms required to implement networks but it is wrong to assume that arbitrary combinations of layers can operate efficiently and effectively in the real world. Of course, ATM switch vendors are learning how to make their equipment handle IP packets better, and then there is Ipsilon http://www.ipsilon.com RFC 1953 and RFC 1954 Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
participants (3)
-
Curtis Villamizar -
Michael Dillon -
salo＠msc.edu