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 datagram protocols.
> > B. Accoutning, classification, resource reervation does not work on
> > fragmented packets.
>
> Thats a bug in accounting classification and resource reservation.
Sorry? It is bug in client mtu selection. Functions above are impossible
on fragmented packet even in theory. And because of A, if client uses mtu
296, it cannot use 100% of emerging and existing IP functions.
> Over a 9600 mobile phone link mtu 296 makes measurable differences to the
> latency when mixing a mail fetch with typing.
It is myth. Changing mtu until ~4K does not affect latency, it stays on 4K/bw.
> 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.
When you have 22Kbit link and 2 second latency, mtu must be large.
> NetROM is MTU 128.
I wrote "<". 8)
> If you want to argue that a MTU < 512 is hard to deal with by MTU discovery
> you are right. So when you get a 'must fragment' below 512, just turn DF off
> for that socket.
It is exactly, which we make, Alan. 8)
> I repeat my request. Cite the RFC number and line.
I repeat my reply: it is sillogism of A and B. See above.
You can write RFC yourself. 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 15 2001 - 21:00:27 EST