Re: Slow transmit / upload

From: Ralf Herrmann (Ralf.Herrmann_at_iin.stud.tu-ilmenau.de)
Date: 04/19/04 

Date: Mon, 19 Apr 2004 22:33:26 +0200

Hi Cliffort,

thanks for your notes.
I'm far away from being an internet or network expert, but i think you got me
wrong in some cases:-)

> They are mutually exclusive in the sense of configuration and purpose.
> The configuration of one does not affect the configuration or purpose
> of of the other, regardless of what "modern" modems do differently.

I understand what you mean, but my comment was a bit more related to the
question how modern modems handle or implement the commands you give to them.

Since the so called win-modems arose, you 've been stuck to the manufacturer
drivers or (in the case of unix) to some kind people who were able to build a
corresponding module. There has been no real std. afaik.
So it's possible you have to add totally different modem commands
or a special sequence to set the right values......well, the idea of copying
the win-driver's modem init commands for the unix scripts is a good
one in any case.

> A modem has nothing to do with setting the MTU. The MTU is not a modem
> protocol thing and is set on the PPP interface by configuring pppd.

Again you are right. But i'm not saying anything different.
I was just guessing a little bit about pppd history.
Maybe i should not have dine this.
But it was imaginable to me, that the default MTU used by pppd
for modems was smaller than today's 1500.......

>>Well, the MTU-thing somehow may have. It might not be applicable
>>to your modem connection, but there is a MTU issue when using a
>>DSL connection. Some (e.g.) webservers cannot be reached or at
>>least the connection is very slow.
>
>
> Agreed. But that's PPPoE ADSL and not PPP over a regular modem via
> landline.

Afaik the problem is indiepended of your connection type. It's an MTU issue
(at least that's what i heared). So i thought with DSL the usage of greater
MTU-values happens (in contrast to modem connections, see above) and so the
mentioned problem can be seen. When you use the same MTU with your
modem, you will be affected as well.
It was again just a guess, maybe it's only a nice fairy tale;-)

>
>>Some people recommend lowering the MTU value because the TCP packets
>>(within the IP packet) are sometimes loaded with an additional
>>header for some special routing reasons. So if you have an MTU of
>>1500 Bytes and you send this packet through such a connection, it
>>cannot pass through when the additional header is added by the router
>>(because in the end the packet size exeedes the max value for IPv4,
>>i think 1536 bytes incl. IP-Header).
>
>
> Yes, both the IP datagram header and the TCP segment can have more in
> their headers than the usual 20 octets, but to my knowledge they seldom
> do. What special routing issues do "some people" identify?

I don't really remember it. The main thing was, that certain connections
saturated the packets with additional header/overhead data so that it
could not be sent in the end. The workaround was lowering the MTU to
provide additional buffer for this overhead data.

> If a router is really permitted to add header options then it would be
> a big surprise to me. I'm no expert on what is permitted and what is
> not though. But if a router is permitted to add header options without
> fragmenting the data to maintain the size of the original datagram then
> it would be an even bigger surprise.

Yes that's right. I'm really sorry that i have no furhter information.
As i siad it was just note which came to my mind.
Anyway, it's an interesting topic.

> By the way, the maximum IPv4 IP datagram total size is 65535 octets,
> not 1536. But the maximum size is also constrained by the MTU of the
> sender's local network interface.

Hm, maybe i mixed up some things at this point. The 1536 bytes may be limit
of ethernet packets (MAC level). But something however was limited
to 1536 bytes.....

> Again, the MTU has nothing to do with the modem's performance. It might
> have an effect if the serial device can't handle the speed set by pppd.
> In that case reducing the speed set by pppd would be the best thing to
> do, not reducing the MTU size.

I didn't really mean the modem's performance. The MTU has nothing to do with the
modem, but with usable bandwidth. Lower MTU means more fragments which all carry
the header overhead with them. While you transmit header data, you cannot
transmit user data at the same time:-)

> It is usually 1500 octets for an Ethernet interface. For IP traffic
> originating from a host via an Ethernet interface the IP datagram size
> is determined by the interface MTU. That means, in the absence of TCP
> or IP options, the datagram size would be 1460. Any options reduce the
> amount of data in the datagram.

I know that. That's another way to produce more overhead and to have less
usable bandwidth.....

> Piggy-backing an ACK in a data segment is desirable since
> it reduces header overhead.

It's a common practice, yes.

> There is an implementation strategy that marks an ACK for a received
> segment as delayed and when a second segment arrives the data from
> both segments is ACKed. This reduces header overhead by sending one
> piggy-backed ACK instead of two ACKs.

I guess i was reffering to that topic. I read about delayed ACKs
when i did some investigations on samba server configuration.
There was a article about massive performance drops when the
corresponding socket option is not given to smbd. (Well the option
is now given by default, it's call TCP_NODELAY, right?).

> The term "dedicated socket option" is beyond my ken..

Call it poetry or just crap. English is not my native language:-)
I wanted to say "the option related to delayed ACKs".

The main intention of my post was to give some ideas on the question,
why the MTU change seemed to be neccessary to solve the problem.
Again, i'm not an expert, just felt like i had to write my thoughts.

Bye

Ralf

Relevant Pages

  • Re: browser hangs in downloads
    ... can't seem to download the java.com recommended to ... First it is a big mistake to connect directly to a modem even if you have ... The MTU on Cable Internet should be 1500. ... connection) with the program "DrTCP" available at: ...
    (microsoft.public.windowsxp.network_web)
  • pf+nat problem (MTU) solved
    ... A little thinking made me realise that my probable MTU size problem is all originating from me deciding earlier to use the DSL modem in half-bridge mode instead of transparent-bridge mode. ... The first one does PPPoE inside the modem, handles connection and authentication to the ISP, and offers the routable public IP via DHCP to a host connecting to the LAN port of the modem. ... I created an open firewall configuration where there is no scrub, the NAT rules are all enabled, and the only filter rule is "pass all". ...
    (comp.unix.bsd.freebsd.misc)
  • Re: OpenBSD 3.5 Internet Gateway
    ... >>There is no problem to reach the internal network and the adsl modem ... > How is your DSL modem set up? ... is it the modem taking care of the connection? ... rl0: flags=8843mtu 1500 ...
    (comp.unix.bsd.openbsd.misc)
  • Re: XP and Modem Speed
    ... > If I take this modem out of the XP system and put it in the 98 system ... "Connection Booster is the best program to speed up your internet ... Also speeds up your modem, ... Adjusts MTU & MSS. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Slow transmit / upload
    ... A modem has nothing to do with setting the MTU. ... >> second ACK delay unless duplicate segments were being being received ... > header for some special routing reasons. ... fragmenting the data to maintain the size of the original datagram then ...
    (comp.os.linux.networking)