[165386] in North American Network Operators' Group
Re: IP Fragmentation - Not reliable over the Internet?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Sep 2 22:54:47 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B9C755E@xmb-rcd-x09.cisco.com>
Date: Mon, 2 Sep 2013 19:38:57 -0700
To: "Fred Baker (fred)" <fred@cisco.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 1, 2013, at 23:11 , "Fred Baker (fred)" <fred@cisco.com> wrote:
>=20
> On Aug 27, 2013, at 12:34 AM, Owen DeLong <owen@delong.com> wrote:
>=20
>> 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?
>>=20
>> 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."
>=20
> 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.
>=20
> 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.
>=20
> The primary argument against that is firewall behavior, in which =
firewalls are programmed to drop fragments with high probability.
>=20
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
