- NANOG - lists.nanog.org

Re: Cisco's AIP vs HSSI
by Kent W. England 16 Oct '96

16 Oct '96

At 02:15 PM 15-10-96 -0400, Avi Freedman wrote: >> ..., IMHO, you really need PPP. > >We run PPP on all non-frame-or-smds and less-than-DS3 links so that >the customer (or ourselves, if it came to it) could switch to non- >Cisco gear instantly. > >But we usually leave most cisco-cisco high-speed links at HDLC. >My impression is that HDLC was the same efficiency - or moderately >more so - than PPP. There are about three flavors of HDLC encapsulation, one of which is cisco and because of that the others don't matter. There is precious little difference between all the flavors of HDLC and PPP, they all carry the old OUI/Ethertype/etc overhead. And the efficiencies of all are the same compared to SMDS or ATM. > >For what do feel that one *really* needs PPP? > Well, that's it -- I don't assume that the whole world is cisco, but I'm a bit naive. Of course there are other hooks in PPP that are useful, since PPP, like BGP, is a Swiss Army knife protocol, but again since the whole world is cisco, let BGP figure everything out and run HDLC. You don't really need PPP in an all cisco backbone. But I like PPP because cisco still doesn't document their HDLC line protocol. :-) (Go ahead, try to find it online or ask someone on one of the tech support lists to find it for you. :-) --Kent I'm kidding. Of course I love everything about cisco, since as Dave O'Leary has told me for a long time "Sooner or later everyone ends up working for cisco" and he seems to be right.

1 0

RAToolSet 3.4.1 is available for anonymous ftp
by Cengiz Alaettinoglu 15 Oct '96

15 Oct '96

RAToolSet 3.4.1 (contains RtConfig and Route Object Editor in addition to other tools) is now available at http://www.isi.edu/ra/RAToolSet ftp://ftp.isi.edu/ra/RAToolSet The ftp directory also contains binaries for selected architectures. We can make binaries for other systems available upon request. RAToolSet 3.4.1 compiles out of the box for the following systems: SunOS, Solaris, OSF/1, BSDI, FreeBSD, linux, and probably on other systems as well. There is also a mailing list, ratoolset(a)isi.edu. To join, please send a message to majordomo(a)isi.edu with body containing subscribe ratoolset In the upcoming Nanog, there will be demos of these tool. Bug reports, fixes and suggestions for improvements are welcome and appreciated. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

1 0

Parking info for NANOG Meeting
by Pam Ciesla 15 Oct '96

15 Oct '96

There is LIMITED PARKING in the Thompson Parking Structure (ONLY) located on Thompson St. about 1 block from the MI Union. Please park your car on the 2nd level and up (do not use the 1st level). You will need to come into the meeting site to get a parking pass and return to your car to put it in your car. Please NOTE that if you get a ticket while doing this bring it to me and I will take care of it. PARK IN STAFF PARKING. NOTE: THIS IS A FIRST COME FIRST SERVE POLICY. HOTEL SHUTTLES ARE HIGHLY RECOMMENDED. Pam Ciesla ps There are no meters available in the Thompson Parking Structure, please use Staff Parking spaces. Sorry for any confusion.

1 0

NANOG Registration
by Pam Ciesla 15 Oct '96

15 Oct '96

The list of attendees for the NANOG Meeting has been updated. If you are not on the list and should be please contact me. NOTE: THIS IS LAST CALL FOR REGISTRATION FOR THE OCTOBER NANOG MEETING Hotels that were blocked are no longer available. Please check other hotels list on the WEB page also check the Crowne Plaza 313-761-7800. If you need any info please contact me. Thanks Pam Ciesla

1 0

Re: Cisco's AIP vs HSSI
by salo＠msc.edu 15 Oct '96

15 Oct '96

