Subject: RE: [Monami6] flow bindings are not for NEMO

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 14 Nov 2006 08:16:29 -0800

Alex,

Based on the discussion below we should be able to agree on the
following:

Flow Binding works for NEMO as long as the MR can control the process
e.g., based on generic or LFN/MNN specific configuration in the MR.
There is additional work that may need to be done if one wants an
MNN/LFN to dynamically request certain behavior from the MR.

Is this a fair statement?

George
> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, November 14, 2006 11:02 AM
> To: Monami6 WG
> Cc: Soliman, Hesham
> Subject: Re: [Monami6] flow bindings are not for NEMO
> 
> Tsirtsis, George wrote:
> > But Alex, this happens already in the internet. Routers load
> > balance traffic on behalf of end nodes every day and the end nodes
> >  are not involved.
> 
> This is fixed end nodes, not mobiles, with homogeneous links - almost
> always stable.
> 
> It is also a model where ISP routers load balance traffic, and
> subscribers pay for higher quality of service.  In smallest NEMO
> contexts (PAN) there wouldn't be such relationships between MR and LFN
> - both would be owned by same person.
> 
> > In a lot of NEMO applications this is still likely to be
> > sufficient.
> 
> Ok.
> 
> > What you are arguing for is a *new* thing, with which an end node
> > can instruct a router on how to route its traffic.
> 
> Best effort routing should happen without end host involvement.  But
> appreciative routing (load balancing, traffic shaping, whatever) are
> for end host.
> 
> > I would argue that this is separate and thus out of scope of the
> > basic functionality needed for MHs/MRs for flow bindings.
> 
> You seem to say not only out of scope, but also MRs have the right to
> load-balance regardless of LFNs' preferences; and you seem to agree
> NEMO already does that for the prefix.
> 
> I agree out of scope.
> 
> I don't agree MRs should ever load balance on behalf of LFNs without
> proper authorization.
> 
> I don't agree MR does anything insecure for MNP (HA prohibits it) and
> hence it shouldn't be allowed to do anything insecure for flows
either.
> 
> We may turn in circles :-)
> 
> Let's look at the looping problem: what do MH's preferences become
> when connecting to a MR?  If a WimAx-WiFi MH prefers WiFi for http and
> the WiMax-WiFi MR prefers WiMax instead, and MH connects through WiFi
> to MR doesn't this translate into MH using WiMax for http, despite its
> preference being WiFi?
> 
> I think we should not claim flow bindings are for NEMO.
> 
> Alex
> 
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Nov 2006 18:37:00 +0100

Tsirtsis, George wrote:
> Flow Binding works for NEMO as long as the MR can control the
> process e.g., based on generic or LFN/MNN specific configuration in
> the MR. There is additional work that may need to be done if one
> wants an MNN/LFN to dynamically request certain behavior from the
> MR.
> 

Yes.

Alex

> 
> George
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Tuesday, November
>> 14, 2006 11:02 AM To: Monami6 WG Cc: Soliman, Hesham Subject: Re:
>> [Monami6] flow bindings are not for NEMO
>> 
>> Tsirtsis, George wrote:
>>> balance traffic on behalf of end nodes every day and the end
>>> nodes are not involved.
>> This is fixed end nodes, not mobiles, with homogeneous links -
>> almost always stable.
>> 
>> contexts (PAN) there wouldn't be such relationships between MR
>> and LFN - both would be owned by same person.
>> 
>>> What you are arguing for is a *new* thing, with which an end
>>> node can instruct a router on how to route its traffic.
>> Best effort routing should happen without end host involvement.
>> But appreciative routing (load balancing, traffic shaping,
>> whatever) are for end host.
>> 
>>> I would argue that this is separate and thus out of scope of
>>> the basic functionality needed for MHs/MRs for flow bindings.
>> You seem to say not only out of scope, but also MRs have the
>> right to load-balance regardless of LFNs' preferences; and you
>> seem to agree NEMO already does that for the prefix.
>> 
>> I agree out of scope.
>> 
>> I don't agree MRs should ever load balance on behalf of LFNs
>> without proper authorization.
>> 
>> I don't agree MR does anything insecure for MNP (HA prohibits it)
>> and hence it shouldn't be allowed to do anything insecure for
>> flows
> either.
>> Let's look at the looping problem: what do MH's preferences
>> become when connecting to a MR?  If a WimAx-WiFi MH prefers WiFi
>> for http and the WiMax-WiFi MR prefers WiMax instead, and MH
>> connects through WiFi to MR doesn't this translate into MH using
>> WiMax for http, despite its preference being WiFi?
>> 
>> _______________________________________________ Monami6 mailing
>> list [email-masked] 
> _______________________________________________ Monami6 mailing
> list [email-masked]

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 15 Nov 2006 10:40:26 +0900

