Re: Signaling Message Fragmentation

Hi Fred,

inline ..

On 9/23/14 4:14 PM, "Templin, Fred L" <[email protected]> wrote:

>Hi Sri,
>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave) [mailto:[email protected]]
>> Sent: Tuesday, September 23, 2014 4:06 PM
>> To: Templin, Fred L; [email protected]
>> Subject: Re: Signaling Message Fragmentation
>> 
>> 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.
>
>Probably better to look at the latest AERO spec (posted today).
>I have it fixed there now.

Ack. Will take a look

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


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


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


Ok.

Regards
Sri




>
>Thanks - Fred
>[email protected]
>
>> 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 protected]> wrote:
>> 
>> >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 protected]
>> >
>> >---
>> >
>> >From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L
>> >Sent: Monday, September 22, 2014 4:45 PM
>> >To: Sri Gundavelli (sgundave); [email protected]
>> >Subject: Re: [DMM] Signaling Message Fragmentation
>> >
>> >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 protected]] On Behalf Of Sri Gundavelli
>> >(sgundave)
>> >Sent: Thursday, September 18, 2014 1:04 PM
>> >To: [email protected]
>> >Subject: [DMM] Signaling Message Fragmentation
>> >
>> >[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
>