Fred,
At 19:46 03/01/2007, Templin, Fred L wrote:
Hello Bob,
Your message is very interesting, and I believe a fresh new
way of looking at the situation - especially for fragmentation
that occurs within tunnels. I appreciate what you are saying,
and look forward to further dialogue on it.
I have been looking at fragmentation over IP*-in-IPv4 tunnels
for some time, and 'draft-templin-linkadapt-03.txt' proposes
an Alternate Fragmentation (AF) scheme that occurs below the
transport layer segmentation (e.g., Packetization Layer Path
MTU Discovery) but above IPv4 fragmentation. It supports
segmentation/reassembly at the tunnel endpoints and uses a
dynamic segment size probing mechanism within the tunnel to
avoid in-the-network IPv4 fragmentation, yet remains compatible
with in-the-network fragmentation should it occur.
I've scanned it.
My initial reaction is that is seems somewhat over-specific in places. It
would seem better if only the bare bones needed for tunnel fragmentation
was in there, rather than tying together the fragmentation scheme with the
checksumming and so forth. Also I suspect the references to specific link
technologies will seem dated in a few years --- it needs to justify some of
the min & max MTU choices for the long term. Also, it would be useful to
say why existing v6 fragment header mechanisms aren't applicable.
Use of the
scheme is indicated by setting the reserved bit in the IPv4
header 'Flags' field (to be renamed as the 'AF' bit), thus
it obsoletes RFC3514 (an "April Fools Day" RFC).
This seems a rather specific use for this last reserved bit, given things
in the IP header are meant to be generally useful to upper layers.
Couldn't use of the coding scheme be negotiated between tunnel endpoints
for all tunnelled packets carrying a specific src-dest address pair?
I have to declare an interest in the reserved (evil) bit myself at this
point. I've been presenting a draft myself in tsvwg
<draft-briscoe-tsvwg-re-ecn-tcp-03.txt> that relies on using it. However, I
like to think we have a strong justification for grabbing it, as the above
draft is the culmination of a decade of work to fix the resource allocation
and accountability problems with the current Internet architecture.
Are you aware of any other claims on that bit? I'm sure there are many.
This AF scheme codes the 'ip_id' field in the IPv4 header and
thus presents a shorter-than-16b ID (the current draft version
specifies only a 6b ID). The assumption (which I think is also
an assumption you are making) is that successful reassembly
will occur within a very short time window if it will occur
at all. This assumes that reassembly failure will normally
occur due to packet loss rather than gross reordering of
packets within the same flow.
I'm not quite making that assumption. I'm saying re-assembly over shorter
gaps should take priority over longer gaps, so re-assembly over longer gaps
should be deferred for a while.
There have been many studies on packet reordering within the
Internet, but I have not found one yet that can completely
characterize the *degree* of reordering, i.e., the expected
number of places by which a reordered packet is out-of-order.
Most of the studies I have seen seem to suggest that the
expected degree of reordering of packets within a short chain
of packets sent in rapid succession within the same flow is
typically very small, e.g., a reordering event such as
(1,2,4,5,3,6,...) may occur occasionally, while one such
as (1,2,4,5,...,64k,3,64k+1,...) most likely will not. Other
factors to consider are: 1) as you observe, lengthening the
ID field may be insufficient in the presence of gross
reordering, and 2) transports such as TCP are likely to
treat grossly reordered packets as loss anyway.
I guess it depends when you look. If you catch a re-route in progress into
a shorter path, you might see something more like your second example if
the re-route affects very fast flows. So, the typical case might not be the
only case we have to allow for.
Finally, this work has been around for some time now, and
I believe has been reviewed by many while few have commented.
Perhaps now is the time for discussion on a wider basis.
I guess one immediate problem springs to mind. Current re-assembly
implementations have had to be hardened against frag, tear-drop etc
attacks. In defining a new coding of the packetID field, it will have to be
resistant to attack from malicious sources. A new coding would open up a
new set of vulnerabilities that would all have to be dreamt up then
patched. For instance, malicious sources could spoof tunnelled packets to
the decap endpoint as if they were from the encap endpoint, but send
sequences of fragments that don't fit together correctly, blowing its
memory, causing it to hang, or whatever.
Bob
____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe, Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
