Re: The CIX and the NSFNET regionals - a dilemma
Right now the performance of the NSFnet is pretty bad (even the T3 network performance is worse than a CIX provided connection) so you are probably doing your customers a service by using the CIX to route packets instead of the NSFnet. But let's look into the future where ANS finally gets its technical act together and the T3 NSFnet really starts to hum. Add in much greater use of the CIX and I can see an inverted picture where the CIX is more of a bottleneck than the NSFnet.
Really? What do you base your assertions on? I can tell you right now that the NSFNET T3 backbone has come a long, long way since last October. (Mark Knopper and his gang must have been in hell back then!) The reliablity has been extremely good. I will admit that the traffic probably isn't taking full advantage of the speed of the T3 pipes right now, but the upgrade of the T3 cards in the NSSes will hopefully improve that situation. The throughput is still definitely higher than a T1 though... So, are there people still having problems with the T3 backbone? I have failed to see any evidence that "the NSFnet is pretty bad," at least worse than a CIX T1 connections. --zawada __
My comments are based on some tests that I ran a couple of weeks ago. Latency between Stanford and MIT via the T3 NSFnet was much greater than an equivalent path via CIX/Alternet (about 50% longer delay via the NSFnet). The results were repeatable and consistent. Throughput was also lower but I attribute that to the longer latency and limited TCP window size. The bottom line was that the performance as seen by a standard workstation using standard networking tools was better via CIX. I suspect that very large windows would push the throughput performance in favor of the NSFnet but I do not have the tools right now to test that. Anybody have a TCP with large windows I can play with? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392
Brian, We see similiar problems, functional capability for interactive applications like telnet is MUCH better through the CIX than through the NSFNet. When "SaltLakeCity" has its normal problems (we've seen about a dozen in January, and we're not looking really) then it goes through the roof. Leveraging off another posting elsewhere, I was wondering how hard it would be for cisco to change their architecture to have multiple routing tables and slightly modify their protocol prioritization scheme so that telnet/rlogin is not just prioritized but goes out a different path (specifically the CIX path). Marty ----- My comments are based on some tests that I ran a couple of weeks ago. Latency between Stanford and MIT via the T3 NSFnet was much greater than an equivalent path via CIX/Alternet (about 50% longer delay via the NSFnet). The results were repeatable and consistent. Throughput was also lower but I attribute that to the longer latency and limited TCP window size. The bottom line was that the performance as seen by a standard workstation using standard networking tools was better via CIX. I suspect that very large windows would push the throughput performance in favor of the NSFnet but I do not have the tools right now to test that. Anybody have a TCP with large windows I can play with? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392
Marty,
Leveraging off another posting elsewhere, I was wondering how hard it would be for cisco to change their architecture to have multiple routing tables and slightly modify their protocol prioritization scheme so that telnet/rlogin is not just prioritized but goes out a different path (specifically the CIX path).
In general, TOS support in routers is pretty easy, though it may not be in Cisco's case depending on how they designed their fast switching stuff. In theory, of course, Cisco is adding TOS support since they are adding OSPF and TOS is a part of OSPF, but I don't know whether theory matches practice in this case (it doesn't in the case of some other OSPF vendors). Philip
Marty,
Leveraging off another posting elsewhere, I was wondering how hard it would be for cisco to change their architecture to have multiple routing tables and slightly modify their protocol prioritization scheme so that telnet/rlogin is not just prioritized but goes out a different path (specifically the CIX path).
In general, TOS support in routers is pretty easy, though it may not be in Cisco's case depending on how they designed their fast switching stuff. In theory, of course, Cisco is adding TOS support since they are adding OSPF and TOS is a part of OSPF, but I don't know whether theory matches practice in this case (it doesn't in the case of some other OSPF vendors). Actually I was proposing that this be handled outside of setting TOS bits, but I wasn't clear. basically if I own a router from cisco today i can prioritize my interface traffic using the "priority-list" command. i select by protocol. Could that concept be built on to give me per port control over my routing in the future? who knows. Marty
No Marty. You are going to need either TOS routing or routing based on source address. The cleanest solution is TOS routing because most routers will include that feature in the near future. Now we need to get the host application software to follow suit or we need a hack that will cause a router to turn on the appropriate TOS bits when it sees a non-RE source address. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392
true TOS needs the hosts to participate - not likely in this century, the installed base is too large. subverting TOS with a router override is doable because you only have to change about 10K routers. whether you should TOS for R&E vs usefuly things like high bandwith or low latency should be debated. but it is doable provided I carry around multiple routing tables in my router. Marty ----- No Marty. You are going to need either TOS routing or routing based on source address. The cleanest solution is TOS routing because most routers will include that feature in the near future. Now we need to get the host application software to follow suit or we need a hack that will cause a router to turn on the appropriate TOS bits when it sees a non-RE source address. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392
Marty,
Actually I was proposing that this be handled outside of setting TOS bits, but I wasn't clear. basically if I own a router from cisco today i can prioritize my interface traffic using the "priority-list" command. i select by protocol. Could that concept be built on to give me per port control over my routing in the future? who knows.
What you're trying to do is basically what TOS does: choose your outgoing path based on whether the application is most concerned about delay, throughput, or whatever. When a host doesn't set any TOS bits, a router could conceivably then peek into the packet to look at TCP ports as part of computing the next hop. However, a router that did so would probably still want to leverage off of the TOS mechanism by using the TCP ports to determine what TOS bits the host should (according to Host Requirements) have set. Philip
Marty,
Actually I was proposing that this be handled outside of setting TOS bits, but I wasn't clear. basically if I own a router from cisco today i can prioritize my interface traffic using the "priority-list" command. i select by protocol. Could that concept be built on to give me per port control over my routing in the future? who knows.
What you're trying to do is basically what TOS does: choose your outgoing path based on whether the application is most concerned about delay, throughput, or whatever. yes. When a host doesn't set any TOS bits, a router could conceivably then peek into the packet to look at TCP ports as part of computing the next hop. However, a router that did so would probably still want to leverage off of the TOS mechanism by using the TCP ports to determine what TOS bits the host should (according to Host Requirements) have set. agreed. the router could send a ICMP SET_YOUR_TOS_BIT,_DUMMY to the host. ;-) m
participants (4)
-
brian＠lloyd.com -
Martin Lee Schoffstall -
Philip Almquist -
zawada＠ncsa.uiuc.edu