the TCP code should be "honouring" the link-local MTU in its selection
of MSS.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Hello!
> We are implementing an IP stack.
Alan, please, tell me what is wrong. And we will repair this.
The implementation follows RFCs and even relaxes their requirements
in the cases, when they are far from reality.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe
Hello!
We are implementing an IP stack.
Alan, please, tell me what is wrong. And we will repair this.
The implementation follows RFCs and even relaxes their requirements
in the cases, when they are far from reality.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe
the TCP code should be "honouring" the link-local MTU in its selection
of MSS.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
> Fragmentation does _not_ work on poor internet more. At all.
We are implementing an IP stack. Fragmentation works very well thank you,
pointing at a few broken sites as an excuse to not do things right isnt
very good.
Alan
-
To unsubscribe from this list: send the line "unsubscribe
Hello!
> Please cite an exact RFC reference.
Imagine, I found this reference yet. This is rfc1191, of course. 8)
in the MSS option. The MSS option should be 40 octets less than the
size of the largest datagram the host is able to reassemble (MMS_R,
as defined in [1]); in many cases,
Hello!
> This smells bad. Datagram protocol send sizes are only limited by
> socket buffer size, nothing more. Fragmentation makes it work.
The thread was started from the observation that fragmented frames
do _not_ pass through router. See? 8)
Path mtu discovery exists exactly to help to
Hello!
> Wouldn't it be simpler to just fix the bugs
There are no bugs.
There is phylosophical discussion about current state of internet
communications.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hello!
> Message size != MTU.
Alan, you misunderstand _sense_ of the problem.
Fragmentation does _not_ work on poor internet more. At all.
Look at original report. It failed _only_ because his intemediate
node failed to forward fragmented packets.
Alexey
-
To unsubscribe from this list: send
:-> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
>> Over a radio link where
>> error rate causes exponential increases in probability of packet loss as
> Another myth. All they do error correction and have so high latency,
> that _increasing_ mtu only helps. And helps a
[EMAIL PROTECTED] writes:
> A. Datagram protocols do not work with mtus not allowing to send
>512 byte frames (even DNS).
This smells bad. Datagram protocol send sizes are only limited by
socket buffer size, nothing more. Fragmentation makes it work.
If you are really talking about
[EMAIL PROTECTED] writes:
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
This smells bad. Datagram protocol send sizes are only limited by
socket buffer size, nothing more. Fragmentation makes it work.
If you are really talking about side
:- "kuznet" == kuznet [EMAIL PROTECTED] writes:
Over a radio link where
error rate causes exponential increases in probability of packet loss as
Another myth. All they do error correction and have so high latency,
that _increasing_ mtu only helps. And helps a lot.
Hello!
Message size != MTU.
Alan, you misunderstand _sense_ of the problem.
Fragmentation does _not_ work on poor internet more. At all.
Look at original report. It failed _only_ because his intemediate
node failed to forward fragmented packets.
Alexey
-
To unsubscribe from this list: send
Hello!
Wouldn't it be simpler to just fix the bugs
There are no bugs.
There is phylosophical discussion about current state of internet
communications.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hello!
This smells bad. Datagram protocol send sizes are only limited by
socket buffer size, nothing more. Fragmentation makes it work.
The thread was started from the observation that fragmented frames
do _not_ pass through router. See? 8)
Path mtu discovery exists exactly to help to
Hello!
Please cite an exact RFC reference.
Imagine, I found this reference yet. This is rfc1191, of course. 8)
in the MSS option. The MSS option should be 40 octets less than the
size of the largest datagram the host is able to reassemble (MMS_R,
as defined in [1]); in many cases,
Fragmentation does _not_ work on poor internet more. At all.
We are implementing an IP stack. Fragmentation works very well thank you,
pointing at a few broken sites as an excuse to not do things right isnt
very good.
Alan
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, 15 Feb 2001 [EMAIL PROTECTED] wrote:
> -> IP suite is not full functional with low MTUs and must be eliminated.
Wouldn't it be simpler to just fix the bugs instead of
eliminating the entire Linux IP suite ;)
Rik
--
Virtual memory is like a game you can't win;
However, without VM
On Thu, 15 Feb 2001 [EMAIL PROTECTED] wrote:
> > Over a 9600 mobile phone link mtu 296 makes measurable differences to the
> > latency when mixing a mail fetch with typing.
>
> It is myth.
> > Over a radio link where
> > error rate causes exponential
On Thu, 15 Feb 2001 [EMAIL PROTECTED] wrote:
Over a 9600 mobile phone link mtu 296 makes measurable differences to the
latency when mixing a mail fetch with typing.
It is myth.
Over a radio link where
error rate causes exponential increases
On Thu, 15 Feb 2001 [EMAIL PROTECTED] wrote:
- IP suite is not full functional with low MTUs and must be eliminated.
Wouldn't it be simpler to just fix the bugs instead of
eliminating the entire Linux IP suite ;)
Rik
--
Virtual memory is like a game you can't win;
However, without VM
> > I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
>
> 512 is maximal message size, which is transmitted without troubles,
> hardwired to almost all the datagram protocols.
Message size != MTU. DNS doesnt use DF. In fact DNS can even fall back to
TCP.
> > > B.
Rick Jones wrote:
>
> > Default of 536 is sadistic (and apaprently will be changed eventually
> > to stop tears of poor people whose providers not only supply them
> > with bogus mtu values sort of 552 or even 296, but also jailed them
> > to some proxy or masquearding domain), but it is still
Hello!
> I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please, Alan, distinguish two things: "works" and "works, until
I ask X". The second is equal to "does not".
512 is maximal message size, which is transmitted without troubles,
hardwired to almost all the
> Default of 536 is sadistic (and apaprently will be changed eventually
> to stop tears of poor people whose providers not only supply them
> with bogus mtu values sort of 552 or even 296, but also jailed them
> to some proxy or masquearding domain), but it is still right: IP
> with mtu lower 576
> A. Datagram protocols do not work with mtus not allowing to send
>512 byte frames (even DNS).
I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please explain your claim in more detail. Please explain why the real world
is violating your version of the laws of
Hello!
> Please cite an exact RFC reference.
No need to cite RFC, this is plain sillogism.
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
B. Accoutning, classification, resource reervation does not work on
fragmented packets.
-> IP suite is
> with bogus mtu values sort of 552 or even 296, but also jailed them
> to some proxy or masquearding domain), but it is still right: IP
> with mtu lower 576 is not full functional.
Please cite an exact RFC reference.
The 576 byte requirement is for reassembled packets handled by the host.
That
Hello!
> Kernel 2.4.x apparently disregards my ppp options MTU setting of 552
> and sets mss=536 (=> MTU=576).
Yes, default configuration is not allowed to advertise mss<536.
The limit is controlled via /proc/sys/net/ipv4/route/min_adv_mss,
you can change it to 256.
Default of 536 is sadistic
Hello!
Kernel 2.4.x apparently disregards my ppp options MTU setting of 552
and sets mss=536 (= MTU=576).
Yes, default configuration is not allowed to advertise mss536.
The limit is controlled via /proc/sys/net/ipv4/route/min_adv_mss,
you can change it to 256.
Default of 536 is sadistic (and
with bogus mtu values sort of 552 or even 296, but also jailed them
to some proxy or masquearding domain), but it is still right: IP
with mtu lower 576 is not full functional.
Please cite an exact RFC reference.
The 576 byte requirement is for reassembled packets handled by the host.
That is
Hello!
Please cite an exact RFC reference.
No need to cite RFC, this is plain sillogism.
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
B. Accoutning, classification, resource reervation does not work on
fragmented packets.
- IP suite is
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please explain your claim in more detail. Please explain why the real world
is violating your version of the laws of
Default of 536 is sadistic (and apaprently will be changed eventually
to stop tears of poor people whose providers not only supply them
with bogus mtu values sort of 552 or even 296, but also jailed them
to some proxy or masquearding domain), but it is still right: IP
with mtu lower 576 is
Hello!
I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please, Alan, distinguish two things: "works" and "works, until
I ask X". The second is equal to "does not".
512 is maximal message size, which is transmitted without troubles,
hardwired to almost all the
Rick Jones wrote:
Default of 536 is sadistic (and apaprently will be changed eventually
to stop tears of poor people whose providers not only supply them
with bogus mtu values sort of 552 or even 296, but also jailed them
to some proxy or masquearding domain), but it is still right: IP
I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
512 is maximal message size, which is transmitted without troubles,
hardwired to almost all the datagram protocols.
Message size != MTU. DNS doesnt use DF. In fact DNS can even fall back to
TCP.
B. Accoutning,
> Kernel 2.4.x apparently disregards my ppp options MTU setting of 552
> and sets mss=536 (=> MTU=576). Kernel 2.2.16 sets mss=512 correctly.
> Is this a kernel bug or what?
The kernel is entitled to set an MSS that may cause fragmentation. So no
it isnt a bug.
536 + 40 = 576
Im not
Kernel 2.4.x apparently disregards my ppp options MTU setting of 552
and sets mss=536 (= MTU=576). Kernel 2.2.16 sets mss=512 correctly.
Is this a kernel bug or what?
The kernel is entitled to set an MSS that may cause fragmentation. So no
it isnt a bug.
536 + 40 = 576
Im not sure
40 matches
Mail list logo
