Subject: RE: fragmentation and tunnels (was: RE: [Int-area] Re: [tsv-area]

From: <[email-masked]>
Date: Fri, 12 Jan 2007 11:34:36 -0000

Hi Fred,

Following on from this message you sent Bob Briscoe. I have just come
across a paper that appears to include some fairly good data regarding
degree of packet reordering:
http://www.cnrl.colostate.edu/Reorder/lcn2005_piratla_nischal_m.pdf

Also worth looking at their reference no [21] which is a site with lots
of additional information including some large raw data sets.

Toby Moncaster 
Future Communications Architecture 
Networks Research Centre 
BT Group Chief Technology Office 
_________________________________________________ 
t: (+44) (0) 1473 648734 
m: (+44) (0) 7764 185416 
British Telecommunications plc 
Registered office: 81 Newgate Street London EC1A 7AJ Registered in
England no. 1800000 
This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.
Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful
business purposes. Communications using this system will also be
monitored and may be recorded to secure effective operation and for
other lawful business purposes.

------------------------------

Date: Wed, 3 Jan 2007 11:46:16 -0800
From: "Templin, Fred L" <[email-masked]>
Subject: fragmentation and tunnels (was: RE: [Int-area] Re: [tsv-area]
	Fwd:	I-DACTION:draft-heffner-frag-harmful-03.txt) 
To: "Bob Briscoe" <[email-masked]>, "Matt Mathis"
	<[email-masked]>, 	"John Heffner" <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain;	charset="us-ascii"

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. 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 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.

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.

Benefits of this AF scheme in relation to IPv4 fragmentation
are:

  - avoidance of in-the-network fragmentation by dynamic
    segment size probing at the tunnel endpoints
  - authenticated probe response from the decapsulating
    tunnel endpoint to avoid false-positives from on- and
    off-path attackers
  - flow-control to avoid reassembly buffer overruns
  - reduced reassembly buffer memory requirements
  - avoidance of undetected reassembly errors via a
    trailing checksum that is dissimilar from the
    Internet checksum
  - larger MTUs for tunnels

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.

Thanks - Fred
[email-masked]

PS: Errata in the current draft version:

   - the current draft only speaks to IPv6-in-IPv4 tunnels
   - the ICMP messaging in the current draft may be too
     IPv6-centric
   - network byte ordering issue in the ip_id coding ('A';
     'P' bits should be MSBs; not LSBs)
   - network byte order coding of trailing checksum needs
     to be clarified
   - draft title should be changed to something like
     "Alternate Fragmentation for IP-in-IP Tunnels"

   The intention is to fix these in a -04 version, along
   with any other change suggestions that may come.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Jan 2007 09:03:15 -0800

Toby - thanks for the pointer, and I will take a look. I
appreciate this and any other references on fragmentation
and packet reordering.

One follow-on thought to what Bob and I were talking about
is that it may be desireable to use the proposed Alternate
Fragmentation (AF) scheme alongside RFC791 fragmentation
even for packets within the same flow.

For example, the AF scheme with its shortened 'id' could be
used for path MTU and decapsulator MRU probing, while RFC791
fragmentation with its 16b 'id' could be used for ordinary
data transport.

The encapsulator could then use the path MTU discovered
by AF to seed its RFC791 fragmentation threshold so that
in-the-network fragmentation is avoided. Then if a temporal
path MTU restriction occurs (e.g., due to a routing change)
there may be a short period of in-the-network fragmentation
until detected by AF - but, data will still be delivered.

Fred

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, January 12, 2007 3:35 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: RE: fragmentation and tunnels (was: RE: [Int-area] 
> Re: [tsv-area]
> 
>  
> Hi Fred,
>