Re: Q:Why router with ATM interface comes out earlier than pure SONET interface?
| >One other fallacy here: ATM and POS do not provide the same effective | >bandwidth when used as an IP transport. Due to the high encapsulation | >overhead and the sizing overhead of fitting packets into cells, ATM has | >proven to be about 20% less efficient at carrying packets than SONET. | >While this is probably not an issue in a campus or within a building, the | >implications for long lines is enormous. | > | | Okay, so given all the great features that ATM is supposed to have | and the only thing that really sucks about it is the overhead due to the 53 | byte cell size, the obvious question is why can't there be an ATM standard | with, say, 197 ( 4 times the current 48 byte payload) or even 389 ( 8 | times 48 ) byte cells? | Is there something magic about 53 or is the IP over ATM application | still so 'obscure' that there is no interest? Increasing the cell size lowers the efficiency further. 53 is an ATM architectural constant. Change it, and it's no longer ATM. Change it, and you're no longer interoperable. Tony
| Okay, so given all the great features that ATM is supposed to have | and the only thing that really sucks about it is the overhead due to the 53 | byte cell size, the obvious question is why can't there be an ATM standard | with, say, 197 ( 4 times the current 48 byte payload) or even 389 ( 8 | times 48 ) byte cells? | Is there something magic about 53 or is the IP over ATM application | still so 'obscure' that there is no interest?
Increasing the cell size lowers the efficiency further.
53 is an ATM architectural constant. Change it, and it's no longer ATM. Change it, and you're no longer interoperable.
Tony
Why not just make ATM variable cell size altogether? Tongue planted firmly in cheek, Chris PS: Actually, overhead is not "the only thing that really sucks". Being connection-oriented at the transport layer is another. -- Christian Kuhtz, BellSouth Corp., Sr. Network Architect <ck@bellsouth.net> 1100 Ashwood Parkway, Atlanta, GA 30338 <ck@gnu.org> "Turnaucka's Law: The attention span of a computer is only as long as its electrical cord." -- /usr/games/fortune
At 06:32 PM 8/3/98 , Christian Kuhtz wrote:
| Okay, so given all the great features that ATM is supposed to have | and the only thing that really sucks about it is the overhead due to the 53 | byte cell size, the obvious question is why can't there be an ATM standard | with, say, 197 ( 4 times the current 48 byte payload) or even 389 ( 8 | times 48 ) byte cells? | Is there something magic about 53 or is the IP over ATM application | still so 'obscure' that there is no interest?
The old story was that the Telco guys wanted 32 byte payload and the data guys wanted a 64 byte payload and the ITU split the difference. Go figure. TORRENT NETWORKING TECHNOLOGIES CORP Next Generation Routing and Services George Janosik Sr Systems Engineer New Business Development 412.851.1103 gjanosik@torrentnet.com <http://www.torrentnet.com/>http://www.torrentnet.com
On Mon, 3 Aug 1998, Tony Li wrote:
Increasing the cell size lowers the efficiency further.
53 is an ATM architectural constant. Change it, and it's no longer ATM. Change it, and you're no longer interoperable.
If the cell size was 1505 or larger would it still be lower efficiency than 53 bytes? Sooner or later they'll probably try to come up with ATMng won't they? -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com Check the website for my Internet World articles - http://www.memra.com
If the cell size was 1505 or larger would it still be lower efficiency than 53 bytes? Sooner or later they'll probably try to come up with ATMng won't they?
It is already here. Called IP. IP over SONET. With lots of IP QoS mechanisms bolted on. That is, if somebody can figure out a way to do private line (circuit emulation) through an IP cloud. ATM will be an interim step, in my opinion. Cheers, Chris -- Christian Kuhtz, BellSouth Corp., Sr. Network Architect <ck@bellsouth.net> 1100 Ashwood Parkway, Atlanta, GA 30338 <ck@gnu.org> "Condense soup, not books!" -- /usr/games/fortune
participants (4)
-
Christian Kuhtz -
George Janosik -
Michael Dillon -
Tony Li