On Aug 27, 2013, at 12:34 AM, Owen DeLong <o...@delong.com> wrote: > If I send a packet out as a legitimate series of fragments, what is the chance > that they will get dropped somewhere in the middle of the path between the > emitting host and the receiving host? > > To my thinking, the answer to that question is basically "pretty close to 0 > and > if that changes in the core, very bad things will happen."
I mostly agree. I will argue that the actual path of an IP datagram is end to end, so the question is not the core, but the end to end path. That said, with today's congestion control algorithms, TCP does pretty badly with an other-than-negligible loss rate, so end to end, fragmented messages have a negligible probability of being dropped, so the probability of sending a message that is fragmented and having it arrive at the intended destination is a negligibly small probability smaller than then probability of sending an unfragmented message and having it arrive. The primary argument against that is firewall behavior, in which firewalls are programmed to drop fragments with high probability. If we had a protocol that sat atop IP and did what fragmentation does that we could expect all non-TCP/SCTP protocols to use, I would have a very different viewpoint. But, playing the ball where it lies, the primary change I would recommend would be to support any firewall rule that permitted dropping the first fragment of a fragmented datagram in which the first fragment did NOT include the entire IP header and the entire subsequent header, and expecting a host to keep a fragment of a datagram no more than some stated number of seconds (I might pick "two") with express permission to drop it more rapidly should the need arise. I would *not* support a rule that simple dropped fragments, or a protocol change that disallowed them.
signature.asc
Description: Message signed with OpenPGP using GPGMail
