[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bezeq ADSL setup



> 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       shlomom@cs.huji.ac.il
> The Mosix Group               www.mosix.org
> 


=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il