- NANOG - lists.nanog.org

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Vadim Antonov 18 Dec '96

18 Dec '96

Craig Nordin <cnordin(a)vni.net> wrote: >> Er. There's no such thing as perfect transport as long as TCP is >> concerned. If end-hosts support large windows, even a single >> TCP session will load the network to the point where it'll lose >> packets. >What you say here makes sense to me. But, out of a 500 >ping sample over the course of half a day, I was getting well >below one percent loss -- six months ago. Most TCP sessins are pretty short, in fact. They simply have no chance to open window. Also, there's a lot of old TCP implementations which have window limited to 64Kb (or less!). >Now, my same sample group is going for more than three percent, >with many ten percent loss routes showing... Well, nobody argues that Internet is overloaded. But the question of how to measure the congestion is not as simple as just pinging. The problem is that there's no reasonable way to learn loss statistics from routers. --vadim

2 1

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Paul Ferguson 18 Dec '96

18 Dec '96

At 06:07 AM 12/17/96 -0000, James D. Wilson wrote: > >And if you are pinging across frame relay your ICMP packet loss might >be your packets above the CIR which have been discarded and also not >indicative of IP packet loss. > If you explicitly introduce L2 connectivity into this paradigm, it gets much, much more complicated. - paul

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by James D. Wilson 17 Dec '96

17 Dec '96

---------- > From: Vadim Antonov <avg(a)pluris.com> > Pings are ok, as long as you realize what exactly is being measured. > If you're pinging ciscos, you aren't measuring IP packet loss. And if you are pinging across frame relay your ICMP packet loss might be your packets above the CIR which have been discarded and also not indicative of IP packet loss. #include <standard.disclaimer> _ __ __ _____ ____ / | / /__ / /_/ ___/__ _______/ __/__ _____ / |/ / _ \/ __/\__ \/ / / / ___/ /_/ _ \/ ___/ / /| / __/ /_ ___/ / /_/ / / / __/ __/ / ================/_/=|_/\___/\__//____/\__,_/_/==/_/==\___/_/========== =====

2 1

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Tony Li 17 Dec '96

17 Dec '96

* 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. There seems to be a great deal of (understandable) confusion on this issue. Let's set it straight: Packets which are _successfully_ forwarded through a (high end) cisco router are not (by default) prioritized by protocol type. Packets which are not forwarded require more work and are effectively rate limited (and consume large amounts of CPU time). Some effects: - Pinging a cisco is not a valid measure of packet loss. It's closer to a CPU load measure than anything else. - Pinging _thru_ a cisco is reasonable. - Traceroute to a cisco is rate limited to one reply per second, so will almost always miss the middle reply. - Traceroute _thru_ a cisco may show many drops which would NOT be seen by normal "thru" traffic. Replies generated by the cisco when the TTL expires are again thru the CPU. So you may well traceroute thru a cisco which does not reply at all. However, you can clearly see the route after that router. * Head of queue blocking in the Gigaswitch Even though the Gigaswitch has input and output queues, your output queue will block until the other providers input queue is free. My (admittedly second hand) understanding is that the Gigaswitch/FDDI actually has minimal amounts of buffering. During a congestion event, it simply withholds the token, resulting in buffering in the routers. Queues there eventually overflow, and ... If this is incorrect, I would greatly appreciate pointers to the truth. Tony

3 2

Re: Exchanges that matter...
by salo＠msc.edu 17 Dec '96

17 Dec '96

> Subject: Re: Exchanges that matter... > Date: Fri, 29 Nov 1996 11:02:24 -0800 > From: Paul A Vixie <paul(a)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(a)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(a)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.

11 12

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by salo＠msc.edu 16 Dec '96

16 Dec '96

> To: salo(a)msc.edu (Tim Salo) > Date: Mon, 16 Dec 1996 17:16:40 -0500 (EST) > From: dvv(a)sprint.net (Dima Volodin) > [...] > > So, do I understand you correctly as saying that you have no interest > > in helping your customers understand the state of your service? > > No, I neither have said nor intend to say anything like that. Yes, I was being a bit unfair. Rather, I should have asked: "How do you recommend that your customers proactively monitor the status of your network and the wider Internet?" I took a quick look at the SprintLink handbook, but probably missed the recommendation. -tjs

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by salo＠msc.edu 16 Dec '96

16 Dec '96

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Sanjay Dani 16 Dec '96

16 Dec '96

> From: dvv(a)sprint.net (Dima Volodin) > 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 Perhaps they are evaluating you against other backbone providers by sending an icmp packet every few minutes. Is that still considered abuse or an incentive to you to potentially gain business by keeping your sites up all the time? Our potential clients evaluate us by visiting our web site to just see the performance. Sanjay.

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by salo＠msc.edu 16 Dec '96

16 Dec '96

> Subject: Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... > To: doleary(a)cisco.com (dave o'leary) > Date: Mon, 16 Dec 1996 16:00:09 -0500 (EST) > Cc: mleber(a)he.net, forrestc(a)iMach.com, nathan(a)netrail.net, joe(a)Navigist.Com, > nanog(a)merit.edu > From: dvv(a)sprint.net (Dima Volodin) > > 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 How many ping per second do you see? How many pings per second can your host handle? Your network? > and, most probably, we will disable any external > traffic we find inappropriate for this or other hosts. So, do I understand you correctly as saying that you have no interest in helping your customers understand the state of your service? -tjs "Those darn customers, things would work just fine, if they didn't keep using the network..."

2 1

Re: [Announce] traceroute sites
by Jason Fesler 16 Dec '96

16 Dec '96

Likewise, http://www.calweb.com/cgi-bin/trace has existed for quite a while. One of my next goals is to start saving traceroute data that it gets it with, and have it build a map with the given data.. Hard part will be making it pretty when starting with just ascii data :-). >> >traceroute url: >> >http://www.cwix.net/cgi-bin/trace -- Jason Fesler jfesler(a)calweb.com Internic: 'whois jf319' Admin, CalWeb Internet Services http://www.calweb.com Junk email returned, in bulk, back to sender; w/copies to all postmasters. You got junk mail problems? Use Eudora Pro, MSIE's mail, or 'man procmail'.

3 2