Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13

From: Christian Kaas-Petersen <[email-masked]>
Date: Mon, 11 May 2009 08:09:09 +0000 (GMT)

When the mobile node is a 3GPP mobile phone, the mobile phone is at
home when it uses its 3GPP radio link.  The mobile phone may have
roamed to another operator's network.  In this case, IP packets take
one IP hop, but doing this one IP hop means traversing
many GTP, PMIP, or other tunnels, before the final stretch may be
a low-bandwidth radio link.  Assuming the 3GPP mobile phone also has
wireless LAN, and wireless LAN is available, then the mobile phone
can have its traffic delivered on the wireless
LAN at a much higher bandwidth.  IP packets will take many IP hops,
but the final stretch is a high-bandwidth radio link.  In this analysis,
only the bandwidth on the radio link is considered a limiting factor. 
This is the use case I have in mind.

As I understand the CoA-on-the-home-link approach,
this approach is still making use of the low-bandwidth radio link.

To good question is, how often will a user be in a situation with
a low-bandwidth 3GPP radio link and at the same time having 
high-bandwidth wireless LAN access.

Christian

--- Den lør 9/5/09 skrev Romain KUNTZ <[email-masked]>:

> Fra: Romain KUNTZ <[email-masked]>
> Emne: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13
> Til: "mext" <[email-masked]>
> Dato: lørdag 9. maj 2009 18.56
> Hi,
> 
> Some comments on draft-ietf-monami6-multiplecoa-13.
> 
> First, I'd like to express that I support Arnaud's opinion
> about section 5.6 (Simultaneous Home and Visited Link
> Operation). I also don't see what is the motivation to
> re-route and tunnel traffic from the HA to one of the MN's
> CoA, while the MN is only one hop from the HA. Even if there
> is a specific use-case, at the time this topology was
> suggested, a simple solution that came out was to configure
> a CoA on the Home link and use a tunnel via the home link. I
> don't think the little overhead of this solution justifies
> the complexity of the one proposed in the draft.
> 

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 11 May 2009 10:49:47 +0200

Hi,

> This is the use case I have in mind.

Thanks for describing that use case, Christian. Someone also briefly
commented to me off-list that the content of section 5.6 was needed to
support 3GPP specific needs.

> this approach is still making use of the low-bandwidth radio link.

Well, no. The MN considers the Home Link (3GPP link) as a foreing
link. It has other more efficient connection means (CoA2 on wifi iface,
...) and configure a CoA on the 3GPP radio link (say CoA1), i.e. does
not deregister with the HA. This allows it to have the HA send the
traffic to CoA2.

> high-bandwidth wireless LAN access.

At home or in a corporate network, chances are very high it will have
access to a high bandwidth WLAN. When moving, access to an WLAN depends
on many factors (country, location in the country, ...). In the end,
it's difficult to provide a common answer.

I am not familiar with 3GPP architectures so following comment is
probably stupid: if the 3GPP access is bad compared to another
simultaneous access I have, why not just switch off the 3GPP link in
order not to use it and simply use the other access as a common foreign
network (configure a CoA, register it to the HA, ...) ? 

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 12:55:42 +0200

Hello Arnaud,

On Monday 11 May 2009, Arnaud Ebalard wrote:
> order not to use it and simply use the other access as a common
> foreign network (configure a CoA, register it to the HA, ...) ?

The 3GPP access may be worse than the WLAN in some aspects (e.g. 
bandwidth) but better in other aspects (e.g. latency, packet loss), 
thus it makes sense to allow to receive some traffic (say VoIP) on the 
home link (3GPP access) while diverting some other traffic (say bulk 
data transfer) on the foreign link (non-3GPP access, e.g. a WLAN).

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 12:59:15 +0200

On Monday 11 May 2009, Arnaud Ebalard wrote:
> link. It has other more efficient connection means (CoA2 on wifi
> iface, ...) and configure a CoA on the 3GPP radio link (say CoA1),
> i.e. does not deregister with the HA. This allows it to have the HA
> send the traffic to CoA2.

In 3GPP it isn't up to the MN to consider where is the home link, it is 
an architectural choice that was made. 

