MTU of the Internet?

Fri Feb 6 00:42:15 UTC 1998

Steve Carter writes...

> Theory tells me that for both types of traffic it is probably better,
> for response times sake, to have an asymetrical MTU (send = smaller,
> receive = bigger from the clients perspective).  Servers set big MTU's,
> clients set their's smaller.
> 
> Irrespective of your MTU size, the file or web page, etc. size is always
> going to be the same, therefore, if you set a smaller MTU at the server
> or within the network, fragmentation occurs, meaning greater overhead
> for a file of a given size and due to this the end station will have to
> reconstitute the data stream out of smaller packets, meaning more CPU
> overhead.

I still think there has to be some kind of better approach to what it is
we are doing when we have such extreme ranges of bandwidth capacity and
the resultant extremes of optimal MTU.  One idea I'm thinking of, and I
may well even give it a try between a couple of Linux boxes over a phone
line, is what I call "cell multiplexed PPP".  Basically this would be a
channelized stream that can parallel multiple packets.  Small ones can
come right through while the big ones are still working.  That may only
help minimally for parallelizing image loading unless there is added
logic that detects the TCP ports and ensures that only one port at a
time is taking up a channel.

-- 
Phil Howard | stop3360 at s0p3a0m6.com eat03me3 at spammer2.org stop8187 at no0where.net
  phil      | stop0it9 at noplace8.com eat7this at anywhere.org a9b2c8d4 at no9place.net
    at      | a6b9c6d0 at dumbads1.net a3b6c8d5 at lame3ads.edu blow4me7 at nowhere5.edu
  milepost  | suck2it1 at spammer3.org stop2450 at no8place.edu no6spam3 at dumbads6.edu
    dot     | stop5ads at dumbads0.net stop3437 at spammer1.com a1b1c6d4 at nowhere8.org
  com       | ads8suck at nowhere5.edu crash722 at noplace2.edu suck6it8 at lame0ads.net