flow bindings are not for NEMO

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:alexandru.petrescumotorola.com]
> 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
> Monami6ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6

_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6

Tsirtsis, George wrote:
> 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?

Yes.

Alex

> 
> George
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:alexandru.petrescumotorola.com] 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 Monami6ietf.org 
>> https:
//www1.ietf.org/mailman/listinfo/monami6
> 
> _______________________________________________ Monami6
mailing
> list Monami6ietf.org 
> https:
//www1.ietf.org/mailman/listinfo/monami6
> 


_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6

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:

> Tsirtsis, George wrote:
>> 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?
>
> Yes.
>
> Alex
>
>> George
>>> -----Original Message----- From: Alexandru
Petrescu
>>> [mailto:alexandru.petrescumotorola.com] 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 Monami6ietf.org https:
//www1.ietf.org/mailman/listinfo/monami6
>> _______________________________________________
Monami6 mailing
>> list Monami6ietf.org https:
//www1.ietf.org/mailman/listinfo/monami6
>
>
> _______________________________________________
> Monami6 mailing list
> Monami6ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6


_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6