Hi George and All

The problem here is important one for the scope of flow distribution.  
It is not related only to flow binding.

In MIP6, the mobile node has multiple interfaces and can distribute  
flow to multiple paths.
However, in the NEMO case, intermediate node (i.e. MR) has multiple  
paths to HA.
Since this is NEMO, end node is not aware of multiple paths between  
MR-HA. (No RO and intermediate router, MR).

Therefore, it is no way for LFN/MNN to know what kind of paths which  
MR manages.
As a result, there is no way for LFN/MNN to tell the preference to MR  
(since LFN cannot know the paths condition of MR).

If Monami6 wants to support end-end policy exchange in general, NEMO  
is very special scenario.
We need additional schemes such as:
- MR advertises the egress interfaces info.
- LFN updates its preference to MR.

Of course, we have to consider some race condition of filter in MR,  
if large number of LFN update their preference.
I mean all the LFN may request WiMAX for all traffic instead of using  
3G. This is not desirable scenario.

To me, these feature needs a lot of work.
Within the current charter, we should stick to the static case for NEMO.
Then, we may think of above feature when the Monami6 finish the  
current charter items.

regards,
ryuji

On 2006/11/15, at 2:37, Alexandru Petrescu wrote:

>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>> list [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>
>

---

From: Andy Huang <[email-masked]>
Date: Wed, 15 Nov 2006 10:46:48 +0800

Hi all:

The problem is interesting, but I think it is not only for MR which has 
multiple paths to HA, but for the 'simple' MR which has just one paths to 
HA. Let's suppose there are multiple MRs in the mobile network and every MR 
uses the different wireless interface. It's also important for MR to inform 
MNNs of egress interface information. These information will help MNNs to 
decide default router selection and source address selection, consequently 
decide uplink and downlink path selection. On this point, maybe this problem 
is more NEMO-sepcific.

Best regards

----- Original Message ----- 
From: "RYUJI WAKIKAWA" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>
Sent: Wednesday, November 15, 2006 9:40 AM
Subject: Re: [Monami6] flow bindings are not for NEMO

> Hi George and All
>
> The problem here is important one for the scope of flow distribution.  It 
> is not related only to flow binding.
>
> In MIP6, the mobile node has multiple interfaces and can distribute  flow 
> to multiple paths.
> However, in the NEMO case, intermediate node (i.e. MR) has multiple  paths 
> to HA.
> Therefore, it is no way for LFN/MNN to know what kind of paths which  MR 
> manages.
> If Monami6 wants to support end-end policy exchange in general, NEMO  is 
> very special scenario.
> Of course, we have to consider some race condition of filter in MR,  if 
> large number of LFN update their preference.
> I mean all the LFN may request WiMAX for all traffic instead of using  3G. 
> This is not desirable scenario.
>
> Then, we may think of above feature when the Monami6 finish the  current 
> charter items.
>
> regards,
> ryuji
>
>
>
>
>
>
>
>>>>> But Alex, this happens already in the internet. Routers load  balance 
>>>>> traffic on behalf of end nodes every day and the end
>>>>> nodes are not involved.
>>>>> In a lot of NEMO applications this is still likely to be  sufficient.
>>>> Ok.

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 15 Nov 2006 12:30:09 +0100

Dear all,

I'm removing the NEMO ML and stick Monami6 where the discussion
initiated, otherwise that will make the discussion complex.

Solving all these cases (multiple HAs, multiple MRs, multiple prefixes)
is very important for deloying Monami6 scenarios. The issues are
described in draft-ietf-nemo-multihoming-issues, and few are
NEMO-specific. On a general basis, issues are IPv6 specific, and there
is no WG to solve them. Probably Monami6 is the right place to
investigate them because mobility is an excellent use case for these
configurations.

draft-ietf-nemo-multihoming-issues is also pointing to the need to
exchange some data between MR and MNNs to take good decisions. It is not
obvious to me that the MR would have to advertise which interfaces are
available, it could just advertise the type of available interfaces, or
not advertising anything at all and let the applications running on MNNs
to tell their preferences (bandwidth requirements, abillity to pay for
services, delay, etc).

Thierry

On Wed, 15 Nov 2006 10:46:48 +0800

---

From: Andy Huang <[email-masked]>
Date: Thu, 16 Nov 2006 13:54:42 +0800

Hi, all

I think the problem should be considered separately in different situations. 
The first one is the mobile network where there is the only MR which has 
multiple paths to its HA, another one is the mobile network where there is 
multiple MRs which have the only path to their HAs(HA). I don't want to be 
involved in the argument of the former situation, but as to the latter 
situation, for example, imagining the scenario of (n,1,n) in 
draft-ietf-nemo-multihoming-issues, MNNs could not decide which address is 
more suitable for the specific service because of lack of those MRs egress 
interface information. Even if there is a mechanism which allows MN to 
exchange preferences with HA, VMN in such mobile network could not use the 
mechanism because they don't know the corresponding wireless technology of 
these CoAs at all. Considering this point, it is necessary for MR to 
advertise egress interface information to MNN, at least it can help VMNs to 
decide which CoA should be binded with flows or services. What's more, as 
draft-ietf-nemo-multihoming-issues described, these interface information 
can help default router selection and path selection .

Any comments?

Best regards
Zhigang Huang

----- Original Message ----- 
From: "Thierry Ernst" <[email-masked]>
To: "Monami6 WG" <[email-masked]>
Sent: Wednesday, November 15, 2006 7:30 PM
Subject: Re: [Monami6] flow bindings are not for NEMO

>>> flow
>>> paths
>>>>>>> balance

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 16 Nov 2006 14:24:52 +0800

Hi, 

> From: Andy Huang [mailto:[email-masked]] 
> Sent: Thursday, November 16, 2006 1:55 PM
> To: Monami6 WG
> The first one is the mobile network where there is the only 
> MR which has multiple paths to its HA, another one is the 
> mobile network where there is multiple MRs which have the 
> only path to their HAs(HA).

[Ben] Unless I'm missing something, the only diference between the first and
second situation is that the second has an addition portion of default
router selection. By advertising egress info, it will definitely help in the
path selection for MNN in both situation. Is there a reason for them to be
consider them separately?

Regards,
Benajmin Lim

I don't want to be involved in 
> the argument of the former situation, but as to the latter 
> draft-ietf-nemo-multihoming-issues, MNNs could not decide 
> which address is more suitable for the specific service 
> because of lack of those MRs egress interface information. 
> Even if there is a mechanism which allows MN to exchange 
> preferences with HA, VMN in such mobile network could not use 
> the mechanism because they don't know the corresponding 
> wireless technology of these CoAs at all. Considering this 
> point, it is necessary for MR to advertise egress interface 
> information to MNN, at least it can help VMNs to decide which 
> CoA should be binded with flows or services. What's more, as 
> draft-ietf-nemo-multihoming-issues described, these interface 
> information can help default router selection and path selection .
> 
> Any comments?
> 
> Best regards
> Zhigang Huang