> From: bmanning(a)ISI.EDU (Bill Manning) > Subject: Re: Cisco's AIP vs HSSI > To: freedman(a)netaxs.com (Avi Freedman) > Date: Tue, 15 Oct 1996 07:55:50 -0700 (PDT) > Cc: bmanning(a)ISI.EDU, salo(a)msc.edu, kri(a)bellcore.com, nanog(a)merit.edu > [...] > The orginal question can be paraphrased as; "which > board is better" (see the subject line). > Tim S. couched his replies in the form of an ATM only > solution. I feel that the HSSI board was not designed > as such. Your comments seem to back up my assertions. The HSSI card was not designed as an ATM solution. The HSSI ATM solution involved, in some sense, making the ATM network look like a frame relay network to the HSSI card. > I would claim that for raw throughput, and assuming > the DS3 daughtercard for the AIP, that the HSSI board > delivers more useful bits at the expense of an outboard > CSU. This is based on my feeling that HDLC is more efficent > than ATM signaling/framing. If the context of the question is the most appropriate interface for a point-to-point connection between two routers, I would worry more about throughput than, for example, issues of ATM versus HDLC functionality and overhead. The AIP card can obviously clock out data a lot faster than can a HSSI board, (assuming you don't intentionally put a slow interface on the AIP card). However, I think it is also important to understand the throughput of the two boards and how well they are integrated into the Cisco (or, in general, your favorite vendor's) router. I was under an impression that the HSSI card was a lower-performing board, but someone with some more detailed understanding should provide some insight. I suppose my answer could be refined as: o If you need an ATM solution, use the AIP card. o If you merely want a DS-3 or slower point-to-point link between two routers, test both solutions, (or talk to someone who has), to determine which solution has better performance; or o If you want a point-to-point connection between two routers at speeds faster than HSSI can support (a bit more than 45 Mbps, I think) use the AIP card. Again, you should also consult your router vendor. They should be giving you all this information and more. For example, you might discuss a OC-3c IP over SONET solution for point-to-point connections. -tjs

1 0

Re: cable modems [Re: Intra/Inter - was Inet-II]
by Kent W. England 15 Oct '96

15 Oct '96

At 09:01 AM 15-10-96 -0700, Milo Medin wrote: >Really Ken, just because you consult to PacBell, you shouldn't be so >obvious in your posturing. :-) Well, Milow, it's hardly posturing. More a gesture. :-) Everyone who's been to NANOG knows that I work for PacBell on the NAP. I believe that you yourself were once a consultant for a long stint at Ames, working for Sterling Software before you stepped over and became a government employee? I don't think you can so easily discredit me for being a low-life self-prostituting money-grubbing consultant. But nice try. I'm sure you've read the Upside article and the issue it raises regarding TCI's investment in the necessary cable plant upgrades to support @Home? > >Cable modems by themselves don't don't the performance problem, in fact, >that's what @Home has been talking about for sometime now, and why we >believe you have to build an intelligent network architecture, not just >dumb pipes. That is certainly true and no one better to architect a data network that works for the web than you. An xDSL network needs the same kind of caching and replication as you are designing into the @Home network for the same reasons. Fortunately, it isn't rocket science (to take your old NASA phrase) and doesn't require proprietary extensions, although some might like to lock in a subscriber to proprietary features of an intelligent web architecture. > >Some folks do believe that just fixing the loop will fix system >performance, and they are clearly in the wrong. However, I will venture >to say that unless you do something like what we're doing, it doesn't >matter if the loop is ADSL or Cable or laser, it's not going to end up >running very fast. This is not just a loop problem. > Right again, just fixing the loop problem isn't enough, but since we are tangentially back on that topic, what exactly has TCI and the other cable partners committed to regarding the investment in cable plants outside the Bay Area? For while you absolutely must have an intelligent data architecture, you also absolutely must have a solution to the local loop problem. You go fix the local loops at TCI and I'll get PacBell to roll out an intelligent data architecture along with the xDSL service. --Kent

1 0

Re: Cisco's AIP vs HSSI
by Kent W. England 15 Oct '96

15 Oct '96

