But, I don't think there are any magical fixes to flow control. Slow-start
is a reasonable solution. And NAPs are not the problem (on this point, see
Garfinkel, who points out the MAEs are actually are at a fraction of
capacity. It's the providers who are too cheap to saturate it)
It's not a 10-second window, it's one packet round-trip. Each successful
r/t doubles the rate until there are losses, then it backs off. What's
wrong is opening many simultaneous connections. Just open one, and leave it
warmed up. Better yet, write kernel TCP control blocks that share b/w
information across connections and cache speeds for a time -- that nets
almost all of the possible gain to T/TCP.
Rohit
----------------------------------------
Hosed again: Why buying that new 56K modem won't make you a faster Web
surfer.
by Robert X. Cringely
When I was a kid back in Apple Creek, Ohio, in the 1950s, one of the rites
of summer was going to the Buster Brown shoe store over in Wooster to buy a
new pair of sneakers. Only we didn't call them sneakers, we called them
"tennis shoes," which was really a hoot since nobody in Apple Creek played
tennis. Apple Creek, with its gas station and mental institution, was not
what you'd call a tennis center in the 1950s.
Certainly the Amish, who comprised more than half of the population of
Apple Creek, didn't play tennis, otherwise we'd see a lot of guys named
"Yoder" in the ATP tennis rankings. Yoder, by the way, is the last name of
about half the Amish people in the world. If you ever meet a real Amishman,
call him Mr. Yoder and he'll think he's supposed to remember you from
someplace.
So we'd go to the Buster Brown shoe store each summer to buy our tennis
shoes. And they weren't Nikes or Reeboks or even Keds: they were Red Ball
Jets. Red Ball Jets were the equivalent of Keds, which is to say they were
just sneakers, except they were black and had that cool red ball. You can't
buy Red Ball Jets anymore and I think that's because they were too cool. I
know mine were.
When we finally got home from the Buster Brown show store, it was time to
put on the Red Ball Jets and go for a run. This was at a time when people
didn't really go running, but having a new pair of Red Ball Jets somehow
changed the world and made running fun. That's because with a new pair of
Red Ball Jets, I could run faster than anyone. It felt like flying. I loved
those shoes.
Now let's fast-forward to the day before yesterday when you stopped by
CompUSA to buy that new 56K modem. 56K modems are the Red Ball Jets of the
1990s: the first time we put them on, it feels like flying.
Or does it?
That 56K modem may feel fast, but how fast is it really for doing the kind
of Internet stuff you really do? That is to say, how much better is it at
Web surfing and downloading smutty JPEGs than the 28.8 or 33.6 modem it
replaced? Like the Red Ball Jets, it sure FEELS faster, but part of that is
cognitive dissonance, induced by the sensation of $200+ leaving your
wallet. (I paid all this money, so the modem ought to feel faster).
The truth is that your new 56K modem actually is faster at downloading
those smutty JPEGs, but it isn't much faster at all for Web surfing. The
even uglier truth is that far more expensive technologies like ISDN, frame
relay, fractional T-1s, full T-1s, and even ADSL aren't dramatically faster
at Web surfing than your old 28.8 modem. Sure, the guy who is paying $1200
per month for a T-1 connection will claim it's faster -- and it might be a
little -- but it's not worth the money.
By now I have made many enemies with these words, so let me admit that I,
too, claimed a massive speed increase when I moved up to ISDN with LZS
compression (a claimed 512 kilobits-per-second throughput).
But I eventually had to admit that while FTP transfers easily came through
at up to 25 kbps on the old data speedometer (at least five times faster
than before), plain old Web surfing didn't feel all that much faster.
What I couldn't figure out was why -- until last week, when I spent a
couple hours with Larry Roberts, who made me see the light. Larry was the
official at the Department of Defense's Advanced Research projects Agency
(ARPA) who was in charge of building the ARPAnet, which was the predecessor
of today's Internet. Larry, who had been a researcher at MIT's Lincoln
Laboratory, pretty much designed the ARPAnet, which means he has a nuts and
bolts understanding of the Internet, too.
And here's what Larry told me. When you do an FTP file transfer on the
Internet, the transfer speed starts at some low figure and then rises to
some maximum. Watch next time you download one of those smutty JPEGs, since
most file transfer programs have a speed readout in bits-per-second. This
steadily increasing transfer rate is an artifact of TCP/IP's flow control.
Flow control has a lot in common with something else we used to do during
summers back in Apple Creek -- drinking out of the garden hose. Remember
how the water that had been sitting in the hose was hot from the sun and
tasted kinda rubbery? Remember also how your brother liked to suddenly turn
the water up full blast while you were drinking in an effort to drown you?
Unlike our brothers, TCP/IP is polite, and since it can't immediately know
whether you are sipping data through a modem straw or a T-3 fire hose, it
starts out slowly, dribbling data at around 2,000 bits-per-second for the
first 10 seconds. That's enough time for the two host computers to agree on
just how big a pipe is connecting them and turn the valve up to full speed,
which is what causes that speed increase over time in FTP transfers.
When TCP/IP was invented by Vint Cerf and Bob Kahn back in the 1970s, they
anticipated Internet backbones built from 56K lines leased from the phone
company, not the high-speed optical lines used today. They also anticipated
people using the Internet for file transfer, e-mail, and remote terminal
log-ins. But they never expected anything like the World Wide Web, and
that's the problem today. And that's the problem: everytime you click on a
link, it starts another TCP/IP flow control session. So whether you are
connected by a 28.8 kilobits-per-second modem or a 445 megabits-per-second
T-3 lines, the first 10 seconds of that link transfer takes place at around
2000 bits-per-second. The first 20,000 bits takes the same time to transfer
no matter how fast your connection is, and most Web pages are designed with
lots and lots of links of 20,000 bytes or less.
Explain that to your wife or husband after the first ISDN bill arrives.
The answer to this problem, according to Larry Roberts, is to change the
flow control algorithms in TCP/IP.
The new algorithms will allow for faster pipes and ought to make the
network 10-100 times faster with no changes in plumbing and only one other
change in network architecture. Larry says the NAPs have got to go.
NAPs are Network Access Points. These are five magic places where the major
Internet backbones are interconnected, allowing traffic to flow back and
forth from, say, Sprint or MCI or Uunet to any of the other big backbone
providers. Running from West to East, the NAPs are in San Francisco, San
Jose, Chicago, Washington DC, and beautiful Pensauken, New Jersey.
Microsoft.com lives not in Seattle but in an office building right on top
of the San Jose NAP -- the better to hear you with, my dear.
The problem with NAPs is that they have only been around since 1993 but are
already overloaded. The San Francisco NAP runs at its maximum capacity of
800 megabits-per-second for 18 hours per day. Twenty percent of packets
aimed at the San Francisco NAP never get through. This is another reason
why Web sites suddenly seem to disappear or slow w-a-y d-o-w-n.
If you are rich, there's a way around the NAP problem. The boys at Excite,
the search company, do this by having T-3 connections to three different
backbone providers. Whenever possible, Excite routes its traffic around the
NAP, which is what Larry Roberts would like to do for the rest of us, too.
All we have to do is give him a few hundred million dollars.
Personally, I'd settle for a brand new pair of Red Ball Jets, size 12.
--- Rohit Khare /// MCI Internet Architecture (BOS) /// khare@mci.net Voice+Pager: (617) 960-5131 VNet: 370-5131 Fax: (617) 960-1009