Ok, I'll add my 4 cents.
That's two for the fragmantation mechanism, and two for the "all hosts
on the network" question. I'm afraid nothing of what I say will actually
answer the original question.
First - fraging:
When a router receives a packet which is too big to transfer to the next
hop, it will fragment it into two (or more) packets which ARE small
enough. This mechanism is in the IP layer (layer 3), and is transparent
to higher protocols.
However, some protocols (such as TCP) don't care where their packets
end, and only about the entire stream. In order to save on fragmantation
costs, they employ an algorithm called "Path MTU". Each packet is sent
with an IP flag called "Don't Fragment". As a result, if a router now
needs to fragment the packet, it will instead drop it, and reply with an
ICMP called "Need Fragment", specifying the MTU needed.
As a result, the originating host adjusts it's internal MTU - FOR THE
ENTIRE PATH, and retransmits the packet. This should answer anyone who
was wondering how come people mentioned both router fragmenting, AND
packets being dropped.
Second - "all hosts on the network".
You don't need to set the MTU for all the hosts on the network, but
doing so will save time, as you will save the first packet being sent,
dropped, and retransmitted. This is because the host has no way of
knowing whether the next connection, to a new destination, has the same
low MTU, and therefor starts afresh.
Third (I know I said there will be only two, so, punish me, get the
comfy chair)
I don't have an ADSL modem, but reading the posts here, one of two
possibilites pop to mind. The first, as suggested, is that there is a
problem with fragmenting packets. The second, is that the "don't
fragment" flag is not being honored (either on or off). Either way means
that the modem is not RFC complient.
Shachar
Miki Shapiro wrote:
>> The MTU limit is because bezeq uses a fast ATM backbone for the whole
>> ADSL operation. ATM works with little packets. Also, even in LANs, system
>> administrator rarly give a MTU larger than 8K since this tends to slow
>> down RTT (round trip time).
>
>
> In most LANs I know, the MTU on all machines on the LAN is the default MTU
> that the OS driver assigns, generally around the 1500 byte range.
>
> My question was "why do I need to go off changing this default MTU to
> 1452 on all machines on the LAN to get my ADSL internet link to work
> correctly" backed up with "I think it will work just as great even if we
> do NOT change the ethernet MTU's on all machines at home" and "maybe the
> howto shouldn't be saying that you need to change the MTU's on anything
> other than the ppp interface of the linux box".
>
> To set the record straight, for some reason, this is what the HOWTO says
> you must do.
>
> You simply explained why hardware limitations of a certain network
> technology have a limit to the size of chunks it can carry. That is, of
> course, absolutely correct and yet irrelevant information.
> Nobody has a problem with the fact that ATM technology transfers reliably
> chunks of up to a certain size.
>
> The way I see it this is how it should work:
> Client send packet too-large-for-ATM-to-carry.
> Linux try to fit big packet into ppp interface.
> Linux fails. Packet too big.
> Linux sends ICMP packet to client saying "smaller please"
> Client gets ICMP packet.
> Client fragments big packet and sends the smaller packets
> Linux manages to fit smaller packet into ppp interface.
> Since we defined how small the packets should be by setting the MTU of the
> interface, I assume we set it small enough for the packets to eventually
> fit into ATM frames.
>
> back to the original question:
>
> WHY CHANGE DEFAULT MTU ON THE CLIENTS?
> Hell, most of the SysAdmins I know don't even know how change the MTU
> on any operating system ;-)
>
>> | Final comment, I don't know this issue that well, but can these ISP
>> | routers be convinced to send smaller packets by sending them ICMP
>> | source-quench requests? is this done automatically by some socket
>> | mechanism?
>>
>> I doubt that. The limitation are for a reason.
>
>
> I don't think you understood what I'm suggesting.
>
> I'm not suggesting we remove all packet-size limits on the intenet and go
> off downloading 15MB MP3's in a single chunk.
>
> I'm suggesting perhaps this mechanism can be used to overcome the
> "Orkit modem bug broken fragmentation mechanism problem that does not get
> solved by setting your ppp MTU to 1452 bytes"
> by impopsing a stricter packetsize limitation where it might help solve
> the problem :-)
>
>
>
> ---= Miki Shapiro =------------------
> ---= Cell: (+972)-56-322433 =--------
> ---= ICQ: 3EE853 =-------------------
> ---= Windows Programmer in Rehab =---
> -------------------------------------
>
> "If at first you don't succeed...
> .. Skydiving is probbably not for you."
>
> On Mon, 11 Jun 2001, Shlomo Matichin wrote:
>
>> hi miki,
>>
>> | I
>> | ---
>> | If I understood this correctly from Mulix, when a too-large packet
>> | containing ppp-encapsulated stuff comes to the ADSL modem on
>> | ethernet interface and wants to go on the DSL interface, the frarmentation
>> | mechanism of the modem (I'm talking about my ATUR3) is broken.
>> | Workaround: don't send packets larger than so-and-so from your linux box
>> | to your ADSL modem.
>> | The bottlenecking is done by the ppp interface (limited to MTU 1452) and
>> | once we do that, We're completely sure that the packets that reach the
>> | ADSL modem over the ethernet interface will be no larger than
>> | (what the ppp driver constructed plus the 48 bytes it added) - 1500 bytes
>> | and their ppp core will be no larger than 1452.
>> | And if they're smaller than 1500, the modem doesn't need to frag them
>> | before sending over the DSL. Problem Solved.
>> |
>> | Now can someonce PLEASE explain to me why we need a SECOND bottleneck by
>> | limiting the MTU Win9x-client-to-linux-over-ethernet traffic, as this
>> | traffic is bekol-mikre encapsulated in the ppp shell, and isn't seen by the ADSL
>> | modem as IP traffic at all?
>> | Why wouldn't an ethernet with 64K IP packets work? If I understand
>> | correctly, it would.
>>
>> The MTU limit is because bezeq uses a fast ATM backbone for the whole
>> ADSL operation. ATM works with little packets. Also, even in LANs, system
>> administrator rarly give a MTU larger than 8K since this tends to slow
>> down RTT (round trip time).
>>
>> | Issue II
>> | --------
>> | What if the other side of our (above-described) tunnel session between ISP
>> | computer and home-linux-router (or redback and home-linux-router) frags
>> | packets?
>> |
>> | Does the ADSL modem handle fragmented packets from the ISP side correctly?
>> | My guess is "NO, it's broken here too", because this problem is
>> | ISP specific.
>> | Obviously this poses a problem from some ISP's and doesn't from
>> | others. (probbably those that also worked around this problem by limiting
>> | the MTU on the tunnel interface on THEIR side) to avoid sending too large
>> | packets to your DSL modem.
>> |
>> | What do we do then? notify them?
>>
>> For this one of the reasons the ICMP protocol exsists. If a packet too
>> large comes to a router, it drops it, and send back a ICMP message to the
>> sender, with a "please fragment" request.
>>
>> | Final comment, I don't know this issue that well, but can these ISP
>> | routers be convinced to send smaller packets by sending them ICMP
>> | source-quench requests? is this done automatically by some socket
>> | mechanism?
>>
>> I doubt that. The limitation are for a reason.
>>
>> Shlomi.
>>
>>
>> --
>> -------------------------------------------
>> Shlomo Matichin [EMAIL PROTECTED]
>> The Mosix Group www.mosix.org
>>
>
>
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
