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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to