Subject: [DMM] Signaling Message Fragmentation

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 18 Sep 2014 20:03:50 +0000

[Discussion under the maintenance scope]

With the standardization of all the new mobility options (ANI, QoS, IFOM, MNP..etc)   and specially with the NAI/Domain type fields in some of those options, we are almost close to hitting the PBU/BU fragmentation limit.

Any thoughts on how to deal with this ? How is it solved in other message based protocols ? I've seen some work on IPSecme WG on IKEv2 message fragmentation for the same issue.

Should we do some thing here ? Or, if any one has invested time on this and has a proposal ? Comments ?

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Sep 2014 23:44:46 +0000

Hi Sri,

My understanding is that if a source sends fragmented messages it must have assurance
that the destination has a large enough reassembly buffer. Since the minimum IPv6
reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented packets
larger than 1500 bytes unless there is some other means of determining whether the
destination's reassembly buffer can accommodate the larger size.

How big do you need?

Thanks - Fred

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, September 18, 2014 1:04 PM
To: [email-masked]
Subject: [DMM] Signaling Message Fragmentation

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Sep 2014 15:50:35 +0000

Sri,

> I've seen some work on IPSecme WG on IKEv2 message fragmentation
> for the same issue.

I looked at this, and the approach is roughly the same as what I have
been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
years. In other words, perform fragmentation and reassembly at a level
above the encapsulating IP protocol headers and below the encapsulated
IP protocol headers - a mid-layer fragmentation and reassembly.

So, this brings up a few questions:

  1) Does the concern apply only to large control messages, or also to
     large data packets?
  2) How big can the control messages get - not only for just today but
     also going forward into the future?
  3) Are we really so concerned about IP fragment dropping that we need
     to bump this up to a mid-layer frag/reass?

Thanks - Fred
[email-masked]

---

From: dmm [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, September 22, 2014 4:45 PM
To: Sri Gundavelli (sgundave); [email-masked]
Subject: Re: [DMM] Signaling Message Fragmentation

Hi Sri,

How big do you need?

Thanks - Fred

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Sep 2014 17:29:55 +0000

Hi Sri,

I will make this even easier and reduce it to a single question:

  1) How big??

Thanks - Fred

> -----Original Message-----
> From: Templin, Fred L
> Sent: Tuesday, September 23, 2014 8:51 AM
> To: Templin, Fred L; Sri Gundavelli (sgundave); [email-masked]
> Subject: RE: Signaling Message Fragmentation
> 
> Sri,
> 
> With the standardization of all the new mobility options (ANI, QoS, IFOM, MNP..etc)   and specially
> with the NAI/Domain type fields in some of those options, we are almost close to hitting the PBU/BU
> fragmentation limit.
> 
> Any thoughts on how to deal with this ? How is it solved in other message based protocols ? I've seen
> some work on IPSecme WG on IKEv2 message fragmentation for the same issue.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Sep 2014 18:55:22 +0000

>   1) How big??

Still no answer. I guess then we will have to assume 64KB.
Anything larger than that will have to go as a jumbogram.

Thanks - Fred

> Sent: Tuesday, September 23, 2014 10:30 AM
> > Should we do some thing here ? Or, if any one has invested time on this and has a proposal ?
> Comments
> > ?
> >
> >
> >
> > Regards
> > Sri
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 23 Sep 2014 23:06:03 +0000

Hi Fred,

Thanks for your response and also sorry for the delay in catching up on
this thread; Had to focus on some other business.

The issue that I raised is specifically in the context of control plane
messages. Some of the mobility options (Ex: Dynamic Mobile Network Prefix
option in RFC7148) can easily exceed the path MTU size. Each of these
options by itself may not be huge, but multiple instances of the option
can be included in the message. For Mobile Networks use-case, its possible
a mobile node is assigned a set of IPv6 prefixes and based on the count
exceed the MTU limits.  As such this should be OK; But ensuring
fragmentation in the MIP layer eliminates issues such as dropped fragments
by mid-level boxes and also fragmentation by on-path nodes. The question
is also not about requiring a huge buffer sizes, but more about handling
messages which are slightly beyond the MTU sizes.  I will look at the SEAL
proposal and understand how its handled there.

