Subject: Re: [Int-area] confirming consensus form themeeting: draft-templin-intarea-seal

From: [email-masked] (Noel Chiappa)
Date: Wed, 24 Feb 2010 13:26:12 -0500 (EST)

> From: "Templin, Fred L" <[email-masked]>

    > SEAL has been approx. 8 years in the making under the public domain, so
    > its not as if I'm popping up out of nowhere to hit people over the head
    > with it.

My message was not in any way about process, but purely about a technical
issue.

Also, again, my technical issue is not specific to SEAL, but would apply to
any encapsulation scheme which attempts to deal with PMTU issues by using
router-to-router fragmentation and reassembly.

    > I have been assured ... by several from major network equipment vendors
    > that fragmentation is no longer a performance concern as it once was;
    > they did not say whether the same was true about reassembly, however.

Well, since the latter is precisely the issue of concern, I'm not sure that
helps much.

    > IP fragmentation was and still is considered harmful.

Looking at the original Kent/Mogul paper, it would seem that many of the
reasons that fragmentation was considered harmful in the host-to-host
context, back then, would apply equally today in the router-to-router case,
in particular the overhead, etc involved in doing re-assembly. So if, as you
say, host-to-host (i.e. IP) IP fragmentation is still considered harmful, why
is router-to-router fragmentation any different?

To avoid being all doom and gloom, let me finish by saying that it seems to
me, having thought about the problem briefly, that router-to-router
fragmentation is not _critical_ to solving the problem of MTU in
encapsulation schemes, and that they may be able to solve it. What _is_
critical is finding the MTU along the path to the device at the far end.

Why? If the encapsulating device has that PMTU value in hand, it can use ICMP
Packet Too Big messages to tell the host to back off. Now, in the _general
case_, that mechanism has been shown to have a lot of problems, due to nodes
out in the network filtering these ICMP messages out.

However, in the encapsulation case, we only have to assure ourselves of two
things, for this mechanism to work: i) that the routers between the source
host and the _encapsulating router_ don't discard the ICMP message, and ii)
that the host processes the ICMP message properly.

i) is almost certainly a much more tractable problem than the general PMTUD
problem, as all the devices in that very limited subset are likely to be
under a single administrative control; in particular, the edge device (which
is where many incoming ICMP messages are filtered out) is instead the
_originator_ of the Packet Too Big ICMP message.

Yes, I know there are some problems even in that situation (e.g. hosts
responding properly), but it still does seem to me a more tractable solution
than re-assembly. As for the hosts, I don't think the network should bend
itself into a pretzel to handle hosts which don't implement specifications
properly - down that path lies an endless tar-pit. Hosts should properly
respond to ICMP PTB's, and if they don't, they should be fixed.

The difficult problem, it seems to me - and this applies to all encapsulation
schemes, not just ones that use fragmentation-reassembly - is to discover
that PMTU, and in an efficient and timely way. This is particularly true
since that number can change at any time, due to a path change out in the
network - a path change that the encapsulating and/or decapsulating devices
may have no knowledge of. The mechanisms in SEAL to discover the PMTU might
be a good way to do that.

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Feb 2010 11:26:56 -0800

Noel,

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Wednesday, February 24, 2010 10:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Int-area] confirming consensus form themeeting: draft-templin-intarea-seal
> 

Thanks for the correction, and apologies for deviating
from the technical.

> router-to-router fragmentation and reassembly.

OK.

> is router-to-router fragmentation any different?

I am considering two cases:

1) the ingress router (or some intermediate router)
   fragments and the egress router reassembles

2) the ingress router (or some intermediate router)
   fragments and the egress router *does not* reassemble

IMHO, the two cases need to be analyzed wrt specific
scenarios, where 1) may more be appropriate for some
scenarios and 2) may be more appropriate for others.
 
> critical is finding the MTU along the path to the device at the far end.

OK.

> out in the network filtering these ICMP messages out.

Right.

> that the host processes the ICMP message properly.

Right - a reasonable assumption when the routers between
the source host and the encapsulating router are within
the same end site.
 
> _originator_ of the Packet Too Big ICMP message.

OK.

> respond to ICMP PTB's, and if they don't, they should be fixed.

I think this may be generalizing just a bit, and I think it
very much depends on the placement of the encapsulating and
decapsulating routers. Routers connected to a core network
in a high data rate path may need to forego reassembly and
just return the PTBs even if the reported MTUs are smaller
than would be desirable. (This can be mitigated by having
the core network only deploy links with large MTUs). Routers
connected to edge networks where there are moderate data
rates on the other hand can make life better for the hosts
if they support a moderate amount of reassembly, e.g.,
to make sure that 1500 packets get through.
 
> be a good way to do that.

OK.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2010 07:05:54 -0800

Noel,

I'd like to have one more word on this. I think the
egress tunnel router (ETR) should be allowed to
reassemble as much or as little as it likes, as long
as it is reasonably consistent about the sizes it will
reassemble. For each ingress tunnel router (ITR), the
ETR can maintain an MRU that tells how big the ETR is
willing to reassemble. Then, if there is fragment loss
due to congestion, it will show up as congestion in
the ETR's reassembly buffer. The ETR can then reduce
its MRU estimate for this ITR and instead begin sending
packet too big messages. So, any congestion-related
fragment loss will be short-lived.

Notice I am listing this as a per-ITR feature instead
of a single MRU for all ITRs. This I think could be an
implementation option, but if possible it would be best
to maintain the value on a per ITR basis since congestion
is likely to be different on different paths. So, for
example, it might be that for some ITRs the ETR will
be able to reassemble 1500 but for others it may need
to shrink its MRU down to 1280.

Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Wednesday, February 24, 2010 11:27 AM
> To: Noel Chiappa; [email-masked]
> Subject: Re: [Int-area] confirming consensus form themeeting:draft-templin-intarea-seal
> 
> Noel,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area