Subject: Re: [Mip4] Call for WG adoption:draft-gundavelli-mip4-multiple-tunnel-support-03.txt

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Sep 2010 13:41:40 +0200

Le 18/08/2010 20:28, Sri Gundavelli a écrit :
> Hi Pete:
>
> Sure. Thanks. I will post the -00 version of the WG doc.
>
> Regards Sri

Thanks Sri for posting 00 WG item of mip4-multiple-tunnel-support.

I have an almost prototype implementation of MIP4 on Mobile Router doing
simultaneous use of multiple interfaces for bandwidth augmentation.
That is similar in spirit to this draft.  It has however some differences:

o does not use flows.
o needs dynamic assignment of private addresses (10.x) on additional
   GRE tunnels (in addition to the Mobile IP tunnel).

   In a way, the current draft encoding could accommodate this 10.x
   address - just add another "CoA" in the multiple interface list as
   Alternate CoA.

   But.

   This 10.x is not a CoA because it is topologically correct in the
   home network, not in the foreign network.  IT shouldn't be called
   "CoA" but something else.  I call it "10.x" for now.

   Its Interface Type field is not that  of the real interface (it's not
   3G, nor WiFi, etc. - it's GRE).

   The HA address ("remote" parm of a GRE tunnel) is not a unique
   address of HA, but it is different for each 10.x address - it is the
   publicly routable address of the HA assigned on the GRE tunnel on HA.

   These HA addresses also need to be communicated in the RegReq.

I think Mobile IP messages are good place to dynamically assign these
additional 10.x addresses (in addition to the multiple CoAs per single
HoA) and the multiple HA addresses.

This still keeps MR reachable at a single HoA - but RegReq should
contain multiple CoAs (this draft), multiple HA addresses (not in this
draft) and multiple 10.x addresses (not in this draft either).

I am wondering whether the draft can be modified to accommodate this
behaviour.

Alex

>
>
> On Aug 18, 2010, at 11:25 AM, McCann Peter-A001034 wrote:
>
>> Sri,
>>
>> Please go ahead and submit this as
>> draft-ietf-mip4-multiple-tunnel-support-00.txt
>>
>> I have registered approval for the -00 version with the
>> secretariat.
>>
>> -Pete
>>
>>
>> McCann Peter-A001034 wrote:
>>> This is a call for WG adoption of
>>> draft-gundavelli-mip4-multiple-tunnel-support-03. A copy of the
>>> draft is here:
>>>
>>>
>> http://tools.ietf.org/html/draft-gundavelli-mip4-multiple-tunnel-support
>>>
>>
>>
-03
>>>
>>> This draft would fulfill charter item 5 which you can view on our
>>> charter here:
>>>
>>> http://tools.ietf.org/wg/mip4/charters
>>>
>>> Please send your comments for or against adoption of this draft
>>> as a working group item by the end of this week, Friday
>>> 8/13/2010.
>>>
>>> Thanks,
>>>
>>> -Pete
>>
>
> -- 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: Tue, 14 Sep 2010 13:57:13 -0700

Hi Alex:

Sorry for the late reply.

> That is similar in spirit to this draft.  It has however some differences:

I assume you are doing per-packet load balancing ? I may have very well
misunderstood your comment. If not and I'm sure you know this, splitting a
given flow across access networks, can be undesirable for certain real time
media flows. It will result in flow re-ordering issues and undesirable
jitter values. AFAIK, Transport AD is against such approach. But, in the
absence of negotiated flow policies, the tunnel peers can always do
per-packet load balancing.

>    GRE tunnels (in addition to the Mobile IP tunnel).

I'm still missing the point. Is the address assignment more like VPN inner
address ? In other words, your topologically correct address, is the
dynamically assigned HoA, the mobile node uses that address, or from that
block for all the application flows ?

>    address - just add another "CoA" in the multiple interface list as

Currently, we have this relationship.

HoA is reachable via Tunnel0, Tunnel1, Tunnel2.
Each Tunnel has a specific encap type and has a src, dst addresses. The CoA
is the dst address of the tunnel from the HA perspective, and is the address
bound to a given interface of the mobile node.

I could not understand, how your approach is modifying this relation. I
tried to read this text few times, I could not get the idea. May be, if you
can reword it a bit, or offline discussion will be great.

Regards
Sri

> --
> 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: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Sep 2010 22:15:53 +0200

Le 14/09/2010 22:57, Sri Gundavelli a écrit :
> On 9/11/10 4:41 AM, "Alexandru
> Petrescu"<[email-masked]> wrote:
>
>> I have an almost prototype implementation of MIP4 on Mobile Router
>> doing simultaneous use of multiple interfaces for bandwidth
>> augmentation. That is similar in spirit to this draft.  It has
>> however some differences:
>>
>> o does not use flows.
>
> I assume you are doing per-packet load balancing ?

YEs, that's what I meant - per-packet distribution (or load balancing if
you wish).

> I may have very well misunderstood your comment. If not and I'm sure
> you know this, splitting a given flow across access networks, can be
> undesirable for certain real time media flows.

Hmm... I am not sure about this undesirability.  It very much depends on
what you mean by a 'media flow'.

> It will result in flow re-ordering issues and undesirable jitter
> values.

That sounds scary in a way.

