Subject: [Int-area] FW: [RRG] Subnetwork Encapsulation and Adaptation Layer (SEAL)

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Feb 2008 09:58:25 -0800

This message is forwared from the Routing Research Group
mailing list. A new document with int-area implications
is available and titled:

  "Subnetwork Encapsulation and Adaptation Layer (SEAL)"
  http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt

SEAL in part specifies an MTU determination scheme based
on the Report Fragmentation (RF) concept that was first
proposed by Charles Lynn on the tcp-ip mailing list in
1987 and re-introduced by Steve Deering on the Path MTU
working group mailing list in 1989. Digests from those
lists are found at:

  http://ipvlx.com/tcp_ip.txt
  http://gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log

Based on the list discussions, the Report Fragmentation
(RF) method seemed to be the most attractive approach
under consideration for IPv4 path MTU discovery, but was
abandoned in favor of the (Don't Fragment/Fragmentation
Needed) method that eventually became RFC1191. The RF
method seems to have been abandoned due in part to
difficulty in procuring an "RF" bit in the IPv4 header,
difficulty in defining an ICMP Fragmentation Report
message and the concern that not all hosts at that time
correctly implemented IP reassembly.

The SEAL proposal addresses all of these points (as well
as others) and shows that a Report Fragmentation-based path
MTU discovery capability for router-to-router tunneling
in the Internet is still possible and could correct the
operational difficulties associated with traditional path
MTU discovery approaches. Moreover, the SEAL approach
supports true diversity, especially for subnetworks that
contain heterogeneous link types with diverse MTUs and/or
L2 address formats.

Please review and comment,

Fred
[email-masked]
_______________________________________________
Int-area mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Feb 2008 15:50:21 -0800

Hi Iljitsch, 

>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:[email-masked]] 
>Sent: Monday, February 25, 2008 2:59 PM
>To: Templin, Fred L
>Cc: Internet Area
>Subject: Re: [Int-area] FW: [RRG] Subnetwork Encapsulation and 
>Adaptation Layer (SEAL)
>
>On 25 feb 2008, at 18:58, Templin, Fred L wrote:
>
>"Robust duplicate packet detection": doesn't that go against the end- 
>to-end principle? Why is it useful to spend cycles detecting this in  
>the adaption layer when the endpoints need to to it anyway?

Perhaps the text is a bit misleading. All that was meant
by way of implication was that each SEAL packet carries a
32bit Identification that (along with the IP source and
destination) can be used by the network to differentiate
it from other SEAL packets. This comes into play most
prominently for multicast when the network is doing
something like the MANET Simplified Multicast Forwarding
(SMF), but could be useful for duplicate packet detection
for unicast as well.

Note that this does not require any particular behavior
on the part of the network; it only means that uniquifying
information is available should the network need it.

>"virtual ethernet": does this mean that there will be an ethernet  
>header in there somewhere? That seems wasteful.

No; no ethernet header. Virtual Ethernet only in the sense
that all ingress/egress tunnel routers attached to the same
subnetwork see each other as single hop neighbors at the IP
layer even though there may be many sub-IP layer hops
in-between. 

>Also, I don't see any  
>mechanisms for using more than two statically configured tunnel  
>endpoints.

The same abstraction applies for both point-to-point and
point-to-multipoint, but the manner in which tunnel endpoints
associate with one another are specified in other documents
(e.g., tunnel-mode-IPsec-over-SEAL, ISATAP-over-SEAL,
LISP-over-SEAL, configured-tunnel-over-SEAL, etc.).

>The ITE additionally admits all inner packets larger than 2KB into the

>VET interface as single-segment SEAL packets under the assumption that

>original sources that send packets larger than 1500 bytes are using an

>end-to-end MTU determination capability such as specified in [RFC4821].
>I disagree with this assumption. Are there ANY RFC 4821  
>implementations today?

I see a standards-track specification, and I see code
being submitted to a major OS. Also, AFAICT only one
endpoint needs to implement the mechanisms independent
of the other endpoint, so there is natural incremental
deployment.  

>Is it a good idea to hardcode values? If you run SEAL on a small  
>network with a larger MTU you could support larger packets without  
>fragmentation.

2KB- packets are conveyed across the subnetwork even if
some cutting and pasting is necessary, and 2KB+ packets are
sent into the subnetwork in one piece and either make it
through unfragmented or not. So, SEAL "takes care of the
smalls, and lets the bigs take care of themselves".

> And on MANETs it could be useful to support really  
>small MTUs.

Yes, and thereby avoid the jitter caused by trying to
convey larges packet across underprivileged links using
a link-specific adaptation.

> Or alternatively, it could be good to present an  
>artificially larger MTU to the users of SEAL because this saves  
>overhead on inner headers.

This is true, too.

>But the part that really bothers me is that there will ALWAYS be  
>fragmentation even when the source host would have been perfectly  
>capable of reducing its packet size.

No fragmentation if the links within the subnetwork configure
reasonably large MTUs. Or, if there are bandwidth-constrained
links that configure tiny MTUs, better to let SEAL handle it
rather than tell the original source that the path MTU is tiny
since the tunnel could be rerouted onto a path with a larger
MTU at any time.

Thanks - Fred

>Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Feb 2008 23:59:22 +0100

"virtual ethernet": does this mean that there will be an ethernet  
header in there somewhere? That seems wasteful. Also, I don't see any  
mechanisms for using more than two statically configured tunnel  
endpoints.

Is it a good idea to hardcode values? If you run SEAL on a small  
network with a larger MTU you could support larger packets without  
fragmentation. And on MANETs it could be useful to support really  
small MTUs. Or alternatively, it could be good to present an  
artificially larger MTU to the users of SEAL because this saves  
overhead on inner headers.

Iljitsch