The home link _is_ the 3GPP access.

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 11 May 2009 13:09:37 +0200

Hi Julien,

> data transfer) on the foreign link (non-3GPP access, e.g. a WLAN).

Well, that makes sense. Even if I don't like the solution in term of
complexity, I understand the motivation based on your argument and the
explanation from Christian. Thanks.

Considering the example you give, maybe you have some comment (in the
context of MCoA) on the current inability for a MN that has a binding
with a CN  to tell that CN that it should route some flows to the HoA of
the MN instead of sending those to the CoA.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 15:42:04 +0200

On Monday 11 May 2009, Arnaud Ebalard wrote:
> >> simultaneous access I have, why not just switch off the 3GPP link
> >> in order not to use it and simply use the other access as a common
> > thus it makes sense to allow to receive some traffic (say VoIP) on
> > the home link (3GPP access) while diverting some other traffic (say
> > bulk data transfer) on the foreign link (non-3GPP access, e.g. a
> > WLAN).
>
> complexity, I understand the motivation based on your argument and
> the explanation from Christian. Thanks.
>
> with a CN  to tell that CN that it should route some flows to the HoA
> of the MN instead of sending those to the CoA.

Without my WG chair hat: Since route optimization is in my view a 
central piece of the MIPv6 design, I would consider that inability as a 
flaw. 

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 11 May 2009 16:00:09 +0200

Hi,

> central piece of the MIPv6 design, I would consider that inability as a 

Thanks for that straight answer, Julien.

Initially in my review, I proposed to use the specific BID #0 (reserved
at the moment but I don't know precisely why) to reference the HoA. I'll
have to investigate that but this may possibly provide a simple and
efficient solution. Well, I thought it was worth mentioning if you had
missed that specific email.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 16:16:49 +0200

