Re: Exchanges that matter...
Subject: Re: Exchanges that matter... Date: Fri, 29 Nov 1996 11:02:24 -0800 From: Paul A Vixie <paul@vix.com> [...] ... and they aren't subject to ATM's cell tax ...
I am surprised, (well, maybe not), that you aren't concerned about the excessive overhead present in FDDI networks... -tjs From: salo@msc.edu (Tim Salo) Date: Tue, 23 Jul 1996 14:50:11 -0500 (CDT)
Date: Tue, 23 Jul 1996 14:28:27 -0400 From: Paul Ferguson <pferguso@cisco.com> [...] Recall Jerry Scharf's numbers; they're indicative of the issue. [...] HDLC framing bytes = 3080633605 HDLC efficiency = 97.72 ATM framing bytes = 3644304857 ATM efficiency = 82.61 ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95
At a certain point, some of these arguments about ATM efficiency sound a bit like saying FDDI is terrible because 4B/5B encoding is only 80% efficient. I think a more interesting measure of the value of ATM versus other wide-area technologies is some sort of measure of throughput per dollar.
HDLC framing bytes = 3080633605 HDLC efficiency = 97.72 ATM framing bytes = 3644304857 ATM efficiency = 82.61 ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95
At a certain point, some of these arguments about ATM efficiency sound a bit like saying FDDI is terrible because 4B/5B encoding is only 80% efficient.
I think a more interesting measure of the value of ATM versus other wide-area technologies is some sort of measure of throughput per dollar.
The issue that everyone seems to be overlooking is network design flexibility. Even if ATM has higher overhead, you can only grow a FDDI network so much. It really isn't all that hard to max out most FDDI switches.
On Sat, 7 Dec 1996, Joe Rhett wrote:
The issue that everyone seems to be overlooking is network design flexibility. Even if ATM has higher overhead, you can only grow a FDDI network so much. It really isn't all that hard to max out most FDDI switches.
Name one FDDI nap that is maxed out. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
On Dec 7, 1996, Nathan Stratton wrote:
Name one FDDI nap that is maxed out.
You must be kidding. Have you not noticed the 20% packet loss across the bridge between the two gigaswitches at MAE-east? Sure, the individual gigaswitches themselves might not be maxed out, but if the bridge is saturated then they may as well be. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access Internet and UNIX| |Network Administrator/Architect | New York City, NY | +------------------------------------+--------------------------------------+
On Sun, 8 Dec 1996, Alec H. Peterson wrote:
On Dec 7, 1996, Nathan Stratton wrote:
Name one FDDI nap that is maxed out.
You must be kidding. Have you not noticed the 20% packet loss across the bridge between the two gigaswitches at MAE-east? Sure, the individual gigaswitches themselves might not be maxed out, but if the bridge is saturated then they may as well be.
Yes, MFS needs to do this differently. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
In message <Pine.LNX.3.95.961208112336.9654C-100000@netrail.net>, Nathan Stratt on writes:
On Sun, 8 Dec 1996, Alec H. Peterson wrote:
On Dec 7, 1996, Nathan Stratton wrote:
Name one FDDI nap that is maxed out.
You must be kidding. Have you not noticed the 20% packet loss across the bridge between the two gigaswitches at MAE-east? Sure, the individual gigaswitches themselves might not be maxed out, but if the bridge is saturated then they may as well be.
Yes, MFS needs to do this differently.
MFS can't even do full duplex ethernet. Of course, I don' know of any other people offering full duplex LAN connection services. Party is related to the old ethernet switches, that didn't support it. But I haven't been able to convince them to sell me full duplex anything yet. (Clear channel DS3 or T-1, but not much else). --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net
On Dec 8, 1996, Jeremy Porter wrote:
MFS can't even do full duplex ethernet. Of course, I don' know of any other people offering full duplex LAN connection services. Party is related to the old ethernet switches, that didn't support it. But I haven't been able to convince them to sell me full duplex anything yet. (Clear channel DS3 or T-1, but not much else).
I think the Cat5 can do it, but most routers don't support it on 10mbit ethernet interfaces (ciscos will do it on 100mbit ones, though). MFS does seem reluctant to do full duplex, though. I'd be interested to hear their reasoning. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access Internet and UNIX| |Network Administrator/Architect | New York City, NY | +------------------------------------+--------------------------------------+
From traceroutes and additional extended pings, I could tell that some of
I've recently been on a hunt - I'm currently on a contract in the Bay Area, but I am still doing some sysadmin for an ISP back in montana. The Montana ISP is Sprint connected. For my local connection in Hayward, CA, I signed up with PACbell, figuring that it would do until I found another provider. After two months I had had enough and went on a quest for another provider. What I discovered is that If I did an extended ping to any provider in my local calling area, I had at least 5% packet loss (the provider I am using right now was at 5%). Pacbell was around 50%. Others varied. By contrast, I can ping any sprint-customer-attached computer and have almost 0% packet loss (1 out of 1000 lost occassionaly). Unfortunately I couldn't find a local provider which was spirnt connected. (An aside: anyone who knows a local priver in hayward which is sprint-connected is more than welcome to contact me directly :) the loss was at exchange points - other times the loss was in internal networks. IS there a reason that I'm getting 5 - 50% loss outside of sprint? I've also played a bit with this from a couple of other providers with similar results. As much as I hate to say anything nice about sprint, I'd have to say that they're very good about not loosing packets, at least when they're BGP hasn't imploded. -forrestc@imach.com
On Sun, 15 Dec 1996, Forrest W. Christian wrote:
By contrast, I can ping any sprint-customer-attached computer and have almost 0% packet loss (1 out of 1000 lost occassionaly).
Providers tend to have better connectivity within their own network.
IS there a reason that I'm getting 5 - 50% loss outside of sprint? I've also played a bit with this from a couple of other providers with similar results.
You paint with a pretty wide brush. The loss is caused by atleast three things: * ICMP packets are dropped by busy routers Many routers drop ICMP packets (ping, traceroute) when busy, or alternate dropping ICMP packets. I know that this behavior occurs when the packets are directed to the specific router, I am not sure if this every occurs for packets passing through. The standby tool ping needs a more reliable replacement for testing end to end packet loss. * Pipe smaller than needed Some providers have a pipes smaller than they "need" going to the NAPs. For a small provider this may be a 10 megabit connection. For sprint even a 100 megabit connection may not be enough (they may need multiple connections). With the Internet continuing to grow you can expect periodic growing pains for specific providers that don't forecast far enough into the future. * Head of queue blocking in the Gigaswitch This primarily effects the traffic of specific providers (who have enough to fill up a 100 megabit pipe). This phenomenon occurs when your NAP connection tries to talk to another providers filled up NAP connection. Even though the Gigaswitch has input and output queues, your output queue will block until the other providers input queue is free. When you block, you drop packets destined for other potentially available connections. However, this usually isn't a problem because most providers don't happen to peer with Sprint (purely an example). In other words, if you don't happen to exchange traffic with the overloaded party you won't see the head of queue problem occur for your packets. This problem can be fixed by multiple connections to the same NAP. (Which many providers already have). To summarize, the ability of a provider to get packets to and from other providers is directly dependent on how much money they are willing to spend to do that. By necessity they improve their internal network first. Mike. +------------------- H U R R I C A N E - E L E C T R I C -------------------+ | Mike Leber Direct Internet Connections Voice 408 282 1540 | | Hurricane Electric Web Hosting & Co-location Fax 408 971 3340 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
At 2:52 PM -0500 12/16/96, Mike Leber wrote:
On Sun, 15 Dec 1996, Forrest W. Christian wrote: [stuff cut] The loss is caused by atleast three things:
* ICMP packets are dropped by busy routers
Many routers drop ICMP packets (ping, traceroute) when busy, or alternate dropping ICMP packets. I know that this behavior occurs when the packets are directed to the specific router, I am not sure if this every occurs for packets passing through. The standby tool ping needs a more reliable replacement for testing end to end packet loss.
in general the router isn't going to treat one protocol (i.e. protocols running over IP (TCP, UDP, ICMP) differently when the packets are passing through the router - it just looks at the header and forwards. ciscos do handle pings for which the router itself is the destination at a lower priority than packets going through the box. I'll leave the discussions as to whether ping is adequate or not for another time.... [more stuff cut] dave
More of that - at least one site uses one of our hosts as a target of pings for measuring "Internet health". We consider this to be an abuse of our resources and, most probably, we will disable any external traffic we find inappropriate for this or other hosts. Dima dave o'leary writes:
At 2:52 PM -0500 12/16/96, Mike Leber wrote:
On Sun, 15 Dec 1996, Forrest W. Christian wrote: [stuff cut] The loss is caused by atleast three things:
* ICMP packets are dropped by busy routers
Many routers drop ICMP packets (ping, traceroute) when busy, or alternate dropping ICMP packets. I know that this behavior occurs when the packets are directed to the specific router, I am not sure if this every occurs for packets passing through. The standby tool ping needs a more reliable replacement for testing end to end packet loss.
in general the router isn't going to treat one protocol (i.e. protocols running over IP (TCP, UDP, ICMP) differently when the packets are passing through the router - it just looks at the header and forwards. ciscos do handle pings for which the router itself is the destination at a lower priority than packets going through the box. I'll leave the discussions as to whether ping is adequate or not for another time....
[more stuff cut]
dave
Interesting. An ICMP packet dropped when busy. Well, it seems as if there is only a hair's difference between when an ICMP packet is dropped and when an IP packet is dropped. If you are busy, you are busy, right? I know that I was getting zero packet loss for many many basic routes this time last year that are now losing packets. I think that a network is in great shape when the packet loss is at a sheer minimum. Even one percent packet loss can be felt as substantially more degraded than perfect transport. Just like ra.net, I use pings to monitor one aspect of overall performance. Me and ra.net are not alone.
On Sun, 15 Dec 1996, Forrest W. Christian wrote:
Many routers drop ICMP packets (ping, traceroute) when busy, or alternate dropping ICMP packets. I know that this behavior occurs when the packets are directed to the specific router, I am not sure if this every occurs for packets passing through. The standby tool ping needs a more reliable replacement for testing end to end packet loss.
Interesting article on the matter in Communications International - Nov 25, 1996 entitled ISPs Divided Over Hub Bottlenecks by Ken Hart. Hank Nussbacher
participants (11)
-
chuckie＠panix.com -
Craig Nordin -
dave o'leary -
dvv＠sprint.net -
Forrest W. Christian -
Hank Nussbacher -
Jeremy Porter -
Joe Rhett -
Mike Leber -
Nathan Stratton -
salo＠msc.edu