On Sep 1, 2013, at 23:11 , "Fred Baker (fred)" <f...@cisco.com> wrote:
> > 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. Yes, the path is end-to-end and things happening near the end-points can be bad for a particular conversation. My point is that if somewhere in the core starts doing bad things to fragments on a regular basis, it will be very bad for massive numbers of users and not just the localized damage one would expect from something closer to the edge. Otherwise, we are saying the same thing. > > The primary argument against that is firewall behavior, in which firewalls > are programmed to drop fragments with high probability. > Which fortunately tend to be located at the edge and not in the core. > 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. I think I mostly agree, but I'd need to think it through a bit more than I can at the moment. Owen