On Monday 11 May 2009, Arnaud Ebalard wrote:
> >> > bandwidth) but better in other aspects (e.g. latency, packet
> >> > loss), thus it makes sense to allow to receive some traffic (say
> >> > VoIP) on the home link (3GPP access) while diverting some other
> >> > traffic (say bulk data transfer) on the foreign link (non-3GPP
> >> > access, e.g. a WLAN).
> >>
> >> Well, that makes sense. Even if I don't like the solution in term
> >> of complexity, I understand the motivation based on your argument
> >> and the explanation from Christian. Thanks.
> >>
> >> Considering the example you give, maybe you have some comment (in
> >> the context of MCoA) on the current inability for a MN that has a
> >> binding with a CN  to tell that CN that it should route some flows
> >> to the HoA of the MN instead of sending those to the CoA.
> >
> > central piece of the MIPv6 design, I would consider that inability
> > as a flaw.
>
> Initially in my review, I proposed to use the specific BID #0
> (reserved at the moment but I don't know precisely why) to reference
> the HoA. I'll have to investigate that but this may possibly provide
> a simple and efficient solution. 

It seems to me that BID #0 isn't required to support the usecase we're 
discussing -- Wouldn't it be sufficient that the MN use the BID 'H' 
flags with the CN in a fashion similar to what is done with the HA?

> Well, I thought it was worth mentioning if you had missed that
> specific email. 

I had, thanks for the pointer.

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 11 May 2009 16:47:24 +0200

Hi,

> flags with the CN in a fashion similar to what is done with the HA?

I think it may be possible to do it that way, yes.

I would just be reluctant (again, just my opinion) to base that feature
on things that may possibly not be in all implementation (content of
section 5.6 and associated structures, i.e. 'H' flag). Another reason
would be that -- even if I have the Home Network case in mind -- I did
not limited the routing of flows to the HoA by CN only to the case where
the MN is at home. Which is the case covered by section 5.6 and H flag.

In the end, BID #0 or reuse of 'H' flag are both sufficient marks in
the BID to tell the peer we are speaking about the HoA.

Cheers,

a+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 11 May 2009 16:44:49 -0700

Hi Arnaud and Julien,

On 2009/05/11, at 6:42, Julien Laganier wrote:

> as a

This isn't a flow.

In Mobile IPv6, when MN registers its binding to CN, MN cannot tell  
some flow is sent without RO.
It is same here in MCoA. For the binding management, we don't offer  
any solution for this.
This is more like flow handling matter which is out of scope in the  
MCoA.
You can use flow binding spec to direct some of flow to bypass the RO.

regards,
ryuji

>
>
> --julien
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 12 May 2009 09:01:49 +0200

Hi Ryuji,

> some flow is sent without RO.

That's correct but MIPv6 was restricted to a single binding and route
for communications bewteen MN-HA and MN-CN. Because MCoA removes that
restriction, I don't see your point about citing a missing feature of
MIPv6 as an argument not to have it in MCoA. IMHO, MCoA is the place
where all the possible destination should be handled, including the
HoA.

>From my perspective, MCoA *is* about binding management.

> This is more like flow handling matter which is out of scope in the

The thing is that at the moment the MCoA draft is the one providing
information about the address to which the traffic is expected to go
(via the content of the BID). If you cannot express the direction is the
HoA with what is in the draft, next documents will have to modify the
semantic of the BID, instead of simply use it. Or do I fail to
understand how you want that to be handled?

> You can use flow binding spec to direct some of flow to bypass the RO.

See above.

Cheers,

a+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 13 May 2009 15:30:20 -0700

Hi Arnaud,

>From the protocol point of view, we have two choices here.
- having special binding for the HoA destination
- having flow management to skip RO

Since RO is not so important at this point, we should go with the
minimal spec which mean the second option.
You can put all the possible features in the MCoA, but the draft is
not discussed in that direction at this stage.
We can always revisit the spec once we "really need" such extension.

> (via the content of the BID). If you cannot express the direction is the

Before the binding, we need to have additional mechanism to the
binding selection.

> understand how you want that to be handled?

We shouldn't change the semantics of BID for this.
We can't modify the spec after completing WG/IETF/IESG LC, but we only
accept minor changes for clarification and editorial errors.
Otherwise, we will get into endless cycles.

Anyway, IMO, your feature can be achieved with the current MCoA spec
with flow binding.

regards,
ryuji

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 14 May 2009 09:31:21 +0200

Hi,

>From my perspective, RO is important.

> not discussed in that direction at this stage.

Julien, George, what do you think? Is the feature a simple and logical
addition for the flow-inding draft? If not, I fail to see how it can be
specified in an external document extending both (MCoA and
flow-binding).

> Anyway, IMO, your feature can be achieved with the current MCoA spec

I'll let the final word to Julien and George.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Thu, 14 May 2009 11:53:40 +0200

Hello all,

> > - having flow management to skip RO

I am sympathetic to the view that MCoA is about multiple binding 
management.

It is also my understanding that it would not make sense to create a 
special binding for the HoA: a MIPv6 binding is between a HoA and 
another address, the CoA. It would not make sense to bind the HoA to 
itself.

Thus, I think the functionality we've talking about can be implemented 
in a semantically clean way by "having flow management to skip RO" as 
Ryuji puts it.

> From my perspective, RO is important.

I agree it is, but as I try to point out above, diverting some of the 
traffic to the HoA while other traffic goes to (one of) the CoA is in 
my view a flow management issue and has nothing to do with multiple 
binding management.

> Julien, George, what do you think? Is the feature a simple and
> logical addition for the flow-inding draft? If not, I fail to see how
> it can be specified in an external document extending both (MCoA and
> flow-binding).

I happen to believe that it's reasonable simple to add the feature to 
the flow binding draft (one possibility would be to use BID set to zero 
in a FID to indicate that forwarding to HoA is desired, as I believe 
you proposed earlier.) 

> [...]
> > We can't modify the spec after completing WG/IETF/IESG LC, but we
> > only accept minor changes for clarification and editorial errors.
> > Anyway, IMO, your feature can be achieved with the current MCoA
> > spec with flow binding.
>

Agree with Ryuji on this.

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 14 May 2009 13:10:59 +0200

Hi,

> in a FID to indicate that forwarding to HoA is desired, as I believe 

If you mean for instance by extending the description of BID field in
section 4.2.1 of flow-binding draft (4.2.1. Binding Reference
Sub-option) to associate value 0 to the HoA, then it's ok for me.

> Agree with Ryuji on this.

Ack.

Cheers,

a+