Subject: [Mip4] Comments on draft-gundavelli-mip4-multiple-tunnel-support-00

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Jan 2009 00:28:29 +0200

Hi Sri, authors,

Here are my initial comments/review of the draft-gundavelli-mip4- 
multiple-tunnel-support-00.
Comments are prefixed with [JiK]. I found this draft rather interesting.

Cheers,
	Jouni

Abstract

    ...
    agent, each through a different interface path.  This capability is
    required for enabling a mobile node to utilize all the available
    wireless access links and build an higher aggregated data pipe to  
the
    home agent by setting the home address reachability over all of  
those
    tunnel paths.

[JiK] Although this I-D might be motivated by wireless host, I would not
       mention it as the only use case. The same comment concerns also  
the
       first paragraph of the Introduction.

Section 1. 2nd paragraph

    ...
    attached.  In both of these modes, there will only be one interface
    on the mobile node that is receiving the traffic from the home  
agent.
    However, this is not efficient and requires an approach where the
    mobile node can use more than one interfaces for reaching the home
    network.  The objective being efficient use of all available links  
to
    obtain higher aggregated bandwidth for the tunneled traffic between
    the home agent and the mobile node.

[JiK] Doesn't this hold for one HoA.. A mobile could have different HoAs
       per a set of interface etc.. Or is there a specific restriction  
of
       not allowing more than one HoA per mobile node? I would clarify
       what "constitutes" a mobile node within this specification. Is it
       a HoA or a mobile node identity (that could be other than HoA..  
and
       a mobile node could have multiple identities).

Section 1. 3rd paragraph

    This document presents extensions to the Mobile IP protocol for
    allowing a mobile node with multiple interfaces to register a care- 
of
    address for each of those active interfaces and establish overlay
    network of tunnels to the home agent over those interface paths.
    ...

[JiK] Is there an assumption that an interface is always a separate
       physical interface? Or can an interface be an alias interface
       as well?

Section 2.2.

       ...
       are given a unique identifier and this identifier is called the
       binding identifier.  The identifier is unique within all the
       bindings for a given mobile node.

[JiK] Unique for a mobile node or one HoA? If a mobile node had multiple
       HoAs BIDs would still be unique? How this would be done?

Section 3.

       ...
       The mobile node registers to the home agent through each of the
       available roaming interfaces.  As part of the registration, the
       ...

[JiK] A "roaming interface" is...?

       ...
       The home agent sets up the routing for the mobile node's home
       address.  The home address will be reachable over any of the
       established tunnels for that mobile node.  Based on the enabled
       traffic policies, the home agent can distribute the data traffic
       over any of those tunnels in any fashion.  When there are no
       explicit traffic policies in place, the default routing policy of
       per-flow load balancing will be in affect.

[JiK] I would like to see similar text from a mobile node point of view.

Section 4.1.

    ...
    This extension is a non-skippable extension and MAY be added to the
    Registration Request message by the mobile node.  There MUST not be
    more than one instance of this extension present in the message.

[JiK] s/MUST not/MUST NOT

       Interface-Type (If-Type)

          Type of interface through which the mobile node is connected.
          The permitted values for this are from the Access Technology
          Type registry.

[JiK] Where are these interface types defined? I could not find any
       mention of a registry etc.

       Binding-Id (BID)

          This 16-bit field is the binding identifier.  It uniquely
          identifies a specific binding of the mobile node, with which
          ...

[JiK] Is it actually per HoA, not per mobile node?

       Interface Bandwidth (If-BW)

          This 16-bit unsigned integer is used for conveying the
          available bandwidth of the interface associated with this
          request.  The bandwidth is specified in kilo-bytes, fractions
          are to be rounded to the nearest integer.

[JiK] How does the mobile node get this information? If it is just the
       "nominal" speed of the interface, this information can be very
       misleading and optimistic.. For example a 54MB WLAN behind a 1M
       xDSL.

Section 5.1.

    o  If the mobile node for connecting to the home link, uses either a
       designated interface or any of the available interfaces to  
connect
       to the home link and if it detects its home link through any of
       those interfaces, then it MUST consider its on the home link and
       SHOULD perform the deregistration procedure.

[JiK] Did I get it right that if any of the interfaces is on the home
       link, then all the other links have to de-register as well? Or  
is it
       only that interface that happens to be on the home link?

Section 5.3.

    ...
    node when it is supporting simultaneous bindings for that
    registration.  When the home agent allows simultaneous bindings, it
    will tunnel a separate copy of each arriving datagram to each of
    those care-of addresses, and the mobile node will receive multiple
    copies of datagrams destined to it.  The operation defined in this
    specification allows a mobile node to register from multiple
    interfaces using different care-of addresses and have multiple
    tunnels from the home agent to each of those care-of addresses and
    for distributing the traffic load across those tunnels.  This is a
    different model than the simultaneous bindings when it comes to the
    ...

