Questions about Internet Packet Losses

Hello, and best wishes for what's left of 1997. Now, if you would, ...

Same to you :slight_smile:

Is Merit's packet loss data (NetNow) credible?

As always, the packet loss data doesn't always measure loss in the
network.

Do packet losses in the
Internet now average between 2% and 4% daily?

The congestion is definitely not distributed evenly. There are
hot spots, and to my knowledge there was no any significant research
on how those hot spots are distributes, what percentage of paths
is affected, etc.

Is there any evidence that Internet packet losses are
trending up or down?

Up. On-going backbone upgrades are simply not sufficient to keep up.

Were Merit's data correct, what would be the impact of 30% packet losses on
opening up TCP connections?

Close to none.

On TCP throughput, say through a 28.8Kbps
modem?

TCP throughput generally goes down the drain with that kind of packet loss.

How big a problem is HTTP's opening of so many TCP connections?

HTTP is broken as designed. That "feature" actively destroys the
cooperative congestion control mechanism.

Does TCP
need to operate differently than it does now when confronted routinely with
30% packet losses and quarter-second transit delays?

No. TCP is self-clocking and fairly loss resistant. This is not to say
there's no room for improvement, but nothing spectacular. For example,
selective ACKs would help to deal with higher loss rates.

0.25 sec delays is something routine with satellite communications. TCP
works just fine with that.

What is the proper
response of an IP-based protocol, like TCP, as packet losses climb? Try
harder or back off or what?

That's described in 1988 article by Van Jacobson, Mike Karels et al.

The answer is -- exponential backoff is sufficient to keep system
stable.

How robust are various widespread TCP/IP
implementations in the face of 30% packet loss and quarter-second transit
delays?

There's a lot of broken implementations (mostly in messy-dossy world).
The 4.3 Reno-derived TCPs (the majority) are fairly robust.

Is the Internet's sometimes bogging down due mainly to packet losses or
busy servers or what, or does the Internet not bog down?

The most annoying problem is not packet loss, it's routing stability.

What fraction of Internet traffic still goes through public exchange points
and therefore sees these kinds of packet losses? What fraction of Internet
traffic originates and terminates within a single ISP?

70% or so packets cross exchange points. That's empirical figure based
on hypothesis that rate of content providers to consumers is about constant
for all backbone ISPs.

There's no difference between public and private exchanges in terms of
dealing with congestion. So mentioning _public_ part is a bit misguided.

Where is the data on packet losses experienced by traffic that does not go
through public exchange points?

I guess there's no reliable data. In fact, there's no theory on how to
collect that data. For example, average, variance, and other traditional
statistical instruments are useless when you attempt to measure fractal
traffic. You end up with meaningless results -- for example, interarrival
time variance is infinite; average rates over similar intervals may differ
by orders of magnitude even when nothing changed, etc, etc.

In other words -- if anybody pretends to know what's going on he's a
charlatan.

If 30% loss impacts are noticeable, what should be done to eliminate the
losses or reduce their impacts on Web performance and reliability?

a) put more fibers into the ground
b) build better routers (want to invest?)
c) connect those routers to that fiber.

There's no hard physical limit on the capacity of the network
which can be built with available electronics. There are at least
six orders of magnitude of the growth which can be handled just by
throwing money at the problem.

The QoS, tag switching and other today's buzzwords are only marginal
improvements at best. The only real solution always was and will be:
more bandwidth.

Are packet losses due mainly to transient queue buffer overflows of user
traffic or to discards by overburdened routing processors or something else?

Mostly buffer overflows.

What does Merit mean when they say that some of these losses are
intentional because of settlement issues?

They may be looking for some libel lawsuits if they would care to
substantiate the claim.

Are ISPs cooperating
intelligently in the carriage of Internet traffic, or are ISPs competing
destructively, to the detriment of them and their customers?

I do not think any of them would kill the hen laying golden eggs.
The reality is that backbone ISPs are starting to turn out new
customers. There's always a lot of noise from those who just don't
get TANSTAAFL, though.

Any help you can offer on these questions would be appreciated.

You're welcome. Particularly it that would help to bring more reality
into press reports.

--vadim

The 4.3 Reno-derived TCPs (the majority) are fairly robust.

Yeah, but I doubt that they're in the majority. Recent stats indicate that
about 9% of the packets out there are using an MSS of 512. Another 1% are
using an MSS of 256. Only 6% are using 536, and 7% are using 1460. This
indicates to me that there are a whole lot of broken boxes out there still.

   The most annoying problem is not packet loss, it's routing stability.

Or, to be more precise, the results of routing instability on one
particular router implementation.

Tony

In other words -- if anybody pretends to know what's going on he's a
charlatan.

Unless they can present a fractal mathematical model that explains the
real-world data. If we encourage more people with experience in fractal
mathematics to study the data, we are more likely to see such models
being developped.

>If 30% loss impacts are noticeable, what should be done to eliminate the
>losses or reduce their impacts on Web performance and reliability?

a) put more fibers into the ground
b) build better routers (want to invest?)

                           ^^^^^^^^^^^^^^^
He means read the white papers at http://www.pluris.com :slight_smile:

c) connect those routers to that fiber.

Michael Dillon - Internet & ISP Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com