MTU of the Internet?

Sez Phil Howard:

Turn the MTU down, way down, and see how it affects things. At what point
in number of connections does the problem happen with MTU=1500 and at what
point does it happen with MTU=600 and even MTU=200.

Of course changing MTU isn't the correct solution, nor is changing the
number of connections. But these are workarounds that do work, for now.

Changing the number of connections IS the correct answer in this case.
If you are a dialup user at 33.6k (or 56k even), you should be very
acutely aware of how puny your pipe is. There is absolutely no reason
to expect 64 simultaneously connections to an OC-12 connected server
to behave normally. HTTP 1.0 is known to be severely flawed in this
respect; it opens large numbers of connections and closes them before
slow-start and congestion avoidance can kick in.

If your primary complaint is interactive response while performing
large downloads, changing the MTU is the correct answer. This is
simply a matter of the transmission time on large packets.

Does anyone have data to show if any terminal servers or client stacks
will honor TOS bits and/or known interactive port numbers when
ordering packets for transmission across slow links?

point to do that at some point. But having read the details on slow start
as a result of this thread, I find it's not what I proposed, although I
can now see that it, too, would have been explained as I explained my idea,
so the explanation was flawed. I might try to implement my ideas via UDP
and see what kinds of effects I can really get over real networks of the
1990's, understanding that the original design was done in the 1980's and
before with slow links and slow routers.

I'm sure we'd all like to see a reference implementation of your
ideas. Keep in mind that one of the primary features of PMTUD is that
it requires no modifications to any hosts or routers, and that it uses
only one protocol (ICMP) which is required to be implemented on all
hosts.

-S

But, practically, is _not_, completely, right now; wasn't this the
complaint I heard?

Cheers,
-- jra

> Smells like a marketing opportunity.

What, marketing a replacement stack? (you really should quote, BTW)

No, because the _users_ don't know enough better to care. It's the
_net_ that suffers.

Actually I think there is a fair bit of awareness among the "users" out
there - at least among those that are actually changing their MTU's...

These folks will likely be your best 'friends' in this effort, and perhaps
even worthy of further 'cultivation'.

Douglas Tooley

Jay R. Ashworth
jra@baylink.com
Member of the Technical Staff Unsolicited Commercial Emailers
Sued
The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby,
Tampa Bay, Florida on alt.fan.heinlein +1 813 790
7592

Managing Editor, Top Of The Key sports e-zine ------------

Does anyone have data to show if any terminal servers or client stacks
will honor TOS bits and/or known interactive port numbers when
ordering packets for transmission across slow links?

This is relatively trivial with Cisco terminal servers, but it does have to
be done manually. I'd be really surprised if no other vendor can
specifically order packets in the queue by port number or something.

Cisco does automatically take specific steps to allow smaller packets
(regardless of TOS or port number) through the box faster when coming from
many slow interfaces to one fast interface. The idea is, why should a
bunch of (completed) telnet packets wait for the ethernet/T1 while a
gigantic 1500 byte FTP packet is still serializing from a 28.8 modem
connection? This should help "perceived" response times on interactive
(e.g. telnet w/ 64 byte packets) stuff while not actually decreasing the
throughput of large file transfers on other peoples' links. Supposedly,
some other vendors place a packet in the outgoing queue when the first byte
arrives. If you have a bunch of small packets come in (and complete) just
after the big packet starts, you could create delays and waste bandwidth on
the uplink.

Of course, I've never actually measured the effects this, nor do I have
first hand knowledge of how other vendors handle the process. I'm just
taking Cisco's word for it (which you are more than welcome to disprove
with real data - if possible ;).

Stephen Sprunk "Oops." Email: stephen@sprunk.org

TTFN,
patrick

I recently discovered that some of my customers have been led to
believe that they should employ a program called "Turbo MTU" (or some
such), which apparently has knobs for every tiny detail of Windows
95's TCP/IP stack. Since these are often the same type of customers
who simply change every setting they can at random, I should not be
suprised that they encounter performance problems.