[JiK] Does the mechanism in this specification work with "traditional"
       simultaneous bindings?

Section 8.

       When the value for this flag is set to value of 0, multiple  
tunnel
       support SHOULD be disabled.

[JiK] Why just SHOULDs ? Isn't it MUST for disabling? In what occasion
      the multiple tunnel support could be allowed if it is disabled?

Section 9.

[JiK] Interface type registry is missing? Also, maybe it could be useful
       to describe what range of error codes are used for both
       MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA &  
MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA.

Section 10.

[JiK] Well, if you DoS a mobile node that has multiple tunnels  
connected,
       you can DoS the mobile node way harder than just through one  
interface &
       tunnel ;)

--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 12 Jan 2009 23:39:30 -0800

Hi Jouni,

Thanks for the review comments. Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of jouni korhonen
> Sent: Monday, January 12, 2009 2:28 PM
> To: [email-masked]; Sri Gundavelli
> Subject: [Mip4] Comments on 
> draft-gundavelli-mip4-multiple-tunnel-support-00
> 
> Hi Sri, authors,
> 
>        mention it as the only use case. The same comment

I agree. Its certainly not the only use case. May be the most
obvious one. Will reword it.

> concerns also  

There should not be any restrictions when supporting multiple HoA's.
The HoA set is reachable via any of these routing paths. Will clarify
this.

>        physical interface? Or can an interface be an alias interface

It should not matter, if the interface is physical or some other
form such as a tunnel. From the mobile perspective, that interface
can be used for sending L2/L3 traffic out. For CCOA case, this interface
has a valid CcoA address. In chained cases, this interface can be a
tunnel.

>        HoAs BIDs would still be unique? How this would be done?

The binding associates the HoA, interface and the HA. This will
be different, if any of these parameters change. So, between
the MN and the HA, when using one HoA or more HoA's, a given
binding always identifies one set. The MN will not propose the
binding id, for one HoA, if the same id is in use for the other
HoA. But, it makes sense to change it to "unique per HoA", I
agree.

> [JiK] A "roaming interface" is...?

Ok.

> [JiK] I would like to see similar text from a mobile node 

Sure.

> [JiK] s/MUST not/MUST NOT

Ok
 
>        mention of a registry etc.

May be 5213 ATT registry. Will add the pointer.

> [JiK] Is it actually per HoA, not per mobile node?

Ok

>        misleading and optimistic.. For example a 54MB WLAN behind a 1M

With 802.21, there are IE's to carry such information. 

> [JiK] Does the mechanism in this specification work with "traditional"

Yes. The simulcast has no bearing on this.

>       the multiple tunnel support could be allowed if it is disabled?

Sure.

> MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA.

Ok

>        you can DoS the mobile node way harder than just through one  

:) Well, I see the positive side :)

Thanks for the review.

Sri

---

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Jan 2009 11:08:04 +0200

Hi Sri,

Thanks for the replies. Got few more things to comment.

> Thanks for the review comments. Please see inline.

[snip]

> With 802.21, there are IE's to carry such information.

802.21 would still deliver a local view of the information, which would
still be something different than e2e path information. Unless one can
assume certain rather closed deployment. I'd like to document to state
that If-BW is just an indicative guess at best.

>>       only that interface that happens to be on the home link?

Seems you missed this?

[snap]

Cheers,
	Jouni

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 13 Jan 2009 16:23:23 -0800 (PST)

Hi Jouni,

Please see inline.

> that If-BW is just an indicative guess at best.

If the information about the air link is predictable, this should
be sufficient, as the bottle neck is in the airlink. I assume .21
can provide that information. However, as you say, its always an
indicative guess. Sure, we can add as you suggested.

>> >       only that interface that happens to be on the home link?

Simultaneous home and roam, I was not sure how important this will be.
It can be supported, wanted to avoid too many changes on the HA just
to support this feature. If this needed, we can cover this.

Regards
Sri

---

From: "jouni korhonen" <[email-masked]>
Date: Wed, 14 Jan 2009 09:15:56 +0200

Hi Sri,

> to support this feature. If this needed, we can cover this.

I see. Well, I don't have a strong preference of the final behavior.
Minimizing changes to a HA is a good argument ;)  However, the case I
was thinking of is the following. The MN is registered to a HA via 4
interfaces (all roaming). Let us assume that if1-3 are high bandwidth
and if4 is rather poor contributing ~10% of the aggregated bandwidth.
If it happens that the if4 enters the home link, all if1-4 get
de-registered but only the if4 can continue to exchange traffic
between the MN and the HA. This would cause a significant degrease on
the aggregated bandwidth... unnecessarily.

Cheers,
      Jouni