But I am not sure packets from one end of Internet to another take the
same path either, yet these re-ordering issues are not disturbing one
end's TCP (for example) to work just fine.

> AFAIK, Transport AD is against such approach. But, in the absence of
> negotiated flow policies, the tunnel peers can always do per-packet
> load balancing.

I agree if I understand you correctly.

I would like to ask otherwise: how else than this proposed per-packet
distribution on the MR could one achieve bandwidth augmentation
independently of the application?

I mean: we can have 'negotiated flows' - ok, but that will not result in
scalable bandwidth augmentation.  A UDP flow will be assigned to an
interface and will not disturb another UDP flow on another iface - ok.
But that a single UDP flow (when nobody else is there) could not take
advantage of two interface simultaneously.

As I understand the MIP flow concept a flow can only flow through one
interface.

>> o needs dynamic assignment of private addresses (10.x) on
>> additional GRE tunnels (in addition to the Mobile IP tunnel).
>>
>
> I'm still missing the point. Is the address assignment more like VPN
> inner address ? In other words, your topologically correct address,
> is the dynamically assigned HoA, the mobile node uses that address,
> or from that block for all the application flows ?

I am not sure what you mean by VPN inner address.

In the picture I sent in Maastricht bit.ly/mip4-mdimcoa there's a single
virtual interface TUN0 holding a single Mobile IP HoA.  There are two
publicly routable CoAs each on a real 3G+ interface.  There are two GRE
tunnels each with a "local" address 10.x (topologically correct at
home).  Each of these GRE also has a "remote" address which is a
publicly routable address (in the same routable space as the HoA) 193.x.

The HA maintains two bindinds: HoA-193...175 and HoA-193...176.
The HoA is 193...187.

> Currently, we have this relationship.

Yes, conceptually.

> HoA is reachable via Tunnel0, Tunnel1, Tunnel2. Each Tunnel has a
> specific encap type and has a src, dst addresses. The CoA is the dst
> address of the tunnel from the HA perspective, and is the address

On MR, do you mean you have two Tunnels with the same src address (the
HoA)?  On linux it is impossible to get this.  Once you set up two
IP-in-IP tunnels with the same "local" address the kernel is unable to
multiplex outgoing packets.  It will use the last in the list.  This is
normal, there is no distinction in a packet telling the kernel which
Tunnel interface to use for outgoing packets.

The only solution here (in my lab) is to use GRE tunnels which have _no_
"local" address.  The kernel distinguishes them on a key in the header,
I believe arbitrarily generated or so.

With IP-in-IP tunnels it is impossible to set _no_ "local" address.

When I saw this I said to myself what a wonderful reason for GRE tunnels.

Remark, here I get GRE encapsulation, but this is in addition to the
IP-in-IP encapsulation of Mobile IP, which should supposedly happen with
the unique HoA of the TUN0.  What I am supposed to do here is
IP-in-IP-in-GRE. (I've only done IP-in-GRE as of now).  It should work.

> I could not understand, how your approach is modifying this
> relation. I tried to read this text few times, I could not get the
> idea. May be, if you can reword it a bit, or offline discussion will
> be great.

Well.  It is not very clear to me either.

It is  however an implementation which works offering simultaneous use
of multiple interfaces on MR for bandwidth augmentation (independent of
the application type - any application takes advantage of it, without
defining flows); also offering reachability at a unique permanent HoA,
and session continuity when the CoAs of the real interfaces change.

It needs dynamic assignment of addresses: HA should tell MR several
addresses (in addition to the unique HoA configured with other than
Mobile IP means) all topologically correct in the home network.

Currently we do this assignment manually.

We could do this assignment with Mobile IP RegReq - it would be
advantageous.

This does not use flow bindings.

I can try to reword if you wish.  It is my only reason to participate in
co-authoring this draft.  I am not that much of a fan of flow bindings,
actually.

I can reply separately about the flow bindings concept altogether (what
_is_ a flow?) and about its implementability (how does one set two
IP-in-IP tunnels with the same local address? doesn't work on linux).

About discussion offline - I am very much against setting things
offline.  If needed I prefer face-to-face or audioconference.  I also
agree that we may generate too many messages on a list which may disturb
- but I try to rate limit.

Alex

>> Its Interface Type field is not that  of the real interface (it's
>> not 3G, nor WiFi, etc. - it's GRE).
>>
>> address of HA, but it is different for each 10.x address - it is
>> the publicly routable address of the HA assigned on the GRE tunnel
>> on HA.
>>
>> I think Mobile IP messages are good place to dynamically assign
>> these additional 10.x addresses (in addition to the multiple CoAs
>> per single HoA) and the multiple HA addresses.
>>
>> contain multiple CoAs (this draft), multiple HA addresses (not in
>> this draft) and multiple 10.x addresses (not in this draft
>> either).
>>
>> I am wondering whether the draft can be modified to accommodate
>> this behaviour.
>>
>> Alex
>>
>>>
>>>
>>>>> draft-gundavelli-mip4-multiple-tunnel-support-03. A copy of
>>>>> the draft is here:
>>>>>
>>>>>
-03
>>>>>
>>>>> This draft would fulfill charter item 5 which you can view
>>>>> on our charter here:
>>>>>
>>>>> Please send your comments for or against adoption of this
>>>>> draft as a working group item by the end of this week, Friday
>>>>> 8/13/2010.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Pete
>>>>
>>>