For user-plane we are covered, the tunnel entry and exit point perform
fragmentation prior to the encapsulation and so generally this should not
cause any issues. We always have the ability to advertise a lower MTU
value on the access link;  The MTU value that we advertise on the access
link should be the lower of the link MTU on the WLAN link and the Tunnel
MTU on the MAG-LMA path. This can be achieved by allowing the MAG to
include the adjusted MTU value in the DHCP OFFER and IPv6 Router
Advertisements. However, we realize not all mobile nodes honor the MTU
option in the DHCPOFFER; But, at least on the addressing plane we can
ensure we send the correct MTU values.

RFC 5844: (IPv4 Traffic from the Mobile Node)
"     The DHCPOFFER message [RFC2131] sent to the mobile node MUST
      include the Interface MTU option [RFC2132].  The DHCP servers in
      the Proxy Mobile IPv6 domain MUST be configured to include the
      Interface MTU option.  The MTU value SHOULD reflect the tunnel MTU
      for the bidirectional tunnel between the mobile access gateway and
      the local mobility anchor."

RFC 5213: (IPv6 Traffic from the Mobile Node)
 
  3.  The mobile access gateway SHOULD add the MTU option, as specified
       in [RFC4861], to the Router Advertisement messages that it sends
       on the access link.  This will ensure the mobile node on the link
       uses the advertised MTU value.  The MTU value SHOULD reflect the
       tunnel MTU for the bi-directional tunnel between the mobile
       access gateway and the local mobility anchor.  Considerations
       from Section 6.9.5 SHOULD be applied for determining the tunnel
       MTU value.

Regards
Sri

On 9/23/14 8:50 AM, "Templin, Fred L" <[email-masked]> wrote:

>With the standardization of all the new mobility options (ANI, QoS, IFOM,
>MNP..etc)   and specially with the NAI/Domain type fields in some of
>those options, we are almost close to hitting the PBU/BU fragmentation
>limit. 
>
>Any thoughts on how to deal with this ? How is it solved in other message
>based protocols ? I've seen some work on IPSecme WG on IKEv2 message
>fragmentation for the same issue.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Sep 2014 23:14:02 +0000

Hi Sri,

> From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
> Sent: Tuesday, September 23, 2014 4:06 PM
> To: Templin, Fred L; [email-masked]
> Subject: Re: Signaling Message Fragmentation
> 
> Hi Fred,
> 

Probably better to look at the latest AERO spec (posted today).
I have it fixed there now.
 
> ensure we send the correct MTU values.

I'm not much of a fan of advertised MTU values in RAs and such. It
may be OK if your tunnel is point-to-point, but I want good MTU
solution for NBMA tunnels where the MTU between neighbors A and B
may be vastly different than the MTU between neighbors A and C.

I also want there to be a guaranteed minimum and an unlimited maximum.
With AERO, all paths are guaranteed to support a minimum MTU of 1500.
But, larger packets can also go through (unfragmented) if the path
MTU is sufficient.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 23 Sep 2014 23:19:27 +0000

Hi Fred,

inline ..

>I have it fixed there now.

Ack. Will take a look

>may be vastly different than the MTU between neighbors A and C.

Its a P2P tunnel and so the NBMA considerations may not be needed.

>But, larger packets can also go through (unfragmented) if the path

Ok.

Regards
Sri

>> >reassembly unit is only 1500 bytes, the source SHOULD NOT send
>>fragmented
>> >packets

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Sep 2014 00:00:24 +0000

Hi Sri,

> Sent: Tuesday, September 23, 2014 4:19 PM

OK.

> Its a P2P tunnel and so the NBMA considerations may not be needed.

What might be needed however is a solution that recurses for
deeply-nested tunnels-within-tunnels (remember "nested NEMO"?).
AERO tunnels can recurse indefinitely, with a minimum of 1500
seen at each level.

> >But, larger packets can also go through (unfragmented) if the path

Good. We will need this if we want to push the Internet MTU up
to something more robust like 9KB or more.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 24 Sep 2014 17:47:12 +0000

Hi Fred,

Ok. 

I remember the nested NEMO discussions, but at least for mobile network
use-cases I have not seen any real deployment use-cases for that
requirement. But, it will be good to have some discussions on that topic.

