- Test - lists.nanog.org

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 29 Mar '96

29 Mar '96

Steve Steinberg <steve(a)wired.com> wrote: >I was talking with David Tennenhouse yesterday about why much of the >Internet community hates ATM and he said something that seems very >accurate: "Everyone worries about overhead in someone elses layer." Heh. He's telling that to carrier ISP people who are generally quite involved in level-2 transport issues? 30% of bandwidth is something to think of, when it costs more than all your equipment. >It's true: just think of how much TCP/IP overhead we put up with that >could be compressed if it was really important. Have you ever asked why IP compressors were't a smashing success? Answer -- because most of bulk traffic on Internet is compressed by hosts (be it GIF or JPEG, or good ol LZW compress). You can't really compress much of headers necessary for end-to-end reliability without per-hop header reconstruction (that is done on very slow links by PPP and C-SLIP, you can do that on T-1s with difficulty, but forget about in on T-3s). >(Not to mention HTTP overhead...) HTTP is being fixed. ATM is beyond repair. >Perhaps more importantly, stepping up fiber bandwidth is a >lot easier than improving router speeds. So why does a 15% loss due to >ATM really matter? It's 30%, for starters. There's a lot of short ACKs and keystrokes. Then, if "stepping up fiber bandwidth" isn't really a big deal why do we need ATM's QoS stuff? Just throw in more bandwidth! >Tennenhouse, btw, is proof that ATM did not come out of the telecom >community alone as people like to believe. You can write a FORTRAN program in any language. You can be a bellhead without being employed by a telco (and vice versa). >It's no suprise that they went with something like ATM that's good for >switch efficiency but bad for transmission line efficiency. That's a hogwash. ATM is bad for switching efficiency. That's obvious to anybody who ever heard about relation between size of memory footprint and speed, and can compare number of forwarding decisions per byte of user payload in IP and ATM. >Fortunately, that was probably the right tradeoff to make. That's apparently why there's no global ATM network on horizon but you can find Internet in Ust'-Kamenodyrsk. --vadim

1 0

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

At 09:48 PM 3/28/96 -0800, Paul A Vixie wrote: > >Where's Padlipski when we need him? > Running IP datagrams across barbed-wire, methinks. ;-) > >What ATM has is an excellent set of buzzwords and a lot of vendor support. > >What IP has is an actual market with real end-to-end products and users. > Therein lies the thrust, Paul. Folks need to devise a more 'real-world' concept of acceptable long-haul data transport services. - paul

1 0

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

At 01:12 AM 3/29/96 -0500, Shikhar Bajaj wrote: >> >> What you fail to mention, however, is that in an effort to achieve >> these noble goals across the Internet, you are relegated to using IP >> over ATM. This is the fatal flaw. >> > >Yes, I admit my guilt. Our clients are looking at solutions in >parallel with the Internet. They feel that sole reliance on the >Internet will not cut it. > >> Sorry. I remain unconvinced. > >That's fine. I'm not trying to sell anything to anyone :). > No -- I didn't mean to appear sanctimonious or self-righteous. This just happens to be one of my pet rants. If folks want ATM services, running then adjacent to the Internet is a foolish thing to do. Parallel to the Internet fabric is certainly doable. - paul > >Shikhar >

1 0

Re: SONET Interconnect (was RE: MCI)
by Sean Doran 29 Mar '96

29 Mar '96

Someone suggested to me that it's because so much money has been spent on developing the technology that it HAS to be used in order to recover the investment. This may be somewhat apocryphal, but it's eminently believable. Sean.

2 1

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

At 10:48 AM 3/26/96 -0500, Shikhar Bajaj wrote: > >Currently, the only way of doing this is the "traditional way" of using >SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into >an STS-12 and then mux the 12's into a STS-48. This is what we are doing >in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA and DoD. >(see http://www.atd.net/atdnet.html) > >As per our previous discussion, the trend seems to be putting the switching >and transport functions in one box so that you may be able to buy an >ATM switch that also does SONET protection switching. > I fail understand, however, why ATM over SONET is desirable when there is such a loss to overhead, especially when viable alternatives may exist to get more bang-for-the-buck. Perhaps someone could enlighten me on this particular datapoint? - paul

