[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bezeq ADSL setup
- To: Miki Shapiro <aris(at-nospam)pharoe.com>
- Subject: Re: Bezeq ADSL setup
- From: Dani Arbel <darbel(at-nospam)techunix.technion.ac.il>
- Date: Tue, 12 Jun 2001 21:45:25 +0300 (IDT)
- Cc: Shlomo Matichin <shlomom(at-nospam)cs.huji.ac.il>, Happy Linux Campers <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <Pine.LNX.4.21.0106111851280.14780-100000@pharoe.com>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
Miki,
>
> WHY CHANGE DEFAULT MTU ON THE CLIENTS?
I do not realy know, but otherwise it won't work
> Hell, most of the SysAdmins I know don't even know how change the MTU
> on any operating system ;-)
Thats why I have added the explanations of how this should be done.
(may I just mention here that if they don't know this they can't be
regarded as sys admins..).
>
> > | 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
>
=================================================================
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