Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment

From: [email-masked] (Noel Chiappa)
Date: Thu, 30 May 2013 12:44:12 -0400 (EDT)

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

    >> Can you please give an example of a tunnel where the encapsulation
    >> overhead does not result in a decrease of the E2E PMTU?

    > SEAL is an example of a tunnel type where the added overhead does not
    > decrease the effective end-to-end path MTU for MTUs up to 1500 bytes.
    > Another example is CAPWAP. 

Both SEAL and CAPWAP apparently rely on fragmentation/reassembly to do this.

The last time we tried to use fragmentation/reassembly on a large scale,
it just didn't work:

  Fragmentation Considered Harmful
  ftp://ftp.hpl.hp.com/pub/dec/WRL/research-reports/WRL-TR-87.3.ps

In light of that, what _experience_ is there with these protocols to show
that fragmentation/reassembly is a _practical_ approach?

(Since CAPWAP supports and MTU somewhat larger than jumbograms, it's not
clear if they have much actual experience with fragmentation/reassembly.)

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 May 2013 16:59:08 +0000

Hi Noel,

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Thursday, May 30, 2013 9:44 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
> 

Both SEAL and CAPWAP have their own segmentation/reassembly
schemes that are apart from IP fragmentation and do not share
some of the same pitfalls.

> The last time we tried to use fragmentation/reassembly on a large

I agree that reassembly in an egress router that is located somewhere
in the middle of a large network doesn't scale. For egress routers
that are close to the destination end systems, however, the scaling
is bounded. In general, the closer the egress router is to the end
systems the more practical reassembly becomes - especially if the
egress router and end system are one and the same.  

>   ftp://ftp.hpl.hp.com/pub/dec/WRL/research-reports/WRL-TR-87.3.ps

SEAL (and CAPWAP too I assume) took this work as guidance on how
to avoid the pitfalls.

> that fragmentation/reassembly is a _practical_ approach?

We are using SEAL internally within Boeing. And, my understanding
is that CAPWAP is widely used.
 
> fragmentation/reassembly.)

CAPWAP assures a tunnel MTU of at least 1500 bytes and uses
segmentation/reassembly to accomplish this when necessary.
But, that is not the same thing as IP fragmentation/reassembly.

Thanks - Fred

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 30 May 2013 17:43:49 +0000

> egress router and end system are one and the same.  

I'm afraid I my personal experience with the statement '… the closer the egress router is to the end systems the more practical reassembly becomes' does not align with this statement.  In some cases it may be true, but its certainly not a general statement I would support.

-Darrel

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 May 2013 17:56:24 +0000

Hi Darrel,

> From: Darrel Lewis (darlewis) [mailto:[email-masked]]
> Sent: Thursday, May 30, 2013 10:44 AM
> To: Templin, Fred L
> Cc: Darrel Lewis (darlewis); Noel Chiappa; [email-masked]
> I'm afraid I my personal experience with the statement '... the closer
> the egress router is to the end systems the more practical reassembly
> becomes' does not align with this statement.  In some cases it may be
> true, but its certainly not a general statement I would support.

I don't mind revising my statement to something like, "In certain
practical deployments, the closer the egress router is to the end
systems the more practical reassembly becomes...". We have both
SEAL and CAPWAP running internally here today.

There is also something else about these schemes that bears mention.
They try to avoid segmentation and reassembly whenever possible and
only do it when there is no other choice. So, if the true path MTU
is (1500+encapsulation_overhead) the schemes will discover this and
send whole packets without segmentation and reassembly. So, I am not
advocating segmentation/reassembly as a steady-state condition but
rather as a last resort. 

Thanks - Fred
[email-masked]