3 2

Re: SONET Interconnect (was RE: MCI)
by bajaj＠bellcore.com 26 Mar '96

26 Mar '96

Bharat, > Has there been any thought given to How the OC-3c signal from a router > will be connected to a OC-48 or 192 signal in a typical SONET ring? Currently, the only way of doing this is the "traditional way" of using SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into an STS-12 and then mux the 12's into a STS-48. This is what we are doing in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA and DoD. (see http://www.atd.net/atdnet.html) As per our previous discussion, the trend seems to be putting the switching and transport functions in one box so that you may be able to buy an ATM switch that also does SONET protection switching. > I would think that the SONET vendors (Alcatel, Fujitsu, etc) would have to > work with the router vendors to ensure that SONET overhead information > is passed properly to the higher level signal. This overhead provides > data on performance, net management, etc. The kicker here is that SONET > contains undefined overhead bytes that many vendors have used for > proprietary services. This is the reason why different vendors' > equipment cannot be mixed within the same ring. The CMISE set of > standards is supposed to take care of incompatibilities, but as with any > other standard, it will be complete years from when it is needed. The SONET standards (at least for frame and overhead) generation are well documented so that router vendors, theoretically, should not need to work with traditional SONET vendors to get transport and framing functionality. For ATM over SONET, there are also a number of chips/chipsets which will perform SONET framing. PMC-Sierra (which FORE Systems uses) and IGT immediately come to mind (and I know that I have missed some others). Of course, if a router and SONET vendor want to work together to also offer some value-added functionality, that is an issue. You are entirely correct that many vendors have used the undefined overhead for proprietary services. The most common overhead used are the growth bytes (Z-bytes) and DCC bytes (D-bytes). In many cases, those bytes are used to pass proprietary messages for network element control and maintainance. That is a major reason why you don't see multiple vendors on the same ring. More than likely the transport would work fine but the OAM would be a nightmare. If and when the vendors fully implement CMISE, that would solve a lot of headaches. Until then, we have to deal with a mixture of partial CMISE support, proprietary interfaces, and TL-1 (Transmission Language-1, an old Bell System management protocol). In lieu of this (and other factors), it is not surprising that strategic partnerships between carriers and vendors are so common. Shikhar

1 0

SONET Interconnect (was RE: MCI)
by Bharat Ranjan 26 Mar '96

26 Mar '96

Has there been any thought given to How the OC-3c signal from a router will be connected to a OC-48 or 192 signal in a typical SONET ring? I would think that the SONET vendors (Alcatel, Fujitsu, etc) would have to work with the router vendors to ensure that SONET overhead information is passed properly to the higher level signal. This overhead provides data on performance, net management, etc. The kicker here is that SONET contains undefined overhead bytes that many vendors have used for proprietary services. This is the reason why different vendors' equipment cannot be mixed within the same ring. The CMISE set of standards is supposed to take care of incompatibilities, but as with any other standard, it will be complete years from when it is needed ;-) mm mm sssss nnnnnn * Bharat Ranjan * m m m s nnnnnnn * Network Engineer * m m m sssss nn nn * Microsoft On-Line Services * m m s nn nn * (206)-936-0471 * m m sssss nn nn * bharatr(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* >

1 0

ATM ABR service
by Kent W. England 25 Mar '96

25 Mar '96