At 10:58 AM 15-10-96 -0400, Avi Freedman wrote: >> This is based on my feeling that HDLC is more efficent >> than ATM signaling/framing. > >Agreed... >But it's not a feeling, it's a fact :) > >> --bill > >Avi > > > While this is certainly true, HDLC is a point-to-point protocol and not a network protocol, like frame relay, SMDS or ATM. And HDLC itself isn't quite enough, IMHO, you really need PPP. And the efficiency lost to ATM is not 40% as often claimed on this list, but rather it is 12% less efficient than PPP for TCP. 10% is the cell header overhead and 2% is due to modulo 48 padding, given actual traffic at FIX West as measured by kc at NLANR. --Kent We return to our regularly scheduled ATM tweaking program now in progress. :-)

2 1

Re: Cisco's AIP vs HSSI
by Kent W. England 15 Oct '96

15 Oct '96

At 09:46 AM 15-10-96 -0400, Padma Krishnaswamy wrote: >One other point about the AIPs relative to the HSSI/DSU ; you may not be >interested in this feature , but the AIPs implement traffic shaping- ie You can >set Peak and Average rates and burst size; you could use this to subrate your >traffic -should you be in a situation where this is desirable. > > While this is true, I would caution the novice that TCP sources don't really benefit from rate shaping and the sort of burst capability you get with VBR. TCP appears to work with the explicit rate control of ABR, but there are some concerns in the research community that it might not work because both TCP and ABR are working the congestion management problem simultaneously and there may be pathological or even common situations where these congestion management schemes conflict or degrade each other. Time will tell. To date, we know that TCP works well with UBR and large buffers. Large is defined by TCP and the path length and works out roughly to twice the bandwidth delay product on the longest path. --Kent

1 0

Re: Cisco's AIP vs HSSI
by salo＠msc.edu 15 Oct '96

15 Oct '96

> Date: Tue, 15 Oct 1996 09:46:23 -0400 > From: kri(a)bellcore.com (Padma Krishnaswamy) > To: nanog(a)merit.edu, salo(a)msc.edu (Tim Salo) > Subject: Re: Cisco's AIP vs HSSI > > One other point about the AIPs relative to the HSSI/DSU ; you may not be > interested in this feature , but the AIPs implement traffic shaping- ie You > can set Peak and Average rates and burst size; you could use this to > subrate your traffic -should you be in a situation where this is desirable. That is my understanding. I think that this is part of a some more general observations: o The AIP card is a more intelligent card and can perform more functions today and is much more likely to perform more functions in the future. o I suspect that few, if any, new ATM features will be added to the HSSI card. Again, your router vendor should be telling you all of this. > I havent looked around to check out any new ADSU type products since mid 95, > but it used to be that you could not do this with an ADSU. This is also my understanding. I thought I saw some work being done on an enhanced DXI specification, (the interface between the router and the ATM DSU), but I think that, for the most part, not much work is being done with ATM DSU solutions today. ATM DSUs were largely developed as a quick-to-market solution for adding ATM functionality to routers, without the need for new router boards. Their time has passed. -tjs

4 5

Re: cable modems [Re: Intra/Inter - was Inet-II]
by Milo Medin 15 Oct '96

15 Oct '96

Really Ken, just because you consult to PacBell, you shouldn't be so obvious in your posturing. :-) Cable modems by themselves don't don't the performance problem, in fact, that's what @Home has been talking about for sometime now, and why we believe you have to build an intelligent network architecture, not just dumb pipes. Some folks do believe that just fixing the loop will fix system performance, and they are clearly in the wrong. However, I will venture to say that unless you do something like what we're doing, it doesn't matter if the loop is ADSL or Cable or laser, it's not going to end up running very fast. This is not just a loop problem. As for the hype machine, KPCB has a pretty good track record (Sun Micro, Intuit, Netscape, etc...), and I am very pleased in my interactions with those guys. They have an excellent reputation in the VC community. As for @home and it's financials, I deal with lots of analysts, and they seem to really like us. Our service is up in Fremont in commercial service, and we're turning on a bunch more cities (we have 3 other regions in test as I type). (Not really hype-like to actually field real service ;-)) Just look at some of the industry analyst reports for cable folks, they have been very favorable... Of course, the RBOC's could have fielded drastically cheaper fast services ages ago, but that would have canabalized all those nice leased line products... :-) Thanks, Milo

1 0