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
