[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Perplexing PMTUD and packet length observations
On 12 aug 2008, at 12:01, Robin Whittle wrote:
I was able to reproduce the behavior and have documented it clearly
here:
Ok, so this is not the same subnet, right? Note that if you feed
tcpdump a few -v's you don't have to do as much header decoding in
your head.
What it looks like to me is that you're actually tcpdumping rather
than ipdumping: what you see is an initial two segment transmission
but as a single packet. Could it be that you're tcpdumping some
virtual interface rather than real packets on the wire? Can you
capture ethernet headers? Maybe some work is being offloaded to the
NIC? If not, I'd say that all of this is a bug in the linux networking
code (which is weird to begin with) but I have no explanation about
why you would be seeing normal size packets without fragmentation. I'm
pretty sure ISPs wouldn't want to expend CPU cycles to do this on
behalf of their hosted customers...
(BTW, I thought having a server 1600 km away was impressive...)
You mentioned some systems sending longer than MSS TCP packets to
hosts on the local network. Can you recall what this feature might
be called?
No.
I couldn't easily find the thread at:
http://www.merit.edu/mail.archives/nanog/
Look for "microsoft".
??? Why would advertising a large MSS be a problem? You send what
the other advertises he/she can handle and obviously _they_ will
be sending you what they can handle.
Yes, but what if, for some reason, there is a router in the path
with a smaller MTU than is generally seen by the client or by Google?
MSS is end-to-end, you still need PMTUD or fragmentation.
I think there is no workable alternative to RFC 1191 PMTUD.
What they should have done back then was create a mechanism that
allows the receiver of fragments to tell the sender that the packet
was fragmented and what the size of the largest fragment was. This
would have been harder to deploy (changes on both ends) but more robust.
RFC 4821 is so difficult to implement
Indeed. Still, it probably has to be done at some point, especially if
we ever want to move away from 1500 as the internet's maximum packet
size.
The first mistake was to invent the DF bit in the first place.
I guess you mean that all packets should always have been
non-fragmentable and that something like RFC 1191 should always have
been in existence.
No: if you have fragmentation anyway, there is no reason to have a
source say it can't be done. It would arguably be useful for the
destination to say that, but this isn't what DF does so before RFC
1191 came along it was useless.
The second mistake is to suggest that the DF bit be set for ALL
packets to do PMTUD in RFC 1191.
I don't understand your objection.
Set it only for 10% of your packets and you still have connectivity
when there is a black hole and the PMTUD works just fine.
Removing fragmentation from the network is a really good aspect of
IPv6, I think. Ideally, I think, all packets should be sent DF=1
and all applications should be ready to cope
No. This is a layer 3 job, not a layer 7 job.
An interesting approach would be to simply truncate packets that are
too big rather than fragment or drop them. A difference between the IP
length field and the actual length of the packet indicates truncation.
Transports would have to be changed to semi-ACK truncated data so the
sender only retransmits a checksum over the semi-ACKed data after
which a full ACK/NAK is possible. The semi-ACK also implicitly signals
the maximum path MTU.
The only reasonable solution seems to be send all packets DF=0 and
expect all routers to report PMTU troubles with a PTB message.
You mean DF=1?
DF=0 is not a solution for IPv6...
Networks which block PTB packets are doing themselves and anyone who
connects to them a grave disservice.
Yes, but they've been getting away with it so far because "everyone"
supports a 1500-byte MTU. So now breaking _that_ assumption creates
problems.
I'm not sure if implicitly making IPv6 packets unfragmentable was
mistake, but relying on ICMP messages was.
Do you suggest some other kind of message, or do you think PMTUD
should be done on the basis of positive acknowledgements alone, with
silent discarding of a too-big packet at whichever router can't
handle it?
With IPv6, it would have been possible to come up with a truncation
approach or maybe something where routers write a maximum packet size
in certain packets.
But now the only way forward is RFC 4821 etc while working hard to fix
PMTUD black holes until 4821 is widely implemented.
Google: No results found for "RFC 4821 deployment".
Yeah, none for "RFC 791 deployment" either...
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg