Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements?

<Basavaraj.Patil@nokia.com> Fri, 09 December 2011 16:47 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6C21F8801 for <netext@ietfa.amsl.com>; Fri, 9 Dec 2011 08:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfvQ2rt798hV for <netext@ietfa.amsl.com>; Fri, 9 Dec 2011 08:47:13 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 86BEB21F87FC for <netext@ietf.org>; Fri, 9 Dec 2011 08:47:13 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pB9Gl5Dj004578; Fri, 9 Dec 2011 18:47:08 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 18:47:05 +0200
Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.69]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Fri, 9 Dec 2011 17:47:05 +0100
From: Basavaraj.Patil@nokia.com
To: sgundave@cisco.com, charliep@computer.org
Thread-Topic: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements?
Thread-Index: AQHMpAbNXcKzKnB2d0K7cZZ3yVH6bZWu6f6AgAFxdo+AIwuIAA==
Date: Fri, 09 Dec 2011 16:47:05 +0000
Message-ID: <CB07971A.16E7C%basavaraj.patil@nokia.com>
In-Reply-To: <CAE9B340.30D30%sgundave@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [173.74.226.233]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2C156C4CB0B08E4B96ECB18404329328@mgd.nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Dec 2011 16:47:05.0863 (UTC) FILETIME=[2F1A3970:01CCB692]
X-Nokia-AV: Clean
Cc: netext@ietf.org
Subject: Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements?
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 16:47:14 -0000

Hi Sri,

In your text below you state:
"
Any time there is an
   inter-technology handover between two access technologies, the
   applications on the host bound to the IP address configuration on the
   logical interface will not detect the change and will continue to use
   the MTU value of the logical interface for the outbound packets,
   which is never greater than the MTU value on that supported access
   network. 
"


How do you guarantee that the MTU value of the LI is never greater than
that of the IF to which the MN performed a handover to?

I do not believe this is realistic unless you set the value to the Min MTU
value (1280) as the default and simply ignore whatever MTU the link
supports.

-Raj

On 11/17/11 10:36 AM, "ext Sri Gundavelli" <sgundave@cisco.com> wrote:

>Hi Charlie/Raj:
>
>Agree. This is what we have for the MTU considerations.
>
>
>5.2.  MTU considerations
>
>   The link MTU (maximum transmission unit) value configured on a
>   logical interface should be the lowest of the MTU values supported
>   across any of the physical interfaces that are part of that logical
>   interface construct.  The MTU value should be configured as part of
>   the logical interface creation on the host.
>
>   Furthermore, this value must be updated any time there is a change to
>   the logical interface construct, such as when interfaces are added or
>   deleted from the logical interface setup.  Any time there is an
>   inter-technology handover between two access technologies, the
>   applications on the host bound to the IP address configuration on the
>   logical interface will not detect the change and will continue to use
>   the MTU value of the logical interface for the outbound packets,
>   which is never greater than the MTU value on that supported access
>   network.  However, the access network may continue to deliver the
>   packets conforming to the MTU value supported on that access
>   technology and the logical interface should be able to receive those
>   packets from the physical interface attached to that network.  This
>   approach of MTU configuration will ensure there is no IP packet
>   fragmentation after inter-technology handovers.
>
>
>On 11/15/11 9:34 PM, "Basavaraj.Patil@nokia.com"
><Basavaraj.Patil@nokia.com>
>wrote:
>
>> 
>> Hi Charlie,
>> 
>> Using the minimum MTU as the value for the logical IF is probably the
>>right
>> thing to do.
>> However you can also consider this as a sort of a DoS attack in the
>>sense that
>> you are forcing the MN to use an MTU to a smaller value thereby causing
>>less
>> efficient use of an air IF.
>> As an example a wifi network may advertise an MTU of 1280 and if the MN
>>uses
>> this as the default even on the cellular IF, the cellular IF is being
>>used sub
>> optimally.
>> 
>> -Basavaraj
>> 
>> On Nov 16, 2011, at 10:23 AM, ext Charles E. Perkins wrote:
>> 
>>> 
>>> Hello folks,
>>> 
>>> At the meeting this morning, a question was raised
>>> about the proper behavior on a logical interface if
>>> more than one value of MTU were advertised on any of
>>> the links of the interface.  This was discussed in
>>> the IPv6 working group.  IIRC, the sense of the
>>> discussion was that this was simply an error.
>>> See section 6.2.7 of RFC 4861.
>>> 
>>> In the case for logical interfaces, it seems to
>>> me that (a) a device can pick the MTU for whatever
>>> router advertisement it is using and (b) for the
>>> purposes of multicast across all links the source
>>> should pick the minimum of all advertised values.
>>> 
>>> Regards,
>>> Charlie P.
>>> 
>>> 
>>> Regards,
>>> Charlie P.
>>> _______________________________________________
>>> netext mailing list
>>> netext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netext
>> 
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>