[H-GEN] PPP problems

[Ben Carlyle]

[ Humbug *General* list - semi-serious discussions about Humbug and ]
[ Unix-related topics.  Please observe the list's charter.          ]

> From: Ben Carlyle <benc at foxboro.com.au>
> > An important effect of the MTU can be felt when communicating
> [snip of an interesting post]
> > Clear?  :)

> no, because of your word interactive. By which i think you mean, keystroke,
> response, keystroke, splat. Would this be true also of web browsing? Click,
> response, etc.

By interactive I mean an application which requires quick response
times to "feel" right.  By quick, in this context, I mean quick
in terms of the size of the packets being sent and the time it
takes to send those packets.  Under these definitions I would not
usually consider web browsing to be interactive, at least in
Australia where we may expect web pages to take tens of seconds to
appear.

> to paraphrase you, i think you said, ftp = large amount of data = large mtu
> = good
> this would also hold true (obviously) for most web pages being received, and
> essentially any screenfuls of telnet (such as cat, ls, midnight commander).

If the amount of data you expect to recieve between interactions
is near the MTU, then that is probably a good thing(tm).  If the
data all comes down in one packet, then it means it doesn't have
extra header information thrown in, and it is quite quick and
efficient to transfer.  If everything you do will result in 10k
responses, then the MTU may be good to set at a little over 10k.
If everything you do will result in 10 meg responses[1] then a
10 meg MTU may be good.  There are issues, though.  Here are three
that are relevant.

Transmission Errors:
Yet another implication of the MTU.  For large transfers it defines
the amount of information that can be transferred in one packet.
This means that if the packet fails, this is the most amount that
will have to be retransmitted.  If your link is perfect, then huge
packets can be wonderfully efficient.. but if your link can introduce
the occasional error, then for a relatively small overhead you can
split the transmission into several segments that are each less
likely to fail, and will cost less to transfer if they do fail.

Different levels of interactivity over the same link:
If you tune your MTU for a quick telnet session, your ftp session
will suffer due to extra headers being sent.  If you tune your MTU
to your ftp session, your telnet session will suffer due to long
delays between packet delivery.  It's all about the tradeoff
between bandwidth and latency.  It really depends on what is important
to you.  Web traffic lies somewhere in the middle, though I suspect
mostly will be far swung towards the ftp/bulk-transfer end.  The
interactive parts of the web connection are most likely to be DNS
lookup to find the host, and the initial connection before data
really starts to flow.  If you have a high MTU and are already loading
the link down with transfers, then you may experience long delays
for new connection startup that might (perhaps, maybe) be alleviated
by setting the MTU a little lower.

Out-of-my-hands:
Your MTU is not negotiated with the machine you're downloading
from.  Your MTU is negotiated with the machine you're directly
connected to. It has its own MTU negotiated to the next machine
along, and so on.  Setting enormous MTUs won't do you any good,
because someone between you and your destination will still be
requiring smaller packets.  They'll have to fragment your packets,
and the machine at the other end of the link will be required to
reconstruct them.  This adds unnecessary overhead[2] :)

> reading too much into your post, keystrokes and web clicks are mRu ?
> therefore not relevant in that sense, but, you also implied some jerkiness
> to responses because telnet (or anything else) would have a hard time
> getting a chunk of the line (eg 1 second between responses).

Actully MRU is just the MTU for the other side of the link.  My
understanding of this is that at any one time both values are
negotiated and set on both hosts.  Jason's post about on-the-fly
modification of the MTU and MRU values may indicate the situation
is a little more complicated :)  They can be different, because
the upstream traffic may be of a quite different nature to the
downstream traffic.. and we all love our flexibility to fine-tune,
don't we?

> am i ok so far? and is mru (not mtu) determined by the 'other side' of the
> peer connection, or is it the other way around?

'tis negotatiated.  Perhaps someone else can fill in the details,
but my understanding is that during the connection each side nomiates
a preferred rate, and perhaps a willingness to change? :)  I'm not
sure.  Voting rights of different computers to choose between
conflicting values can be as complicated as preference voting, or
as simple as first-come first-served.


Benjamin.

[1] I know, I know... this is silly and there are other restrictions.
[2] Why can't we all agree, and just get along?



--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.