OK.

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Sep 2014 20:50:33 +0000

Hi Sri,

> requirement. But, it will be good to have some discussions on that topic.

I am thinking about the case when a mobile router A provides an access
link for a mobile router B, which provides an access link for a mobile
router C, which provides an access link for a mobile router D, etc.
Each mobile router would coordinate with their home networks so that
there would be tunnels-within-tunnels-within-tunnels-etc.

I can think of use cases related to my industry, for example when a
first airplane provides an access link to a second airplane, the second
airplane provides an access link to a third airplane, etc. I think this
might come up also for certain mobile ad-hoc scenarios.

In any case, however, whenever there is a fixed or mobile node connected
to an access link provided by a mobility anchor there is nothing stopping
the node from setting up a tunnel. Then, there will be at least one
tunnel-within-tunnel nesting.

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 24 Sep 2014 22:26:10 +0000

Hi Fred,

> I can think of use cases related to my industry, for example when a first airplane provides an access link to a second airplane, the second airplane provides an access link to a third airplane, etc.

Seems to match the below use-case. I do not know the Boeing's or the broader Airline industry requirement, but personally I've not seen much interest for this.

> In any case, however, whenever there is a fixed or mobile node connected to an access link provided by a mobility anchor there is nothing stopping the node from setting up a tunnel.

Agree. That's there today; A MR on cellular access link, brings up a tunnel, which is on a transport tunnel.

Regards
Sri

On 9/24/14 1:50 PM, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sri,

Thanks - Fred
[email-masked]<mailto:[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Sep 2014 22:59:24 +0000

Hi Sri,

Sure, that diagram could be redrawn with airplanes instead of automobiles. But,
consider also the case where the airplane is a mobile router that connects into a
home network provided by an aeronautical Internet service provider. Then, the
passenger devices are also mobile routers with their own home networks. That
would represent a single mobile-router-within-mobile-router nesting, but a
"nested NEMO" case nonetheless.

We also care about use cases outside of just commercial aviation. Unmanned Air
Systems, Unmanned Underwater Vehicles, MANETs, disaster relief networks,
search and rescue networks, space-based systems etc.

About tunnels within tunnels, we should be able to nest them to infinite levels
of recursion where each level sees at least a 1500 MTU. None of this 1460
reduced to 1420 reduced to 1380, etc. until we run out of space - there should
be a solid 1500 at every level with the ability to go bigger if the path MTU can
support it.

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 3:26 PM
To: Templin, Fred L; [email-masked]
Subject: Re: Signaling Message Fragmentation

Hi Fred,

Regards
Sri

Hi Sri,

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 25 Sep 2014 06:07:49 +0000

Hi Fred,

Ok ! Not my area of interest, but I understand the requirement.

Regards
Sri

From: <Templin>, Fred L <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 24, 2014 3:59 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Signaling Message Fragmentation

Hi Sri,

“nested NEMO” case nonetheless.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Sep 2014 14:58:22 +0000

OK, then it sounds like you would agree that fixing tunnel MTU once and for
all would be a good thing?

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 11:08 PM
To: Templin, Fred L; [email-masked]
Subject: Re: Signaling Message Fragmentation

Hi Fred,

Regards
Sri

Hi Sri,

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 25 Sep 2014 17:06:06 +0000

Fred - If there is interest to do that work and the chair's are ok with it, I'll not object to that work.

Regards
Sri

From: <Templin>, Fred L <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 25, 2014 7:58 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Signaling Message Fragmentation

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 11:08 PM
To: Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: Re: Signaling Message Fragmentation

Hi Fred,

Regards
Sri

Hi Sri,

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Sep 2014 18:43:04 +0000

OK Sri; thanks. I just dropped a -40 version of the spec that includes substantial
improvements to the fragmentation and MTU section beyond what you have
already seen. If the WG wants to use this as a starting point, that would be OK
with me.

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 10:06 AM
To: Templin, Fred L; [email-masked]
Subject: Re: Signaling Message Fragmentation

Regards
Sri

Thanks - Fred

Hi Fred,

Regards
Sri

Hi Sri,

Thanks - Fred