At 01:25 PM 10/23/97 -0400, Vijay Gill wrote:
Anyone willing to speak forth and give notes of their experience in setting up a NAP.
Vijay; I had a lot to do with making the Pacific Bell ATM NAP work, so I'll weigh in with a few comments while waiting for my plane out of Phoenix. Q) Should I use a switch or a router? A) If you are a disinterested third party L2 infrastructure provider, you need to offer your NAP customers a L2 infrastructure. If you are an ISP and you want to offer service to resellers, then you need to offer them a L3 infrastructure. The short answer is "you need a switch". Q) What sort of switch should I use? A) Use one that goes real fast on the interfaces, has a humongous aggregate throughput, and offers plenty of buffer space for high bandwidth delay product TCPs to bandwidth-hunt. Early ATM switches didn't have sufficient buffer space for practical use of TCP over UBR because Bellcore said they didn't need it. The DEC gigaswitch suffers Head of Line blocking problems, the sort of mistake an engineer makes who is building his first switch and doesn't like to read the literature. Some late model ATM switches have big buffers and work just fine for Internet NAPs. Use UBR service. ABR service is unproven and may interact with TCP congestion avoidance in bad ways, but this is unproven. I should think a honking big frame switch (I prefer MAC frames) with big buffers should work well, but do you want to be the first to try to run a production NAP with one? I don't think you need fancy admission control, rate control, explicit feedback congestion. Would be nice for the hardware to have four to eight queues and some switches for finding the right header bits to use to classify packets so that differential service might work when ready. A lot of folks think I'm an ATM bigot or at least suspect because I used to talk to Bellheads, but a few years ago the only big switches that possibly worked were ATM based. I still think that is true, because the old gigaswitch doesn't work, due to HOL blocking. No one has tried anything else yet, so there it stands. All I care is that it works and 1) simple 2) big buffers does the trick today. Of course, you could just sling an Ethernet hub in a rack and get started that way. It's been done. :-) --Kent