At 12:18 PM 3/25/96 -0500, Curtis Villamizar wrote: > >Due to some poor initial choices in equipment (mostly due to a lack of >useful ATM choices at the time) PacBell got an early reputation for >moderate loss at very low throughput. They put their customers >requiring "high speed" on a single FDDI ring, which is the same things >causing trouble at MAE-West, soon to be upgraded. Curtis; The Newbridge ATM switch was selected over three years ago. The new Stratacom BPX (10Gbps) switches are now in place and working for NAP service. The Newbridges are still in service for other applications. > >Perhaps after the transition to the ABR capable switch, assuming also >that the router adapters will respect the RM cells and can all agree >on RFC1483 (and in addition RFC1577 would be nice), the PacBell NAP >will be a technically viable alternative. I think it's a bit optimistic to expect ABR routers real soon (the standard is still pretty fresh), but the BPX will emit EFCI notification, so the routers can use that if they want. > >On a technical note, I'm not excited about ABR's concept of fainess. >I don't see the value to giving the VC to some small provider a fair >share of bandwidth outbound from the NAP as is given a large provider >with 2-3 orders of maginitude more TCP flows on the VC. It is not >technically feasible to set up a VC per large provider flow, and there >is no way to weight the VC. I'd prefer EPD/PPD since someone is >likely to be congested. > >For example, consider traffic to provider A. Provider B and C each >provides 25% of the egress traffic. There are 10 other providers >pushing 5% each when things get congested. Provider B and C will be >losing 80% of their traffic before the others see any loss, even if >those providers only have a handful of users some of which are doing >wasteful things like running multiple unicast CuSeeMe flows. If >provider A is a small provider with a low speed link, the problem >isn't due to provider B and C. Provider A has too little egress >bandwidth, yet only traffic from B and C is affected. > If what you want is an "admit all with best effort" quality of service then we should configure the NAP for UBR service and let each connection or path fight for bandwidth "fairly" according to WFQ (if available in the routers) or FIFO and TCP congestion avoidance. If what you want is a "allocate minimums, share the rest" quality of service then we should use ABR and set the minimum cell rate according to what the parties to each circuit want. What do NAP customers want? WFQ/FIFO sharing or pre-allocated ABR? >This is a fundamental problem due to the need for hard state (separate >VC per actual user flow) to affect ABR (as opposed to no state at all >for EPD) and the infeasibility of setting up this hard state. > >Curtis It might make sense to map each flow onto a separate VC when that flow is a campus network flow, but I don't think that scales to something the size of the NAP. --Kent

1 0

Re: MCI [ATM overhead]
by salo＠msc.edu 25 Mar '96

25 Mar '96

> Date: Thu, 21 Mar 1996 15:09:51 +0800 > From: avg(a)postman.ncube.com (Vadim Antonov) > To: jogden(a)merit.edu, nanog(a)merit.edu > Subject: Re: MCI [ATM overhead] > [...] > The pricing on ATM transport is merely an artefact of "pilot" > status of ATM networks. Carriers lose money on that. When > market will be established the prices are bound to rise to > that of native IP transport, or, likely, more (as ATM does not handle > levels of overcommitment found in IP backbones now). > [...] Hmmm... Does that imply that the NSP that can take advantage of underpriced services, (perhaps including ATM, if you are correct), will have a competitive advantage? -tjs

1 0

Re: MCI [ATM overhead]
by salo＠msc.edu 25 Mar '96

25 Mar '96

> From: jon(a)branch.com (Jon Zeeff) > Subject: Re: MCI [ATM overhead] > To: salo(a)msc.edu (Tim Salo) > Date: Thu, 21 Mar 1996 09:04:44 -0500 (EST) > Cc: wolfgang(a)whnet.com, nanog(a)merit.edu > > > Line Rate 155.520 Mbps > > Available to ATM 149.760 > > Available to AAL 135.632 > > > The reader can apply their favorite packet size distributions to these > > numbers. > > Having said all that, I am not sure where that leaves us. > > That leaves us with the throughput of two DS3 links. It doesn't seem worth > the effort given how short term a solution it is. I am not sure I follow your arithmetic. The line rate on a DS-3 is 44.736 Mbps. You need to subtract several overheads from that: at least some DS-3 and some PPP overhead. How does that add up to half of the throughput of an OC-3c IP/ATM link? As long as I took this opportunity to inquire, what to you mean by "given how short term a solution it is?" -tjs

1 0