Subject: Re: [MEXT] Important considerations for directionality of flowbindings

From: <[email-masked]>
Date: Tue, 2 Jun 2009 16:11:48 +0200

Hi all,

Please see inline comment.

Regards,
Pierrick 

> ________________________________________
> De : [email-masked] [mailto:[email-masked]] De la part de
> Yuri Ismailov
> Envoyé : vendredi 29 mai 2009 09:35
> À : Hesham Soliman; mext
> Objet : Re: [MEXT] Important considerations for directionality of
> flowbindings
> 
> Hesham,
> This is nice story and makes some sense for the discssion, however some
> details are ommited. In your adventure with the helpdesk, it (the
> helpdesk) is a third party service and thus your conclusions make sence.
> Think of the situation when superior of a heldesk person will tell him/her
> to check access point in some room. Would it be the same reaction? I
> assume not. By that I mean that if, for example, I'll install home agent
> in my home network, I can make it know anything I want about MN, and more
> intresting is that how I will do it, does not require any standardization.
> In other words, I'm superior of my HA.
> This situation is not unthinkable, I personally believe that this is much
> more efficient way of using HA fnctionality as opposed to big service
> providers who will have to fight with scalability and performance.
> However, one does not exclude another.
> Difference between policies and rules is a convertion step.
> 
> 

The difference between policy and rules is not only a matter of conversion. A policy, is a static, or quasi-static, set of guidance for the MN (e.g use access network X for application type A,...) while a rule update requires to be more dynamic. I mean: eventually a policy could be updated depending on network condition (e.g if X overloaded, use access network Y for application type A,...) but a rule reacts on local triggers (e.g. modification of the radio link quality) with a shorter period of variation. So, IMHO, there is no requirement for updating policy on a short period and out-of-band mechanism can be used (e.g. IEEE 802.21 in push mode,...).

My 2 cents...

> 
> Is there any reason to restrict where such convertion takes place? True
> that a HA does not know what is going on in the access network, on the
> other hand HA may know what is the network condition between HA and
> correspondent node. Either of this information is important, if not
> equally important.
> It is not really difficult to let an MN to reject rules sent by HA, which
> in my view would be quite natural. This implies that HA must follow the
> rules installed by MN until explicit acceptance has been received from MN.
> Such procedure is very similar to an MN beahviour when initiating new BU,
> where MN is not supposed to send any traffic before BU confirmation.
> BTW, what is the numerical representation of "rough consensus"? I assume
> is when majority is for, is it so?
> Yuri 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hesham Soliman
> Sent: Thursday, May 28, 2009 12:07 PM
> To: mext
> Subject: [MEXT] Important considerations for directionality of flow
> bindings
> 
> Hi all,
> 
> I've always been a fan of the IETF's tradition of rough concensus (as
> opposed to voting). To me, this implies that you need to get your point
> across and get other people to see that point of view. As opposed to
> other organisations that require their members to vote and end up with
> rigid political positions.
> 
> The chairs asked us about the directionality question of the flows
> bindings.
> On the charter question, I said that the charter doesn't need to mention
> how a solution should work, but rather what problem needs to be solved.
> Hence, as far as the charter is concerned, I'm fine with transferring
> rules "between" the MN and HA without mentioning directions.
> 
> Nevertheless, we still need to agree on identifying the requirement for
> the solution. And when it comes to this, I'm strongly against voting and
> I'll practice this by explaining in this email why I think rules can not
> be transferred from the HA to the MN and that the only direction that
> makes sense in MIP is MN->HA. I'll deliberately ignore arguments like
> "some people want this" or "an SDO wants this". They fall under the
> "meaningless words"
> category and I'm incapable of discussing them because they come with
> voting attitudes. They all need to be justified if the WG wants to have
> a technical _discussion_.
> 
> Here are my reasons:
> 
> 1. The HA does not know whether a CoA is tied to a certain access
> technology. It is one thing for the HA to send a message saying "forward
> port 80 traffic on a wifi link" (a policy) and a completely different
> thing to say "forward port 80 traffic using CoA 3ffe::1" (a rule).
> 
> 2. You might argue that the HA can be told by the MN that 3ffe::1 is
> tied to a wifi access, so what's the problem now? The problem is that
> the HA has no idea about dynamic changes on that wifi link. It doesn't
> know if it's congested, it doesn't know what application is using port
> 80 (it doesn't have to be web traffic) or port 8000 for that matter and
> doesn't even know if the AP of that wifi link works at all. Finally, it
> doesn't know the user's policies or other admin policies for that MN.
> This type of information needs to be sent regularly because it changes
> all the time and requires serious cross layer integration including
> sometimes layer 8 integration! It's completely impractical.
> 
> 3. If the HA installed rules in the MN, what happens if the MN wants to
> change those rules. Say the wifi link went down, or the MN's wifi
> interface went down and it wants to move that traffic to another
> interface. Would the HA reject such move? Does the MN have to justify to
> the HA why it needs to move traffic? Does that involve writing a letter
> perhaps?
> If you say "well in that case, the HA should let the MN move the
> traffic"
> then I'll ask you: what's the point of having the HA install this stuff
> if it has no authority and how does it know the reason for the MN's
> movement of the flow?
> The way to control how users do things is to incentivise them with
> charging models and show them that things work better on certain
> technologies, not by installing rules that can't be followed. It's a
> broken mindset and we've known that it's broken for a long time.
> 
> 4. Some people mentioned that the HA should be able to revoke flows on
> the MN. I'm perfectly fine with that, just extend the binding revocation
> draft to handle flows and the rest is pretty straight forward.
> 
> Finally, I'll indulge in a true story that happened to me a few years
> ago when I found that my wifi link wasn't working in a hotel (no radio)
> and called the help desk. He insisted that the link was up an I insisted
> that it wasn't. When I asked him to tell me how he knows the link is up
> he said: I can ping the AP! Of course after another 5 minutes of trying
> to convince him that pinging the AP doesn't mean the radio is actually
> working he sent someone to the hotel who in turn realised that the radio
> was not working.
> For those people who want rules to be transferred from the HA to the MN,
> please think of your HA as this help desk person, i.e. it has no clue
> about what's happening at the other end.
> 
> I hope this helps with the realisation that decisions can't be made here
> based on voting and that there is little merit to transferring rules
> from the HA to the MN. Policies can be transferred without any problems,
> but not rules.
> 
> Hesham
> 
> 
> 
> 
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 2 Jun 2009 17:46:34 +0200

Hi Pierrick,

On Jun 2, 2009, at 4:11 PM, <[email-masked]> wrote:

> The difference between policy and rules is not only a matter of  
> conversion. A policy, is a static, or quasi-static, set of guidance  
> for the MN (e.g use access network X for application type A,...)  
> while a rule update requires to be more dynamic. I mean: eventually  
> a policy could be updated depending on network condition (e.g if X  
> overloaded, use access network Y for application type A,...) but a  
> rule reacts on local triggers (e.g. modification of the radio link  
> quality) with a shorter period of variation. So, IMHO, there is no  
> requirement for updating policy on a short period and out-of-band  
> mechanism can be used (e.g. IEEE 802.21 in push mode,...).

Fully agree!
This is why I do not support the exchange of rules from the HA to the  
MN. Policies may be exchanged from the HA to the MN, but MIP is  
definitely not the protocol to transport them.

Nicolas

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 2 Jun 2009 16:54:50 +0100

FWIW I also fully agree with this as well as with Hesham's main points.

Although I understand that some people find the prospect of an HA
micromanaging uplink flows interesting at an academic level, I do not
think anyone would seriously consider this in a practical deployment
for reasons that have already been exhaustively articulated.

Regards
George

On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavont <[email-masked]> wrote:
>> conversion. A policy, is a static, or quasi-static, set of guidance for the
>> MN (e.g use access network X for application type A,...) while a rule update
>> requires to be more dynamic. I mean: eventually a policy could be updated
>> depending on network condition (e.g if X overloaded, use access network Y
>> for application type A,...) but a rule reacts on local triggers (e.g.
>> modification of the radio link quality) with a shorter period of variation.
>> So, IMHO, there is no requirement for updating policy on a short period and
>> out-of-band mechanism can be used (e.g. IEEE 802.21 in push mode,...).
>
> Fully agree!
> This is why I do not support the exchange of rules from the HA to the MN.
> Policies may be exchanged from the HA to the MN, but MIP is definitely not
> the protocol to transport them.
>
> Nicolas
>
>>
>>
>> My 2 cents...
>>
>>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Jun 2009 09:19:01 -0700 (PDT)

First it was:
No HA can not do, only MN can do it.

Now it suddenly became:
Yes it is possible but academic :).

Regards,

Behcet

----- Original Message ----
From: George Tsirtsis <[email-masked]>
To: Nicolas Montavont <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, June 2, 2009 10:54:50 AM
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Regards
George

On Tue, Jun 2, 2009 at 4:46 PM, Nicolas Montavont <[email-masked]> wrote:
>> out-of-band mechanism can be used (e.g. IEEE 802..21 in push mode,...).
>
> Fully agree!
>>> opposed to voting).. To me, this implies that you need to get your point
>>> the HA has no idea about dynamic changes on that wifi link.. It doesn't

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 2 Jun 2009 17:22:35 +0100

A lot of things are theoretically possible.
We are not here, however, to standardise all theoretical possibilities.

---

From: Frank Xia <[email-masked]>
Date: Tue, 02 Jun 2009 11:38:08 -0500

Hi Nicolas and Pierrick

As for policy and rules which you think policy
is static while rules are dynamic,  I don't think
I have the same understanding as you.

In 3GPP/TISPAN,  PCRF ( Policy and Charging
Rules function entity) could enforce
PCC (Policy and Charging Control)dynamically.

There is not such a difference which you highlighted.

BR
Frank

----- Original Message ----- 
From: "Nicolas Montavont" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 02, 2009 10:46 AM
Subject: Re: [MEXT] Important considerations for directionality of 
flowbindings

Hi Pierrick,

On Jun 2, 2009, at 4:11 PM, <[email-masked]> wrote:

> conversion. A policy, is a static, or quasi-static, set of guidance  for 
> the MN (e.g use access network X for application type A,...)  while a rule 
> update requires to be more dynamic. I mean: eventually  a policy could be 
> updated depending on network condition (e.g if X  overloaded, use access 
> network Y for application type A,...) but a  rule reacts on local triggers 
> (e.g. modification of the radio link  quality) with a shorter period of 
> variation. So, IMHO, there is no  requirement for updating policy on a 
> short period and out-of-band  mechanism can be used (e.g. IEEE 802.21 in 
> push mode,...).

Fully agree!

Nicolas

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Jun 2009 09:42:32 -0700 (PDT)

Yes IETF has already standardized "theoretical possibilities" with RFC 3543 in 2003, why not another one that was inherited from one of the founding fathers of mext called monami6?

----- Original Message ----
From: George Tsirtsis <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Nicolas Montavont <[email-masked]>; [email-masked]
Sent: Tuesday, June 2, 2009 11:22:35 AM
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

On Tue, Jun 2, 2009 at 5:19 PM, Behcet Sarikaya
<[email-masked]> wrote:
>>>> https://www.ietf..org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 12:57:53 +1000

Behcet, 

You don't understand the discussion. We're not talking about binding
revocation, everyone agrees that the HA can revoke a flow binding. So stop
referring to RFCs that are not being disputed...

On 3/06/09 2:42 AM, "Behcet Sarikaya" <[email-masked]> wrote:

> 
> Yes IETF has already standardized "theoretical possibilities" with RFC 3543 in
> 2003, why not another one that was inherited from one of the founding fathers
> of mext called monami6?
> 
> 
>  
> 
>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 08:32:00 +0200

Hi all,

Can someone explain why (quasi, semi, ...) static nature of rules matters? The generation of new rules set is triggered upon various events: intreface evants, link load report, user generated events and so on. Whenever an event is being processed the logic has to re-evaluate policies in order to come up with the new rules set. The new rules set may be exactly the same as the previous one.
I think what is important is the origin for rules generation and these are EVENTS, NOT POLICIES. Obviously events are dynamic, however upon 1000 new events arrival neither policies nor rules may change. Rules are not dynamic because they are RULES, but because something is happening.

I do entirely agree that many of the things, such as policies transfer, interface information, and anything else you can come up with is not related to MIP protocol. That is exactly my point! Not even rules generation from policies based on event arrival is an integral part of MIP. This can be implemented on a vanilla host without mobility support but multiaccess will be at the place. It is just rules TRANSFER which is the matter of MIP. So where is the logic when saying that MN to HA rules transfer is a practical engineering and HA to MN is an academic interest?

Regards
Yuri

-----Original Message-----
From: Nicolas Montavont [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2009 5:47 PM
To: [email-masked]
Cc: Yuri Ismailov; [email-masked]; [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Hi Pierrick,

On Jun 2, 2009, at 4:11 PM, <[email-masked]> wrote:

>> De : [email-masked] [mailto:[email-masked]] De la part 
>> de Yuri Ismailov Envoyé : vendredi 29 mai 2009 09:35 À : Hesham 
>> Soliman; mext Objet : Re: [MEXT] Important considerations for 
>> directionality of flowbindings
>>
>> Hesham,
>> This is nice story and makes some sense for the discssion, however 
>> some details are ommited. In your adventure with the helpdesk, it 
>> (the
>> Think of the situation when superior of a heldesk person will tell 
>> him/her to check access point in some room. Would it be the same 
>> reaction? I assume not. By that I mean that if, for example, I'll 
>> install home agent in my home network, I can make it know anything I 
>> want about MN, and more intresting is that how I will do it, does not 
>> require any standardization.
>> This situation is not unthinkable, I personally believe that this is 
>> much more efficient way of using HA fnctionality as opposed to big 
>> service providers who will have to fight with scalability and 
>> performance.
> for the MN (e.g use access network X for application type A,...) while 
> a rule update requires to be more dynamic. I mean: eventually a policy 
> could be updated depending on network condition (e.g if X overloaded, 
> use access network Y for application type A,...) but a rule reacts on 
> local triggers (e.g. modification of the radio link

Fully agree!
This is why I do not support the exchange of rules from the HA to the MN. Policies may be exchanged from the HA to the MN, but MIP is definitely not the protocol to transport them.

Nicolas

>> that a HA does not know what is going on in the access network, on 
>> the other hand HA may know what is the network condition between HA 
>> and correspondent node. Either of this information is important, if 
>> not equally important.
>> It is not really difficult to let an MN to reject rules sent by HA, 
>> which in my view would be quite natural. This implies that HA must 
>> follow the rules installed by MN until explicit acceptance has been 
>> received from MN.
>> Such procedure is very similar to an MN beahviour when initiating new 
>> BU, where MN is not supposed to send any traffic before BU 
>> confirmation.
>> BTW, what is the numerical representation of "rough consensus"? I 
>> assume is when majority is for, is it so?
>> Yuri
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Hesham Soliman
>> opposed to voting). To me, this implies that you need to get your 
>> point across and get other people to see that point of view. As 
>> opposed to other organisations that require their members to vote and 
>> end up with rigid political positions.
>>
>> On the charter question, I said that the charter doesn't need to 
>> mention how a solution should work, but rather what problem needs to 
>> be solved.
>> Nevertheless, we still need to agree on identifying the requirement 
>> for the solution. And when it comes to this, I'm strongly against 
>> voting and I'll practice this by explaining in this email why I think 
>> rules can not be transferred from the HA to the MN and that the only 
>> direction that makes sense in MIP is MN->HA. I'll deliberately ignore 
>> arguments like "some people want this" or "an SDO wants this". They 
>> fall under the "meaningless words"
>> voting attitudes. They all need to be justified if the WG wants to 
>> have a technical _discussion_.
>>
>> Here are my reasons:
>>
>> technology. It is one thing for the HA to send a message saying 
>> "forward port 80 traffic on a wifi link" (a policy) and a completely 
>> different thing to say "forward port 80 traffic using CoA 3ffe::1" (a 
>> rule).
>>
>> the HA has no idea about dynamic changes on that wifi link. It 
>> doesn't know if it's congested, it doesn't know what application is 
>> using port 80 (it doesn't have to be web traffic) or port 8000 for 
>> that matter and doesn't even know if the AP of that wifi link works 
>> at all.
>> Finally, it
>> This type of information needs to be sent regularly because it 
>> changes all the time and requires serious cross layer integration 
>> including sometimes layer 8 integration! It's completely impractical.
>>
>> 3. If the HA installed rules in the MN, what happens if the MN wants 
>> to change those rules. Say the wifi link went down, or the MN's wifi 
>> interface. Would the HA reject such move? Does the MN have to justify 
>> to the HA why it needs to move traffic? Does that involve writing a 
>> letter perhaps?
>> then I'll ask you: what's the point of having the HA install this 
>> stuff if it has no authority and how does it know the reason for the 
>> MN's movement of the flow?
>> 4. Some people mentioned that the HA should be able to revoke flows 
>> on the MN. I'm perfectly fine with that, just extend the binding 
>> revocation draft to handle flows and the rest is pretty straight 
>> forward.
>>
>> and called the help desk. He insisted that the link was up an I 
>> insisted that it wasn't. When I asked him to tell me how he knows the 
>> link is up he said: I can ping the AP! Of course after another 5 
>> minutes of trying to convince him that pinging the AP doesn't mean 
>> the radio is actually working he sent someone to the hotel who in 
>> turn realised that the radio was not working.
>> For those people who want rules to be transferred from the HA to the 
>> MN, please think of your HA as this help desk person, i.e. it has no 
>> clue about what's happening at the other end.
>>
>> I hope this helps with the realisation that decisions can't be made 
>> here based on voting and that there is little merit to transferring 
>> rules from the HA to the MN. Policies can be transferred without any 
>> problems, but not rules.
>>
>> Hesham
>>
>>
>>
>>
>>

---

From: <[email-masked]>
Date: Wed, 3 Jun 2009 08:35:50 +0200

Hi Frank,

We are not saying that policies must not be updated. Actually, we are considering policies are quasi-static; I think it is the case for PCRF: there is no need to update these policies every milliseconds. Basically, we are saying there is no requirement for piggybacking MIP signalling to transport policies because existing mechanisms can be reused, typically 3GPP mechanism could be candidate.

Hope that clarifies,

BR,
Pierrick 

> -----Message d'origine-----
> De : Frank Xia [mailto:[email-masked]]
> Envoyé : mardi 2 juin 2009 18:38
> À : Nicolas Montavont; SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]
> de
> some
> >> him/her
> >> much
> >> which
> >> BU,
> Of
> point
> mention
> for
> "forward
> to
> to
> stuff
> insisted
> MN,
> here

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 16:41:17 +1000

Yuri,

 It is just rules TRANSFER which is the matter of MIP. So where
> is the logic when saying that MN to HA rules transfer is a practical
> engineering and HA to MN is an academic interest?

=> I think we've (I'm including myself) highlighted several reasons for why
it makes little sense to transfer rules from HA to MN. Instead of rat-holing
on theory Vs practice, you (or others advocating the other direction) need
to come up with reasons for doing things this way. This way we can think
like engineers about tradeoffs.
Absent that, I don't see any point in having theory Vs practice high level
discussions, which will lead nowhere.

Hesham

> Policies may be exchanged from the HA to the MN, but MIP is definitely not the
> protocol to transport them.
> 
> Nicolas
> 
>> 
>> 
>> My 2 cents...
>> 
>>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 09:00:33 +0200

Hesham,
"Academic interest" is not my argument and I agree that this kind of discussion will take us nowhere. You withdrew this statement from the context.
Some examples:

- network condition towards CN(s)
- the sum of number of hops between MN -> HA and HA -> CN
- Access provider (any access, not necessarily wireless) who offeres HA services preferences change
- Change of the access provider traffic to another backbone provider due to the time of the day.
- Traffic condition on HA interface, which accepts traffic from MN if MN sends on some particular local interface

Pretty much sure that there are more examples and I encourage to think about those not from MN point of view but rather from the HA service provider.

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 8:41 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

> engineering and HA to MN is an academic interest?

=> I think we've (I'm including myself) highlighted several reasons for why it makes little sense to transfer rules from HA to MN. Instead of rat-holing on theory Vs practice, you (or others advocating the other direction) need to come up with reasons for doing things this way. This way we can think like engineers about tradeoffs.
Absent that, I don't see any point in having theory Vs practice high level discussions, which will lead nowhere.

Hesham

>>> want about MN, and more intresting is that how I will do it, does 
>>> not require any standardization.
>> while a rule update requires to be more dynamic. I mean: eventually a 
>> policy could be updated depending on network condition (e.g if X 
> Policies may be exchanged from the HA to the MN, but MIP is definitely 
> not the protocol to transport them.
> 
> Nicolas
> 
>> 
>> 
>> My 2 cents...
>> 
>>> 
>>> Such procedure is very similar to an MN beahviour when initiating 
>>> new BU, where MN is not supposed to send any traffic before BU 
>>> confirmation.
>>> I've always been a fan of the IETF's tradition of rough concensus 
>>> (as opposed to voting). To me, this implies that you need to get 
>>> your point across and get other people to see that point of view. As 
>>> opposed to other organisations that require their members to vote 
>>> and end up with rigid political positions.
>>> 
>>> Hence, as far as the charter is concerned, I'm fine with 
>>> transferring rules "between" the MN and HA without mentioning directions.
>>> 
>>> voting and I'll practice this by explaining in this email why I 
>>> think rules can not be transferred from the HA to the MN and that 
>>> the only direction that makes sense in MIP is MN->HA. I'll 
>>> deliberately ignore arguments like "some people want this" or "an 
>>> SDO wants this". They fall under the "meaningless words"
>>> different thing to say "forward port 80 traffic using CoA 3ffe::1" 
>>> (a rule).
>>> 
>>> tied to a wifi access, so what's the problem now? The problem is 
>>> that the HA has no idea about dynamic changes on that wifi link. It 
>>> interface. Would the HA reject such move? Does the MN have to 
>>> justify to the HA why it needs to move traffic? Does that involve 
>>> writing a letter perhaps?
>>> Finally, I'll indulge in a true story that happened to me a few 
>>> years ago when I found that my wifi link wasn't working in a hotel 
>>> (no
>>> radio)
>>> insisted that it wasn't. When I asked him to tell me how he knows 
>>> the link is up he said: I can ping the AP! Of course after another 5

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 17:12:33 +1000

Yuri, 

Thanks for progressing the discussion. Comments inline

> on some particular local interface

=> I'm trying to understand what you mean above. These are all scenarios,
the question is: What is the benefit for the HA to transfer rules? The HA
will not know the path between the MN and CN more than either node does. So
I don't understand what _benefits_ you see here.

Hesham

> 
> Pretty much sure that there are more examples and I encourage to think about
> those not from MN point of view but rather from the HA service provider.
> 
> /yuri
> 
> 
> 
> 
> => I think we've (I'm including myself) highlighted several reasons for why it
> makes little sense to transfer rules from HA to MN. Instead of rat-holing on
> theory Vs practice, you (or others advocating the other direction) need to
> come up with reasons for doing things this way. This way we can think like
> engineers about tradeoffs.

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 3 Jun 2009 08:17:49 +0100

Yuri,

Since you are working for a vendor to cellular operators it should be
trivial for you to check what the bottlenecks in cellular and other
wireless networks are.

In cellular, by far the biggest bottleneck is the wireless link i.e.,
the airlink between the mobile and the base station (BS) / access
point (AP).
The next bottleneck is the backhaul link connecting the BS/AP to the
aggregation router/switch depending on RAN architecture.

These two links are simply too expensive to overdimention; the former
due to spectrum cost/constraints, and the latter due to the high
cost/volume of last-mile wires required to go to all the BS/AP.

In all networks, technologies, and deployments I have been involved
with, the rest of the network is considered pretty much to be
overdimentioned. This is why all the conditions to which you claim the
HA may have better view of (even if one considers the HA to somehow
know the condition of the whole network, which of course is nonsense),
are in any case not relevant in practice. And they are certainly not
relevant to the uplink traffic sent by the mobile over the first 2
links, which are also the only relevant bottlenecks in the system.

George

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 09:23:39 +0200

Hesham,

In my view these are events not scenarious. These events are known by HA but not MN. If HA acts upon events, given that it knows somewhat more about MN, not only IP addresses, it (HA) can generate new rules and send them as hint to MN. Back again, MN has four options:
- reject,
- re-evaluate and reject
- re-evaluate and accept
- accept

The benefit will be obviously that the new rules (if accepted) may llead to a better overall communication characteristics.

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 9:13 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri, 

> - Traffic condition on HA interface, which accepts traffic from MN if 
> MN sends on some particular local interface

=> I'm trying to understand what you mean above. These are all scenarios, the question is: What is the benefit for the HA to transfer rules? The HA will not know the path between the MN and CN more than either node does. So I don't understand what _benefits_ you see here.

Hesham

> 
> Pretty much sure that there are more examples and I encourage to think 
> about those not from MN point of view but rather from the HA service provider.
> 
> /yuri
> 
> 
> 
> 
> => I think we've (I'm including myself) highlighted several reasons 
> for why it makes little sense to transfer rules from HA to MN. Instead 
> of rat-holing on theory Vs practice, you (or others advocating the 
> other direction) need to come up with reasons for doing things this 
> way. This way we can think like engineers about tradeoffs.
> Absent that, I don't see any point in having theory Vs practice high 
> level discussions, which will lead nowhere.
> 
> Hesham
> 
> 
>> 
>> Regards
>> Yuri
>> 
>>>> De : [email-masked] [mailto:[email-masked]] De la 
>>>> part de Yuri Ismailov Envoyé : vendredi 29 mai 2009 09:35 À : 
>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important considerations 
>>>> for directionality of flowbindings
>>>> 
>>>> Hesham,
>>>> install home agent in my home network, I can make it know anything 
>>>> I want about MN, and more intresting is that how I will do it, does 
>>>> This situation is not unthinkable, I personally believe that this 
>>>> is much more efficient way of using HA fnctionality as opposed to 
>>>> big service providers who will have to fight with scalability and 
>>>> performance.
>> Policies may be exchanged from the HA to the MN, but MIP is 
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Hesham Soliman
>>>> your point across and get other people to see that point of view. 
>>>> As opposed to other organisations that require their members to 
>>>> vote and end up with rigid political positions.
>>>> 
>>>> mention how a solution should work, but rather what problem needs 
>>>> to be solved.
>>>> category and I'm incapable of discussing them because they come 
>>>> with voting attitudes. They all need to be justified if the WG 
>>>> wants to have a technical _discussion_.
>>>> 
>>>> Here are my reasons:
>>>> 
>>>> "forward port 80 traffic on a wifi link" (a policy) and a 
>>>> completely different thing to say "forward port 80 traffic using CoA 3ffe::1"
>>>> (a rule).
>>>> 
>>>> 2. You might argue that the HA can be told by the MN that 3ffe::1 
>>>> is tied to a wifi access, so what's the problem now? The problem is 
>>>> 3. If the HA installed rules in the MN, what happens if the MN 
>>>> wants to change those rules. Say the wifi link went down, or the 
>>>> MN's wifi interface went down and it wants to move that traffic to 
>>>> another interface. Would the HA reject such move? Does the MN have 
>>>> to justify to the HA why it needs to move traffic? Does that 
>>>> involve writing a letter perhaps?
>>>> stuff if it has no authority and how does it know the reason for 
>>>> the MN's movement of the flow?
>>>> technologies, not by installing rules that can't be followed. It's 
>>>> a broken mindset and we've known that it's broken for a long time.
>>>> 
>>>> the link is up he said: I can ping the AP! Of course after another 
>>>> 5 minutes of trying to convince him that pinging the AP doesn't 
>>>> mean the radio is actually working he sent someone to the hotel who 
>>>> in turn realised that the radio was not working.
>>>> For those people who want rules to be transferred from the HA to 
>>>> the MN, please think of your HA as this help desk person, i.e. it 
>>>> has no clue about what's happening at the other end.
>>>> 
>>>> rules from the HA to the MN. Policies can be transferred without 
>>>> any problems, but not rules.
>>>> 
>>>> Hesham
>>>> 
>>>> 
>>>> 
>>>> 
>>>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 09:34:26 +0200

George,
I do not think that my employment matters for this discussion.
I suggest we focus then on corporate scenarious or residential networks, which would have similar access provider functions which I described eralier
/yuri 

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 9:18 AM
To: Yuri Ismailov
Cc: Hesham Soliman; Nicolas Montavont; [email-masked]; [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

Since you are working for a vendor to cellular operators it should be trivial for you to check what the bottlenecks in cellular and other wireless networks are.

In cellular, by far the biggest bottleneck is the wireless link i.e., the airlink between the mobile and the base station (BS) / access point (AP).
The next bottleneck is the backhaul link connecting the BS/AP to the aggregation router/switch depending on RAN architecture.

These two links are simply too expensive to overdimention; the former due to spectrum cost/constraints, and the latter due to the high cost/volume of last-mile wires required to go to all the BS/AP.

In all networks, technologies, and deployments I have been involved with, the rest of the network is considered pretty much to be overdimentioned. This is why all the conditions to which you claim the HA may have better view of (even if one considers the HA to somehow know the condition of the whole network, which of course is nonsense), are in any case not relevant in practice. And they are certainly not relevant to the uplink traffic sent by the mobile over the first 2 links, which are also the only relevant bottlenecks in the system.

George

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 18:10:13 +1000

Yuri,

I can't parse those events you refer to. I'l answer both emails here. First

>> - the sum of number of hops between MN -> HA and HA -> CN

=> What's the event? A change in those conditions? The MN knows the
conditions of the e2e path as well as or better than the HA. What is the
benefit of having the HA send a hint and how reliable is that hint anyway?

>> HA services preferences change

=> Preferences change to what?? How does it know if such change works for
the MN at all? This is way too vague to be able to discuss tradeoffs.

>> MN sends on some particular local interface

=> These are path changes. The HA has _no idea_ how such a change affects
each MN/CN combination and it's "hint" can cause more problems than it
solves. BTW, if you're talking about hints then we're no longer talking
about installing bindings in the MN. This is a different topic. MIP doesn't
transfer hints, it pretty much sends "orders" from one end to another.

> - accept

=> First, by assuming that the MN can reject the "hint" as you call it you
invalidate the whole argument for the HA to install rules. Rejecting a hint
or even evaluating it means that the MN knows more. Therefore, the HA's hint
is a complete waste of bandwidth.

I'm still confused about the _benefits_ you see here. Or are you assuming
that the MN can't know those hints without the HA's involvement? But if
you're assuming that, then how can it reject the hints? This whole proposal
makes no sense to me at all. Not to mention the complexity you implicitly
assume in order to generate those, hopefully reliable, hints.

Hesham

On 3/06/09 5:23 PM, "Yuri Ismailov" <[email-masked]> wrote:

> Hesham,
> 
> In my view these are events not scenarious. These events are known by HA but
> not MN. If HA acts upon events, given that it knows somewhat more about MN,
> not only IP addresses, it (HA) can generate new rules and send them as hint to
> MN. Back again, MN has four options:
> 
> The benefit will be obviously that the new rules (if accepted) may llead to a
> better overall communication characteristics.
> 
> /yuri
> 
> 
> => I'm trying to understand what you mean above. These are all scenarios, the
> question is: What is the benefit for the HA to transfer rules? The HA will not
> know the path between the MN and CN more than either node does. So I don't
> understand what _benefits_ you see here.
> 
> Hesham
> 
>>

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 3 Jun 2009 10:17:23 +0100

I only referred to your employment regarding access you might have to
credible and relevant information. I hope you did not take it the
wrong way.

Corporate and residential scenarios are even less relevant. An HA at
home or at the office can know even less relevant information than an
HA in say a cellular system, when the mobile is roaming somewhere on
the Internet.

But we keep dancing around the same arguments...no much progress.

George

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 11:33:29 +0200

Hesham,

Whenever we talk about sending additional information, the "waste of bandwidth" can be brought up. So I do not have an answer for that besides speculations around it. Otherwise, we can go far beyond normal logic:-) Flow mobility support requires additional signaling - waste of bandwidth and what are benefits? Mobility support requires additional signaling ..... Any new feature will require additional signaling.....

Speaking about benefits, everybody who knows the area is capable of turning things up side down. I assume it is subjective standpoint of considering things as benefits or disadvantages and all is about to agree or disagree. For me those I wrote about are benefits or potential benefits if you want.
One important thing in the discussion, although mentioned, but forgotten later is that by making rules distribution one way only, we do create limitation for benefits, or potential benefits if this sounds better.

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 10:10 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

>> - the sum of number of hops between MN -> HA and HA -> CN

=> What's the event? A change in those conditions? The MN knows the conditions of the e2e path as well as or better than the HA. What is the benefit of having the HA send a hint and how reliable is that hint anyway?

>> HA services preferences change

=> Preferences change to what?? How does it know if such change works for the MN at all? This is way too vague to be able to discuss tradeoffs.

>> MN sends on some particular local interface

=> These are path changes. The HA has _no idea_ how such a change affects each MN/CN combination and it's "hint" can cause more problems than it solves. BTW, if you're talking about hints then we're no longer talking about installing bindings in the MN. This is a different topic. MIP doesn't transfer hints, it pretty much sends "orders" from one end to another.

> - accept

=> First, by assuming that the MN can reject the "hint" as you call it you invalidate the whole argument for the HA to install rules. Rejecting a hint or even evaluating it means that the MN knows more. Therefore, the HA's hint is a complete waste of bandwidth.

I'm still confused about the _benefits_ you see here. Or are you assuming that the MN can't know those hints without the HA's involvement? But if you're assuming that, then how can it reject the hints? This whole proposal makes no sense to me at all. Not to mention the complexity you implicitly assume in order to generate those, hopefully reliable, hints.

Hesham

On 3/06/09 5:23 PM, "Yuri Ismailov" <[email-masked]> wrote:

> Hesham,
> 
> In my view these are events not scenarious. These events are known by 
> HA but not MN. If HA acts upon events, given that it knows somewhat 
> more about MN, not only IP addresses, it (HA) can generate new rules 
> and send them as hint to MN. Back again, MN has four options:
> 
> The benefit will be obviously that the new rules (if accepted) may 
> llead to a better overall communication characteristics.
> 
> /yuri
> 
> 
> => I'm trying to understand what you mean above. These are all 
> scenarios, the question is: What is the benefit for the HA to transfer 
> rules? The HA will not know the path between the MN and CN more than 
> either node does. So I don't understand what _benefits_ you see here.
> 
> Hesham
> 
>> 
>> Pretty much sure that there are more examples and I encourage to 
>> think about those not from MN point of view but rather from the HA 
>> service provider.
>> 
>> /yuri
>> 
>> 
>> 
>> 
>> for why it makes little sense to transfer rules from HA to MN. 
>> Instead of rat-holing on theory Vs practice, you (or others 
>> advocating the other direction) need to come up with reasons for 
>> doing things this way. This way we can think like engineers about tradeoffs.
>>>>> I want about MN, and more intresting is that how I will do it, 
>>>>> does not require any standardization.
>>>>> the other hand HA may know what is the network condition between 
>>>>> HA and correspondent node. Either of this information is 
>>>>> important, if not equally important.
>>>>> It is not really difficult to let an MN to reject rules sent by 
>>>>> HA, which in my view would be quite natural. This implies that HA 
>>>>> must follow the rules installed by MN until explicit acceptance 
>>>>> has been received from MN.
>>>>> Subject: [MEXT] Important considerations for directionality of 
>>>>> flow bindings
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Nevertheless, we still need to agree on identifying the 
>>>>> requirement for the solution. And when it comes to this, I'm 
>>>>> strongly against voting and I'll practice this by explaining in 
>>>>> this email why I think rules can not be transferred from the HA to 
>>>>> the MN and that the only direction that makes sense in MIP is 
>>>>> MN->HA. I'll deliberately ignore arguments like "some people want 
>>>>> this" or "an SDO wants this". They fall under the "meaningless words"
>>>>> is tied to a wifi access, so what's the problem now? The problem 
>>>>> is that the HA has no idea about dynamic changes on that wifi 
>>>>> link. It doesn't know if it's congested, it doesn't know what 
>>>>> application is using port 80 (it doesn't have to be web traffic) 
>>>>> or port 8000 for that matter and doesn't even know if the AP of 
>>>>> that wifi link works at all.
>>>>> Finally, it
>>>>> 4. Some people mentioned that the HA should be able to revoke 
>>>>> flows on the MN. I'm perfectly fine with that, just extend the 
>>>>> binding revocation draft to handle flows and the rest is pretty 
>>>>> straight forward.
>>>>> 
>>>>> mean the radio is actually working he sent someone to the hotel 
>>>>> who in turn realised that the radio was not working.
>>>>> I hope this helps with the realisation that decisions can't be 
>>>>> made here based on voting and that there is little merit to 
>>>>> transferring rules from the HA to the MN. Policies can be 
>>>>> transferred without any problems, but not rules.
>>>>> 
>>>>> Hesham
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 11:35:53 +0200

True,
I would say progress is NULL.

/yuri 

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 11:17 AM
To: Yuri Ismailov
Cc: Hesham Soliman; Nicolas Montavont; [email-masked]; [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

I only referred to your employment regarding access you might have to credible and relevant information. I hope you did not take it the wrong way.

Corporate and residential scenarios are even less relevant. An HA at home or at the office can know even less relevant information than an HA in say a cellular system, when the mobile is roaming somewhere on the Internet.

George

On Wed, Jun 3, 2009 at 8:34 AM, Yuri Ismailov <[email-masked]> wrote:
> I suggest we focus then on corporate scenarious or residential 
> networks, which would have similar access provider functions which I 
> described eralier /yuri
>
> Cc: Hesham Soliman; Nicolas Montavont; 
> [email-masked]; [email-masked]

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 19:47:03 +1000

On 3/06/09 7:33 PM, "Yuri Ismailov" <[email-masked]> wrote:

> Hesham,
> 
> Whenever we talk about sending additional information, the "waste of
> bandwidth" can be brought up. So I do not have an answer for that besides
> speculations around it.

=> no no, I don't mean it literally, I mean that the message doesn't do
anything, i.e. Has no benefit.

> 
> Speaking about benefits, everybody who knows the area is capable of turning
> things up side down. I assume it is subjective standpoint of considering
> things as benefits or disadvantages and all is about to agree or disagree.

=> That's fine, I'm asking for benefits in your opinion not someone else's.
It's impossible to discuss this if I can't see any benefits because you
didn't send any. What you sent were actions that can be done by the HA and I
responded by saying that the same (or more) information is available to the
MN. Therefore, if you think there are additional benefits to doing this in
the HA then you need to tell us.

The bottom line is this: MIP works by letting the MN install bindings in the
HA. If you want things to work in reverse you need to justify it. I can't
see any justifications because you're not answering my questions on your
scenarios. So, count me out on the reverse direction :).

For 
> me those I wrote about are benefits or potential benefits if you want.

=> No you didn't. You wrote about things that can be done. Many things can
be done by many entities, the question is why the HA and not the MN.

> One important thing in the discussion, although mentioned, but forgotten later
> is that by making rules distribution one way only, we do create limitation for
> benefits, or potential benefits if this sounds better.

=> Well, we won't know what we're missing unless someone tells us. So far no
one has mentioned the advantages of doing things in the reverse direction.
There is always something missing from a protocol (it's engineering), the
question us whether it's significant or worth the trouble.

Hesham

> => What's the event? A change in those conditions? The MN knows the conditions
> of the e2e path as well as or better than the HA. What is the benefit of
> having the HA send a hint and how reliable is that hint anyway?
> 
> => Preferences change to what?? How does it know if such change works for the
> MN at all? This is way too vague to be able to discuss tradeoffs.
> 
> => These are path changes. The HA has _no idea_ how such a change affects each
> MN/CN combination and it's "hint" can cause more problems than it solves. BTW,
> if you're talking about hints then we're no longer talking about installing
> bindings in the MN. This is a different topic. MIP doesn't transfer hints, it
> pretty much sends "orders" from one end to another.
> 
> invalidate the whole argument for the HA to install rules. Rejecting a hint or
> even evaluating it means that the MN knows more. Therefore, the HA's hint is a
> complete waste of bandwidth.
> 
> I'm still confused about the _benefits_ you see here. Or are you assuming that
> the MN can't know those hints without the HA's involvement? But if you're
> assuming that, then how can it reject the hints? This whole proposal makes no
> sense to me at all. Not to mention the complexity you implicitly assume in
> order to generate those, hopefully reliable, hints.
> 
> Hesham
> 
>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 12:52:00 +0200

Hesham,
You are out:-)

Still some answers, despite knowing that in your opinion they are not benefits.

First of all MIP will not be breaked if the rules will be sent in both directions.

- Access provider preferences relate to the use of backbone provider, which may vary with the time of day. Changing backbone provider can make quite big difference for commnication between HA (if HA service is provided by the same access provider) and CN(s). The difference can be expressed in, let's say, number of hops, load, possibly something else. Such change is an event and may have an impact on the overall communication. This can be told directly to MN or HA. Direct communication to MN (if accepted as benefit:-)) in such case will need standardization. Communication of this information to HA does not (I consider this as a benefit). HA may act upon that event, and the rest you know: rules in reverse direction.

- Access provider may set up different parameters for traffic shaping for each of HA interfaces. These preferences may vary independently of change of backbone provider but dependently on the time of day. The rest you know, whether it changes somebodies opinion.

- I presume that in RO mode this is similar to HA mode, and I'm in when it comes to send rules in reverse direction between CN and MN. Benefits of doing that is that any change percieved by CN as important to react upon can be expressed in proposal of new rules. The sources causing changes may include but not limited to, are user, network managemnt events, application generated events, etc.

So feel free to consider this as benefits or not

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 11:47 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

On 3/06/09 7:33 PM, "Yuri Ismailov" <[email-masked]> wrote:

> bandwidth" can be brought up. So I do not have an answer for that 
> besides speculations around it.

=> no no, I don't mean it literally, I mean that the message doesn't do anything, i.e. Has no benefit.

> 
> Speaking about benefits, everybody who knows the area is capable of 
> turning things up side down. I assume it is subjective standpoint of 
> considering things as benefits or disadvantages and all is about to agree or disagree.

=> That's fine, I'm asking for benefits in your opinion not someone else's.
It's impossible to discuss this if I can't see any benefits because you didn't send any. What you sent were actions that can be done by the HA and I responded by saying that the same (or more) information is available to the MN. Therefore, if you think there are additional benefits to doing this in the HA then you need to tell us.

The bottom line is this: MIP works by letting the MN install bindings in the HA. If you want things to work in reverse you need to justify it. I can't see any justifications because you're not answering my questions on your scenarios. So, count me out on the reverse direction :).

For 
> me those I wrote about are benefits or potential benefits if you want.

=> No you didn't. You wrote about things that can be done. Many things can be done by many entities, the question is why the HA and not the MN.

> One important thing in the discussion, although mentioned, but 
> forgotten later is that by making rules distribution one way only, we 
> do create limitation for benefits, or potential benefits if this sounds better.

=> Well, we won't know what we're missing unless someone tells us. So far no one has mentioned the advantages of doing things in the reverse direction.
There is always something missing from a protocol (it's engineering), the question us whether it's significant or worth the trouble.

Hesham

> conditions of the e2e path as well as or better than the HA. What is 
> the benefit of having the HA send a hint and how reliable is that hint anyway?
> 
> => Preferences change to what?? How does it know if such change works 
> for the MN at all? This is way too vague to be able to discuss tradeoffs.
> 
>>> - Traffic condition on HA interface, which accepts traffic from MN 
>>> if MN sends on some particular local interface
> 
> => These are path changes. The HA has _no idea_ how such a change 
> affects each MN/CN combination and it's "hint" can cause more problems 
> than it solves. BTW, if you're talking about hints then we're no 
> longer talking about installing bindings in the MN. This is a 
> different topic. MIP doesn't transfer hints, it pretty much sends "orders" from one end to another.
> 
> => First, by assuming that the MN can reject the "hint" as you call it 
> you invalidate the whole argument for the HA to install rules. 
> Rejecting a hint or even evaluating it means that the MN knows more. 
> Therefore, the HA's hint is a complete waste of bandwidth.
> 
> I'm still confused about the _benefits_ you see here. Or are you 
> assuming that the MN can't know those hints without the HA's 
> involvement? But if you're assuming that, then how can it reject the 
> hints? This whole proposal makes no sense to me at all. Not to mention 
> the complexity you implicitly assume in order to generate those, hopefully reliable, hints.
> 
> Hesham
> 
> 
>> scenarios, the question is: What is the benefit for the HA to 
>> transfer rules? The HA will not know the path between the MN and CN 
>> more than either node does. So I don't understand what _benefits_ you see here.
>> 
>> Hesham
>> 
>>> 
>>>> is the logic when saying that MN to HA rules transfer is a 
>>>> practical engineering and HA to MN is an academic interest?
>>> 
>>>>>> This is nice story and makes some sense for the discssion, 
>>>>>> however some details are ommited. In your adventure with the 
>>>>>> helpdesk, it (the
>>>>>> Think of the situation when superior of a heldesk person will 
>>>>>> tell him/her to check access point in some room. Would it be the 
>>>>>> same reaction? I assume not. By that I mean that if, for example, 
>>>>>> I'll install home agent in my home network, I can make it know 
>>>>>> anything I want about MN, and more intresting is that how I will 
>>>>>> do it, does not require any standardization.
>>>>> conversion. A policy, is a static, or quasi-static, set of 
>>>>> guidance for the MN (e.g use access network X for application type 
>>>>> A,...) while a rule update requires to be more dynamic. I mean: 
>>>>> eventually a policy could be updated depending on network 
>>>>> condition (e.g if X overloaded, use access network Y for 
>>>>> application type A,...) but a rule reacts on local triggers (e.g. 
>>>>> modification of the radio link
>>>>>> that a HA does not know what is going on in the access network, 
>>>>>> on the other hand HA may know what is the network condition 
>>>>>> between HA and correspondent node. Either of this information is 
>>>>>> The chairs asked us about the directionality question of the 
>>>>>> flows bindings.
>>>>>> this email why I think rules can not be transferred from the HA 
>>>>>> to the MN and that the only direction that makes sense in MIP is
>>>>>> MN's wifi interface went down and it wants to move that traffic 
>>>>>> to another interface. Would the HA reject such move? Does the MN 
>>>>>> have to justify to the HA why it needs to move traffic? Does that 
>>>>>> The way to control how users do things is to incentivise them 
>>>>>> with charging models and show them that things work better on 
>>>>>> certain technologies, not by installing rules that can't be 
>>>>>> followed. It's a broken mindset and we've known that it's broken for a long time.
>>>>>> 
>>>>>> years ago when I found that my wifi link wasn't working in a 
>>>>>> hotel (no
>>>>>> radio)

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 03 Jun 2009 21:15:01 +1000

> First of all MIP will not be breaked if the rules will be sent in both

=> Well, that's debatable, but this is clearly not a reason to do anything.

> 
> - Access provider preferences relate to the use of backbone provider, which
> may vary with the time of day. Changing backbone provider can make quite big
> difference for commnication between HA (if HA service is provided by the same
> access provider) and CN(s). The difference can be expressed in, let's say,
> number of hops, load, possibly something else. Such change is an event and may
> have an impact on the overall communication. This can be told directly to MN
> or HA. Direct communication to MN (if accepted as benefit:-)) in such case
> will need standardization. Communication of this information to HA does not (I
> consider this as a benefit). HA may act upon that event, and the rest you
> know: rules in reverse direction.

=> There is no need to _tell_ the MN anything. There are two issues here.
First, changing network conditions are best known e2e. So the MN will know
that anyway based on the traffic running between it and the CN. The other
issue is related to cost for certain times of day. This is a routing issue
in the HA and has nothing to do with which interface the MN selects. The
selected CoA has zero impact on the HA's upstream selection. Completely
irrelevant actually.
Of course, as far as cost on the visited link, the MN knows best.

> 
> - Access provider may set up different parameters for traffic shaping for each
> of HA interfaces. These preferences may vary independently of change of
> backbone provider but dependently on the time of day. The rest you know,
> whether it changes somebodies opinion.

=> But again, this has zero effect on CoA selection. The two issues are
completely orthogonal. Selecting CoA1 or CoA2 has zero impact on the HA's
upstream route.

> 
> - I presume that in RO mode this is similar to HA mode, and I'm in when it
> comes to send rules in reverse direction between CN and MN. Benefits of doing
> that is that any change percieved by CN as important to react upon can be
> expressed in proposal of new rules. The sources causing changes may include
> but not limited to, are user, network managemnt events, application generated
> events, etc.
> 

=> You seem to think that there is a relationship between upstream routing
and CoA selection. That's not the case at all. These are two different
addresses from two different networks.

Hesham

> It's impossible to discuss this if I can't see any benefits because you didn't
> send any. What you sent were actions that can be done by the HA and I
> MN. Therefore, if you think there are additional benefits to doing this in the
> HA then you need to tell us.
> 
> HA. If you want things to work in reverse you need to justify it. I can't see
> any justifications because you're not answering my questions on your
> => No you didn't. You wrote about things that can be done. Many things can be
> done by many entities, the question is why the HA and not the MN.
>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 14:47:13 +0200

Ok, see your point, however:-)

The major difference here is that your are talking about CoA selection and I'm talking about interface selection. Quite a big difference.
I do not see any grounds for MN to select CoA, based on what? Prefix length? While selection of an interface is based on expected characteristics of the communication. Routes (up/down)link in my opinion do have impact on the characteristics and this is exactly the information missing in the MN when selecting interface.

Whenever, MN decides to move a flow, the reason can be anything but not which CoA it has configured on each interface.

Another thing is that MN will notice something e2e if and only if such support is implemented in the MN. Moreover, this notice can not be made at IP layer. TCP fights alone with all problems and never tells to any other layer what is going on. So what is left? Two options. Add this support to operating system, which makes its (support) existence questionable, or to applications, which is even more questionable.

>>
>> Well, that's debatable, but this is clearly not a reason to do anything.
>>
Are you serious about that MIP may be broken because of that?

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 1:15 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

> 
> - Access provider preferences relate to the use of backbone provider, 
> which may vary with the time of day. Changing backbone provider can 
> make quite big difference for commnication between HA (if HA service 
> is provided by the same access provider) and CN(s). The difference can 
> be expressed in, let's say, number of hops, load, possibly something 
> else. Such change is an event and may have an impact on the overall 
> communication. This can be told directly to MN or HA. Direct 
> communication to MN (if accepted as benefit:-)) in such case will need 
> standardization. Communication of this information to HA does not (I 

=> There is no need to _tell_ the MN anything. There are two issues here.
First, changing network conditions are best known e2e. So the MN will know that anyway based on the traffic running between it and the CN. The other issue is related to cost for certain times of day. This is a routing issue in the HA and has nothing to do with which interface the MN selects. The selected CoA has zero impact on the HA's upstream selection. Completely irrelevant actually.
Of course, as far as cost on the visited link, the MN knows best.

> 
> - Access provider may set up different parameters for traffic shaping 
> for each of HA interfaces. These preferences may vary independently of 
> change of backbone provider but dependently on the time of day. The 
> rest you know, whether it changes somebodies opinion.

=> But again, this has zero effect on CoA selection. The two issues are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on the HA's upstream route.

> 
> - I presume that in RO mode this is similar to HA mode, and I'm in 
> when it comes to send rules in reverse direction between CN and MN. 
> Benefits of doing that is that any change percieved by CN as important 
> to react upon can be expressed in proposal of new rules. The sources 
> causing changes may include but not limited to, are user, network 
> managemnt events, application generated events, etc.
> 

=> You seem to think that there is a relationship between upstream routing and CoA selection. That's not the case at all. These are two different addresses from two different networks.

Hesham

> It's impossible to discuss this if I can't see any benefits because 
> you didn't send any. What you sent were actions that can be done by 
> the HA and I responded by saying that the same (or more) information 
> is available to the MN. Therefore, if you think there are additional 
> benefits to doing this in the HA then you need to tell us.
> 
> The bottom line is this: MIP works by letting the MN install bindings 
> in the HA. If you want things to work in reverse you need to justify 
> it. I can't see any justifications because you're not answering my 
> questions on your scenarios. So, count me out on the reverse direction :).
> 
> 
> For
> => No you didn't. You wrote about things that can be done. Many things 
> can be done by many entities, the question is why the HA and not the MN.
> 
> => Well, we won't know what we're missing unless someone tells us. So 
> far no one has mentioned the advantages of doing things in the reverse direction.
> There is always something missing from a protocol (it's engineering), 
> the question us whether it's significant or worth the trouble.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> 
>> 
>> affects each MN/CN combination and it's "hint" can cause more 
>> problems than it solves. BTW, if you're talking about hints then 
>> we're no longer talking about installing bindings in the MN. This is 
>> a different topic. MIP doesn't transfer hints, it pretty much sends "orders"
>> from one end to another.
>> 
>> => First, by assuming that the MN can reject the "hint" as you call 
>> it you invalidate the whole argument for the HA to install rules.
>> hints? This whole proposal makes no sense to me at all. Not to 
>> mention the complexity you implicitly assume in order to generate 
>> those, hopefully reliable, hints.
>> 
>> Hesham
>> 
>> 
>>> In my view these are events not scenarious. These events are known 
>>> by HA but not MN. If HA acts upon events, given that it knows 
>>> somewhat more about MN, not only IP addresses, it (HA) can generate 
>>> new rules and send them as hint to MN. Back again, MN has four options:
>>> 
>>>> Absent that, I don't see any point in having theory Vs practice 
>>>> high level discussions, which will lead nowhere.
>>>> 
>>>> Hesham
>>>> 
>>>> 
>>>>> 
>>>>> Regards
>>>>> Yuri
>>>>> 
>>>>>>> same reaction? I assume not. By that I mean that if, for 
>>>>>>> example, I'll install home agent in my home network, I can make 
>>>>>>> it know anything I want about MN, and more intresting is that 
>>>>>>> how I will do it, does not require any standardization.
>>>>>>> This situation is not unthinkable, I personally believe that 
>>>>>>> this is much more efficient way of using HA fnctionality as 
>>>>>>> opposed to big service providers who will have to fight with 
>>>>>>> scalability and performance.
>>>>>> quality) with a shorter period of variation. So, IMHO, there is 
>>>>>> no requirement for updating policy on a short period and 
>>>>>>> HA, which in my view would be quite natural. This implies that 
>>>>>>> HA must follow the rules installed by MN until explicit 
>>>>>>> acceptance has been received from MN.
>>>>>>> Such procedure is very similar to an MN beahviour when 
>>>>>>> initiating new BU, where MN is not supposed to send any traffic 
>>>>>>> before BU confirmation.
>>>>>>> BTW, what is the numerical representation of "rough consensus"? 
>>>>>>> I assume is when majority is for, is it so?
>>>>>>> Yuri
>>>>>>> 
>>>>>>> 
>>>>>>> I've always been a fan of the IETF's tradition of rough 
>>>>>>> concensus (as opposed to voting). To me, this implies that you 
>>>>>>> need to get your point across and get other people to see that point of view.
>>>>>>> mention how a solution should work, but rather what problem 
>>>>>>> needs to be solved.
>>>>>>> MN->HA. I'll deliberately ignore arguments like "some people 
>>>>>>> MN->want
>>>>>>> 1. The HA does not know whether a CoA is tied to a certain 
>>>>>>> access technology. It is one thing for the HA to send a message 
>>>>>>> saying "forward port 80 traffic on a wifi link" (a policy) and a 
>>>>>>> 2. You might argue that the HA can be told by the MN that 
>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? The 
>>>>>>> problem is that the HA has no idea about dynamic changes on that 
>>>>>>> wifi link. It doesn't know if it's congested, it doesn't know 
>>>>>>> what application is using port 80 (it doesn't have to be web 
>>>>>>> traffic) or port 8000 for that matter and doesn't even know if 
>>>>>>> the AP of that wifi link works at all.
>>>>>>> Finally, it
>>>>>>> changes all the time and requires serious cross layer 
>>>>>>> integration including sometimes layer 8 integration! It's completely impractical.
>>>>>>> 
>>>>>>> have to justify to the HA why it needs to move traffic? Does 
>>>>>>> that involve writing a letter perhaps?
>>>>>>> then I'll ask you: what's the point of having the HA install 
>>>>>>> this stuff if it has no authority and how does it know the 
>>>>>>> reason for the MN's movement of the flow?
>>>>>>> insisted that it wasn't. When I asked him to tell me how he 
>>>>>>> knows the link is up he said: I can ping the AP! Of course after 
>>>>>>> another
>>>>>>> the MN, please think of your HA as this help desk person, i.e. 
>>>>>>> it has no clue about what's happening at the other end.
>>>>>>>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 04 Jun 2009 00:08:50 +1000

On 3/06/09 10:47 PM, "Yuri Ismailov" <[email-masked]> wrote:

> The major difference here is that your are talking about CoA selection and I'm
> talking about interface selection. Quite a big difference.

=> No, that's not the point really. The point is that there is no
relationship between CoA/interface selection on the MN and the upstream ISP
for the home network.

> I do not see any grounds for MN to select CoA, based on what? Prefix length?
> While selection of an interface is based on expected characteristics of the
> communication. Routes (up/down)link in my opinion do have impact on the
> characteristics and this is exactly the information missing in the MN when
> selecting interface.

=> There is nothing missing for the MN to make this selection. Please tell
us specifically what is missing. You're changing points on me all the time
now. Lets stick to one point at a time. What's missing?

> Another thing is that MN will notice something e2e if and only if such support
> is implemented in the MN.

=> Of course, so what?

  Moreover, this notice can not be made at IP layer.
> TCP fights alone with all problems and never tells to any other layer what is
> going on. So what is left? Two options. Add this support to operating system,
> which makes its (support) existence questionable, or to applications, which is
> even more questionable.

=> It's interesting that you think it's questionable to add the support to
the MN's OS but not questionable to add the support to the HA's OS, which
will not lead to the same reliability as if it were done in the MN. It
doesn't make sense to me.

> Are you serious about that MIP may be broken because of that?

=> Yes! It's not designed to do what you want to do. Luckily, in this case
what you want, IMO, is broken anyway so it's not a problem.

Hesham

> issue is related to cost for certain times of day. This is a routing issue in
> the HA and has nothing to do with which interface the MN selects. The selected
> CoA has zero impact on the HA's upstream selection. Completely irrelevant
> actually.
> => You seem to think that there is a relationship between upstream routing and
> CoA selection. That's not the case at all. These are two different addresses
> from two different networks.
> 
> Hesham
> 
>> 
>> /yuri
>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 3 Jun 2009 16:24:28 +0200

Hesham

Missing is additional information which may be helpful in making better decision about interface selection by MN.
Which information is that I wrote in my previous emails. Back to my examples (not all, do not want to repeat myself). If HA will have changed traffic shaping parameters on one of the incoming or outgoing interfaces, this will be important information for MN to know.
We have agreed already that whether this information important or not, benfitial or not is a matter of standpoint.
I consider that knowing more is a benefit and will help to get better result.

My point is still the same. I see the reverse rules sending as possibility to provide more information to the MN, thus make MN to get to better decision about interface selection for its flows. This point has not changed since the beginning of the discussion.

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2009 4:09 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

On 3/06/09 10:47 PM, "Yuri Ismailov" <[email-masked]> wrote:

> The major difference here is that your are talking about CoA selection 
> and I'm talking about interface selection. Quite a big difference.

=> No, that's not the point really. The point is that there is no relationship between CoA/interface selection on the MN and the upstream ISP for the home network.

> While selection of an interface is based on expected characteristics 
> of the communication. Routes (up/down)link in my opinion do have 
> impact on the characteristics and this is exactly the information 
> missing in the MN when selecting interface.

=> There is nothing missing for the MN to make this selection. Please tell us specifically what is missing. You're changing points on me all the time now. Lets stick to one point at a time. What's missing?

> 
> Whenever, MN decides to move a flow, the reason can be anything but 
> not which CoA it has configured on each interface.
> 
> Another thing is that MN will notice something e2e if and only if such 
> support is implemented in the MN.

=> Of course, so what?

> TCP fights alone with all problems and never tells to any other layer 
> what is going on. So what is left? Two options. Add this support to 
> operating system, which makes its (support) existence questionable, or 
> to applications, which is even more questionable.

=> It's interesting that you think it's questionable to add the support to the MN's OS but not questionable to add the support to the HA's OS, which will not lead to the same reliability as if it were done in the MN. It doesn't make sense to me.

> Are you serious about that MIP may be broken because of that?

=> Yes! It's not designed to do what you want to do. Luckily, in this case what you want, IMO, is broken anyway so it's not a problem.

Hesham

>> is provided by the same access provider) and CN(s). The difference 
>> can be expressed in, let's say, number of hops, load, possibly 
>> something else. Such change is an event and may have an impact on the 
>> overall communication. This can be told directly to MN or HA. Direct 
>> communication to MN (if accepted as benefit:-)) in such case will 
>> need standardization. Communication of this information to HA does 
>> not (I consider this as a benefit). HA may act upon that event, and 
>> the rest you
> First, changing network conditions are best known e2e. So the MN will 
> know that anyway based on the traffic running between it and the CN. 
> The other issue is related to cost for certain times of day. This is a 
> routing issue in the HA and has nothing to do with which interface the 
> MN selects. The selected CoA has zero impact on the HA's upstream 
> selection. Completely irrelevant actually.
>> for each of HA interfaces. These preferences may vary independently 
>> of change of backbone provider but dependently on the time of day. 
>> The rest you know, whether it changes somebodies opinion.
> 
> => But again, this has zero effect on CoA selection. The two issues 
> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact on 
> the HA's upstream route.
> 
>> 
>> Benefits of doing that is that any change percieved by CN as 
>> important to react upon can be expressed in proposal of new rules. 
>> The sources causing changes may include but not limited to, are user, 
>> network managemnt events, application generated events, etc.
>> 
> => You seem to think that there is a relationship between upstream 
> routing and CoA selection. That's not the case at all. These are two 
> different addresses from two different networks.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> => No you didn't. You wrote about things that can be done. Many 
>> things can be done by many entities, the question is why the HA and not the MN.
>> 
>>> forgotten later is that by making rules distribution one way only, 
>>> we do create limitation for benefits, or potential benefits if this 
>>> sounds better.
>> 
>>> => Preferences change to what?? How does it know if such change 
>>> works for the MN at all? This is way too vague to be able to discuss tradeoffs.
>>> 
>>>>> => I think we've (I'm including myself) highlighted several 
>>>>> reasons for why it makes little sense to transfer rules from HA to MN.
>>>>>>>> Hesham Soliman; mext Objet : Re: [MEXT] Important 
>>>>>>>> considerations for directionality of flowbindings
>>>>>>>> 
>>>>>>>> Hesham,
>>>>>>>> tell him/her to check access point in some room. Would it be 
>>>>>>>> the same reaction? I assume not. By that I mean that if, for 
>>>>>>>> between HA and correspondent node. Either of this information 
>>>>>>>> is important, if not equally important.
>>>>>>>> On the charter question, I said that the charter doesn't need 
>>>>>>>> to mention how a solution should work, but rather what problem 
>>>>>>>> needs to be solved.
>>>>>>>> saying "forward port 80 traffic on a wifi link" (a policy) and 
>>>>>>>> a completely different thing to say "forward port 80 traffic 
>>>>>>>> using CoA 3ffe::1"
>>>>>>>> (a rule).
>>>>>>>> 
>>>>>>>> 3ffe::1 is tied to a wifi access, so what's the problem now? 
>>>>>>>> The problem is that the HA has no idea about dynamic changes on 
>>>>>>>> that wifi link. It doesn't know if it's congested, it doesn't 
>>>>>>>> know what application is using port 80 (it doesn't have to be 
>>>>>>>> web
>>>>>>>> wants to change those rules. Say the wifi link went down, or 
>>>>>>>> the MN's wifi interface went down and it wants to move that 
>>>>>>>> traffic to another interface. Would the HA reject such move? 
>>>>>>>> Does the MN have to justify to the HA why it needs to move 
>>>>>>>> traffic? Does that involve writing a letter perhaps?
>>>>>>>> If you say "well in that case, the HA should let the MN move 
>>>>>>>> the traffic"
>>>>>>>> knows the link is up he said: I can ping the AP! Of course 
>>>>>>>> after another
>>>>>>>> For those people who want rules to be transferred from the HA 
>>>>>>>> to the MN, please think of your HA as this help desk person, i.e.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Jun 2009 07:53:12 -0700 (PDT)

I mentioned it as an example of HA to MN type of control.
I think it will be good if you please stop disputing the charter which is coming from the text you yourself agreed several years ago.
Is this a better advice?

Behcet

----- Original Message ----
From: Hesham Soliman <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; George Tsirtsis <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, June 2, 2009 9:57:53 PM
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Behcet, 

On 3/06/09 2:42 AM, "Behcet Sarikaya" <[email-masked]> wrote:

>>>>> voting attitudes.. They all need to be justified if the WG wants to have
>>>>> the HA has no idea about dynamic changes on that wifi link... It doesn't

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 04 Jun 2009 12:00:09 +1000

Yuri,

> Missing is additional information which may be helpful in making better
> decision about interface selection by MN.
> Which information is that I wrote in my previous emails. Back to my examples
> (not all, do not want to repeat myself). If HA will have changed traffic
> shaping parameters on one of the incoming or outgoing interfaces, this will be
> important information for MN to know.
> We have agreed already that whether this information important or not,
> benfitial or not is a matter of standpoint.

=> I don't agree or like to think that it's a matter of standpoint. That's
why I asked you on every point you raised and compared this to the MN's
knowledge on e2e basis. Once we have "standpoints" then we're getting
outside the technical realm. The reason I don't think it's useful is that
this information cannot be used by the MN to select a CoA. I've already
stated that before and you seemed to agree so I don't know why you repeat
this as a reason for the HA to install filters in the MN. Let me say it
again: There is no correlation between the routing on the HA's upstream
interfaces/ISP with the MN's selection of a CoA.

> My point is still the same. I see the reverse rules sending as possibility to
> provide more information to the MN, thus make MN to get to better decision
> about interface selection for its flows. This point has not changed since the
> beginning of the discussion.

=> This is why we're not making progress IMO:

1. The hints you refer to are not the same things as installing rules on the
MN. Completely different information in fact. You've essentially proved that
when you suggested that the MN can accept or reject them. So, let's not call
them rules. The more direct word for what you want to send is policies

2. You didn't provide a valid scenario that we can discuss as to why it's
needed or how it could work. I've asked numerous questions in each email
that were not answered (with the exception of the last email). It's not
possible to progress the discussion without answering each others'
questions. You can go back through the threads and verify this.

3. If we're sending rules from the HA to the MN and the MN can reject those
rules then the whole exercise is pointless. You really want to send policies
not rules. I can imagine those policies being one of the inputs that the MN
uses to make a decision. I still fail to see how anything happening on the
HA's upstream interfaces/ISP link can possibly influence the MN's decision
for CoA selection. This is another unanswered question.

Hesham

> => No, that's not the point really. The point is that there is no relationship
> between CoA/interface selection on the MN and the upstream ISP for the home
> network.
> 
> => There is nothing missing for the MN to make this selection. Please tell us
> specifically what is missing. You're changing points on me all the time now.
> Lets stick to one point at a time. What's missing?
> 
>> 
> => It's interesting that you think it's questionable to add the support to the
> MN's OS but not questionable to add the support to the HA's OS, which will not
> lead to the same reliability as if it were done in the MN. It doesn't make
> sense to me.
> 
>> 
>>>> 
>>>>>>> MN.

---

From: w52006 <[email-masked]>
Date: Thu, 04 Jun 2009 11:25:23 +0800

Hello Hesham

Reading through your comments, I get two main points here and
provide my comments below.

1. Presumably you believe MN could/would always determine the 
optimized path in different network condition, and HA knows nothing.

You know, whatever it is, flow binding is driven by MIP-above function
(such as connect manager, app, etc). According to RFC1122, MS 
(host) may be simple or intelligent, which is also concerned in the 
MIF WG. Why do you think MN is that intelligent on flow 
management? I don't think so. 
On the contrary, I think, HA should be capable to adjust the forwarding 
path on behalf of network operator or HA service provider. (even if MN
is very intelligent). That's, there are three types of operations for flow 
binding on HA:
a) may accept/reject MN's flow binding request; or
b) may initiate flow binding to MN; (e.g. MN has registered MCoA, 
but does not bind any flow; that's, all traffic flows are over the primary 
CoA); or 
c) may initiate flow binding to hand off flow from one interface to 
another (e.g. HA is aware of access network congestion based on 
BFD-like mechanism. Please see more cases as Yuri mentioned)

Further, how HA knows App is up to how you (operator) identify App.

2. No benefits to flow rules exchange from HA to MN.

I think, one of the important benefits is that HA could adjust the 
forwarding path for MN on behalf of network operator or HA service 
provider.

Moreover, I observe one of your argumentation is "MN may change 
it if relavent link/interface is down, etc.". I think it is obviously not 
enough to prove anything. 

B.R.
Yungui

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 04 Jun 2009 14:04:11 +1000

> optimized path in different network condition, and HA knows nothing.

=> The HA knows nothing about the criteria that the MN will use to make the
decision. In your email below you didn't explain what the HA knows. More
below.

> management? I don't think so.

=> Because it knows everything it needs to make the decision. You still
didn't say what it doesn't know.

> On the contrary, I think, HA should be capable to adjust the forwarding

=> "should be capable"? This sounds like a wish. On what basis is the HA
capable of making that decision? This is a very simple question that you
need to answer before you can proceed with suggesting protocol messages.

> a) may accept/reject MN's flow binding request; or

=> Yes it can reject it of course like it does with any other binding. It
can also revoke it.

> but does not bind any flow; that's, all traffic flows are over the primary

=> On what basis? How does it decide that?

> BFD-like mechanism. Please see more cases as Yuri mentioned)

=> Completely unworkable. I already responded to Yuri's emails, feel free to
respond to that. I don't want to repeat myself.

> Further, how HA knows App is up to how you (operator) identify App.

=> huh? The operator doesn't identify apps and if it tried to identify apps
it's a guess based on historical data. The MN KNOWS the apps.

> forwarding path for MN on behalf of network operator or HA service

=> I've answered this point 3 times already. Please respond to those
answers. We can't keep repeating reasons that have already been shown to be
wrong unless you prove me wrong.

> enough to prove anything.

=> ?? I can't parse this.

Hesham

---

From: <[email-masked]>
Date: Thu, 4 Jun 2009 15:14:36 +0200

Hi,

Please see inline comments.

Regards,
Pierrick

> De : Hesham Soliman [mailto:[email-masked]]
> Envoyé : jeudi 4 juin 2009 06:04
> À : [email-masked]; 'Yuri Ismailov'; 'Nicolas Montavont'; SEITE
> Pierrick RD-RESA-REN
> Cc : [email-masked]
> Objet : Re: [MEXT] Important considerations for directionality
> offlowbindings
> 
> 
> 
> 

I definitely agree that a decision function is required to manage flow binding but, IMHO, who and how is making the decision is independent from the mobility execution protocol (i.e. MIP). Here, we just need to consider that policies/rules are available at the HA and MN side but I think that how these rules/policies are derived is out of scope in this discussion. Am I missing something? 

> => Because it knows everything it needs to make the decision. 

I agree. Actually there are different models for the decision architecture. Even if it could be possible for the HA to enforce the decision to the MN, I don't think it is the best way to do. The MN should be involved in the decision making process because it knows about local criteria for making the decision (e.g. applications running, user preferences, accesses available, quality of the communication links,...). Of course, it does not exclude the case where the decision process is shared between the MN and the network where a dedicated entity (it can be the HA but not necessary) provides policies and/or recommendation to the MN but the later should make the final decision for above reason. However as I said before, I think that discussion with regards to decision is out of scope here....     

> You still

---

From: "Yuri Ismailov" <[email-masked]>
Date: Thu, 4 Jun 2009 16:01:16 +0200

Hesham,

I provided several scenarious which you said are invalid. This is where my conclusion about standpoint comes from.
Whether you call hints policies or rules it does not change what information can be provided by HA to MN.
There were many arguments that ploicies may be sent to mn but not rules. For me rules is instantiation of policies evaluated based on an event.

By sending rules HA does not install anything in MN. Likewise, MN does not install rules in HA, it informs HA about currently made choices. As I remember rules will not be valid until proper Ack arrival, which for me means that may not be instantiated at all.
Niether rules nor polices are specific to MIP. As I wrote those can be exchanged between hosts without any MIP implementation, just for access selection purposes. Once it was decided to make it as part of MIP protocol, I'm fine with that. Do not have any idea to discuss this, while personally consider that the work on rules transfer can very well fit into the MEXT group but as a separate work item, but this is not the case now, so good enough the way it is.
And back again, it really gets repeated, so will lead to nowhere, you've got my arguments and tell that the information, which I'm talking about, is not usefull. What can I say more? I can put you on my position and start asking questions instead of answering. So, why it is not usefull?

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Thursday, June 04, 2009 4:00 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

> Missing is additional information which may be helpful in making 
> better decision about interface selection by MN.
> Which information is that I wrote in my previous emails. Back to my 
> examples (not all, do not want to repeat myself). If HA will have 
> changed traffic shaping parameters on one of the incoming or outgoing 
> interfaces, this will be important information for MN to know.

=> I don't agree or like to think that it's a matter of standpoint. That's why I asked you on every point you raised and compared this to the MN's knowledge on e2e basis. Once we have "standpoints" then we're getting outside the technical realm. The reason I don't think it's useful is that this information cannot be used by the MN to select a CoA. I've already stated that before and you seemed to agree so I don't know why you repeat this as a reason for the HA to install filters in the MN. Let me say it
again: There is no correlation between the routing on the HA's upstream interfaces/ISP with the MN's selection of a CoA.

> My point is still the same. I see the reverse rules sending as 
> possibility to provide more information to the MN, thus make MN to get 
> to better decision about interface selection for its flows. This point 
> has not changed since the beginning of the discussion.

1. The hints you refer to are not the same things as installing rules on the MN. Completely different information in fact. You've essentially proved that when you suggested that the MN can accept or reject them. So, let's not call them rules. The more direct word for what you want to send is policies

2. You didn't provide a valid scenario that we can discuss as to why it's needed or how it could work. I've asked numerous questions in each email that were not answered (with the exception of the last email). It's not possible to progress the discussion without answering each others'
questions. You can go back through the threads and verify this.

3. If we're sending rules from the HA to the MN and the MN can reject those rules then the whole exercise is pointless. You really want to send policies not rules. I can imagine those policies being one of the inputs that the MN uses to make a decision. I still fail to see how anything happening on the HA's upstream interfaces/ISP link can possibly influence the MN's decision for CoA selection. This is another unanswered question.

Hesham

>> The major difference here is that your are talking about CoA 
>> selection and I'm talking about interface selection. Quite a big difference.
> 
> relationship between CoA/interface selection on the MN and the 
> upstream ISP for the home network.
> 
> => There is nothing missing for the MN to make this selection. Please 
> tell us specifically what is missing. You're changing points on me all the time now.
>> Another thing is that MN will notice something e2e if and only if 
>> such support is implemented in the MN.
> 
> => Of course, so what?
> 
>> operating system, which makes its (support) existence questionable, 
>> or to applications, which is even more questionable.
> 
> => It's interesting that you think it's questionable to add the 
> support to the MN's OS but not questionable to add the support to the 
> HA's OS, which will not lead to the same reliability as if it were 
> done in the MN. It doesn't make sense to me.
> 
>> 
>>>> 
> => Yes! It's not designed to do what you want to do. Luckily, in this 
> case what you want, IMO, is broken anyway so it's not a problem.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> 
>>> - Access provider preferences relate to the use of backbone 
>>> provider, which may vary with the time of day. Changing backbone 
>>> provider can make quite big difference for commnication between HA 
>>> (if HA service is provided by the same access provider) and CN(s). 
>>> The difference can be expressed in, let's say, number of hops, load, 
>>> possibly something else. Such change is an event and may have an 
>>> impact on the overall communication. This can be told directly to MN 
>>> or HA. Direct communication to MN (if accepted as benefit:-)) in 
>>> such case will need standardization. Communication of this 
>>> information to HA does not (I consider this as a benefit). HA may 
>>> act upon that event, and the rest you
>> The other issue is related to cost for certain times of day. This is 
>> a routing issue in the HA and has nothing to do with which interface 
>> the MN selects. The selected CoA has zero impact on the HA's upstream 
>>> - Access provider may set up different parameters for traffic 
>>> shaping for each of HA interfaces. These preferences may vary 
>>> independently of change of backbone provider but dependently on the time of day.
>>> The sources causing changes may include but not limited to, are 
>>> user, network managemnt events, application generated events, etc.
>>> 
>>>> Whenever we talk about sending additional information, the "waste 
>>>> of bandwidth" can be brought up. So I do not have an answer for 
>>>> that besides speculations around it.
>>> 
>>>> turning things up side down. I assume it is subjective standpoint 
>>>> of considering things as benefits or disadvantages and all is about 
>>>> to agree or disagree.
>>> 
>>> The bottom line is this: MIP works by letting the MN install 
>>> bindings in the HA. If you want things to work in reverse you need 
>>> to justify it. I can't see any justifications because you're not 
>>> answering my questions on your scenarios. So, count me out on the reverse direction :).
>>> 
>>> 
>>> For
>>> => Well, we won't know what we're missing unless someone tells us. 
>>> So far no one has mentioned the advantages of doing things in the 
>>> reverse direction.
>>> There is always something missing from a protocol (it's 
>>> engineering), the question us whether it's significant or worth the trouble.
>>> 
>>> Hesham
>>> 
>>>> 
>>>> /yuri
>>>> 
>>>> 
>>>> 
>>>> conditions of the e2e path as well as or better than the HA. What 
>>>> is the benefit of having the HA send a hint and how reliable is 
>>>> that hint anyway?
>>>> 
>>>>>> - Traffic condition on HA interface, which accepts traffic from 
>>>>>> MN if MN sends on some particular local interface
>>>> 
>>>> we're no longer talking about installing bindings in the MN. This 
>>>> is a different topic. MIP doesn't transfer hints, it pretty much 
>>>> sends "orders"
>>>> from one end to another.
>>>> 
>>>> involvement? But if you're assuming that, then how can it reject 
>>>> the hints? This whole proposal makes no sense to me at all. Not to 
>>>>> somewhat more about MN, not only IP addresses, it (HA) can 
>>>>> generate new rules and send them as hint to MN. Back again, MN has four options:
>>>>> 
>>>>> transfer rules? The HA will not know the path between the MN and 
>>>>> CN more than either node does. So I don't understand what 
>>>>> _benefits_ you see here.
>>>>> 
>>>>> Hesham
>>>>> 
>>>>>> 
>>>>>> think about those not from MN point of view but rather from the 
>>>>>> HA service provider.
>>>>>> 
>>>>>> /yuri
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>>> De : [email-masked] [mailto:[email-masked]] De 
>>>>>>>>> la part de Yuri Ismailov Envoyé : vendredi 29 mai 2009 09:35 À :
>>>>>>>>> example, I'll install home agent in my home network, I can 
>>>>>>>>> make it know anything I want about MN, and more intresting is 
>>>>>>>>> that how I will do it, does not require any standardization.
>>>>>>>>> that a HA does not know what is going on in the access 
>>>>>>>>> network, on the other hand HA may know what is the network 
>>>>>>>>> condition between HA and correspondent node. Either of this 
>>>>>>>>> information is important, if not equally important.
>>>>>>>>> It is not really difficult to let an MN to reject rules sent 
>>>>>>>>> by HA, which in my view would be quite natural. This implies 
>>>>>>>>> that HA must follow the rules installed by MN until explicit 
>>>>>>>>> initiating new BU, where MN is not supposed to send any 
>>>>>>>>> traffic before BU confirmation.
>>>>>>>>> As opposed to other organisations that require their members 
>>>>>>>>> to vote and end up with rigid political positions.
>>>>>>>>> 
>>>>>>>>> strongly against voting and I'll practice this by explaining 
>>>>>>>>> in this email why I think rules can not be transferred from 
>>>>>>>>> the HA to the MN and that the only direction that makes sense 
>>>>>>>>> in MIP is
>>>>>>>>> category and I'm incapable of discussing them because they 
>>>>>>>>> come with voting attitudes. They all need to be justified if 
>>>>>>>>> the WG wants to have a technical _discussion_.
>>>>>>>>> 
>>>>>>>>> Here are my reasons:
>>>>>>>>> 
>>>>>>>>> access technology. It is one thing for the HA to send a 
>>>>>>>>> message saying "forward port 80 traffic on a wifi link" (a 
>>>>>>>>> policy) and a completely different thing to say "forward port 
>>>>>>>>> 80 traffic using CoA 3ffe::1"
>>>>>>>>> (a rule).
>>>>>>>>> 
>>>>>>>>> The problem is that the HA has no idea about dynamic changes 
>>>>>>>>> on that wifi link. It doesn't know if it's congested, it 
>>>>>>>>> doesn't know what application is using port 80 (it doesn't 
>>>>>>>>> have to be web
>>>>>>>>> binding revocation draft to handle flows and the rest is 
>>>>>>>>> pretty straight forward.
>>>>>>>>> 
>>>>>>>>> Finally, I'll indulge in a true story that happened to me a 
>>>>>>>>> few years ago when I found that my wifi link wasn't working in 
>>>>>>>>> a hotel (no
>>>>>>>>> radio)
>>>>>>>>> and called the help desk. He insisted that the link was up an 
>>>>>>>>> I insisted that it wasn't. When I asked him to tell me how he 
>>>>>>>>> 5 minutes of trying to convince him that pinging the AP 
>>>>>>>>> doesn't mean the radio is actually working he sent someone to 
>>>>>>>>> the hotel who in turn realised that the radio was not working.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Jun 2009 00:38:17 +1000

Yuri,

> can be provided by HA to MN.

=> It changes the outcome for the work item we're discussing. I'm trying to
come to a conclusion on this and there is a huge difference between
transferring policies and installing flow bindings.

> By sending rules HA does not install anything in MN. Likewise, MN does not
> install rules in HA, it informs HA about currently made choices. As I remember
> rules will not be valid until proper Ack arrival, which for me means that may
> not be instantiated at all.
> Niether rules nor polices are specific to MIP. As I wrote those can be
> exchanged between hosts without any MIP implementation, just for access
> selection purposes. Once it was decided to make it as part of MIP protocol,
> I'm fine with that. Do not have any idea to discuss this, while personally
> consider that the work on rules transfer can very well fit into the MEXT group
> but as a separate work item, but this is not the case now, so good enough the
> way it is.
> And back again, it really gets repeated, so will lead to nowhere, you've got
> my arguments and tell that the information, which I'm talking about, is not
> usefull. What can I say more? I can put you on my position and start asking
> questions instead of answering. So, why it is not usefull?

=> I explained why the specific information you mentioned was not
useful/useable by the MN and this is what I referred to as unanswered.
Because if you agree with my previous explanations then we don't need to
discuss it further. If you disagree you certainly didn't tell me why. You
have the charge of proof because you want to change the way MIP works
currently, that's all I'm trying to say.

Hesham 

> => I don't agree or like to think that it's a matter of standpoint. That's why
> I asked you on every point you raised and compared this to the MN's knowledge
> on e2e basis. Once we have "standpoints" then we're getting outside the
> technical realm. The reason I don't think it's useful is that this information
> cannot be used by the MN to select a CoA. I've already stated that before and
> you seemed to agree so I don't know why you repeat this as a reason for the HA
> to install filters in the MN. Let me say it
> needed or how it could work. I've asked numerous questions in each email that
> were not answered (with the exception of the last email). It's not possible to
> progress the discussion without answering each others'
> HA's upstream interfaces/ISP link can possibly influence the MN's decision for
> CoA selection. This is another unanswered question.
> 
> Hesham
> 
>> 
>> /yuri
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Jun 2009 08:12:48 -0700 (PDT)

Hesham, there is no change in your draft, I don't understand what you're really talking about. You should sit back and enjoy.

Regards,

Behcet

----- Original Message ----
From: Hesham Soliman <[email-masked]>
To: Yuri Ismailov <[email-masked]>; Nicolas Montavont <[email-masked]>; [email-masked]
Cc: [email-masked]
Sent: Thursday, June 4, 2009 9:38:17 AM
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

Hesham 

>> My point is still the same.. I see the reverse rules sending as
>> To: Yuri Ismailov; Nicolas Montavont;
>> pierrick.seite@orange-ftgroup..com
>> Cc: [email-masked]
>>>> when it comes to send rules in reverse direction between CN and MN..
>>>> To: Yuri Ismailov; Nicolas Montavont;
>>>> [email-masked]
>>>> Cc: [email-masked]
>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" <[email-masked]> wrote:
>>>> 
>>>>> Hesham,
>>>>> 
>>>>> from one end to another..
>>>>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Fri, 5 Jun 2009 10:14:31 +0200

Hesham,

Still not clear for me why you call scenarious invalid?
Some broadband providers (this is used in practice) have quota on the amount of traffic sent by users. Once quota is exceeded provider downgardes outgoing traffic from its network to 64Kbs (this figure is the real example from real provider). Such combination of to paths, where one is high speed, lets say 10 Mbs and another one is 64Kbs is quite crusual to apps running on top of TCP. Not for all types of traffic though.

MN can not know about this situation. Nobody will send this information to MN. That means that MN will choose its interfaces based on its knowledge about 10Mbs link capabilities. Obtaining this isnformation from HA is quite significant to make a better decision about choice of interfaces for its flows.
 This is concrete example of what happens in the reality.
Do you consider that this information will be useless for MN?

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Thursday, June 04, 2009 4:38 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

On 5/06/09 12:01 AM, "Yuri Ismailov" <[email-masked]> wrote:

> Hesham,
> 
> I provided several scenarious which you said are invalid. This is 
> where my conclusion about standpoint comes from.

=> It changes the outcome for the work item we're discussing. I'm trying to come to a conclusion on this and there is a huge difference between transferring policies and installing flow bindings.

> By sending rules HA does not install anything in MN. Likewise, MN does 
> not install rules in HA, it informs HA about currently made choices. 
> As I remember rules will not be valid until proper Ack arrival, which 
> for me means that may not be instantiated at all.
> exchanged between hosts without any MIP implementation, just for 
> access selection purposes. Once it was decided to make it as part of 
> MIP protocol, I'm fine with that. Do not have any idea to discuss 
> this, while personally consider that the work on rules transfer can 
> very well fit into the MEXT group but as a separate work item, but 
> this is not the case now, so good enough the way it is.
> And back again, it really gets repeated, so will lead to nowhere, 
> you've got my arguments and tell that the information, which I'm 
> talking about, is not usefull. What can I say more? I can put you on 
> my position and start asking questions instead of answering. So, why it is not usefull?

=> I explained why the specific information you mentioned was not useful/useable by the MN and this is what I referred to as unanswered.
Because if you agree with my previous explanations then we don't need to discuss it further. If you disagree you certainly didn't tell me why. You have the charge of proof because you want to change the way MIP works currently, that's all I'm trying to say.

Hesham 

> [email-masked]
> Cc: [email-masked]
>> We have agreed already that whether this information important or 
>> not, benfitial or not is a matter of standpoint.
> 
> => I don't agree or like to think that it's a matter of standpoint. 
> That's why I asked you on every point you raised and compared this to 
> the MN's knowledge on e2e basis. Once we have "standpoints" then we're 
> getting outside the technical realm. The reason I don't think it's 
> useful is that this information cannot be used by the MN to select a 
> CoA. I've already stated that before and you seemed to agree so I 
> don't know why you repeat this as a reason for the HA to install 
> filters in the MN. Let me say it
> again: There is no correlation between the routing on the HA's 
> upstream interfaces/ISP with the MN's selection of a CoA.
> 
>> possibility to provide more information to the MN, thus make MN to 
>> get to better decision about interface selection for its flows. This 
>> point has not changed since the beginning of the discussion.
> 
> 1. The hints you refer to are not the same things as installing rules 
> on the MN. Completely different information in fact. You've 
> essentially proved that when you suggested that the MN can accept or 
> reject them. So, let's not call them rules. The more direct word for 
> what you want to send is policies
> 
> 2. You didn't provide a valid scenario that we can discuss as to why 
> it's needed or how it could work. I've asked numerous questions in 
> each email that were not answered (with the exception of the last 
> email). It's not possible to progress the discussion without answering each others'
> 3. If we're sending rules from the HA to the MN and the MN can reject 
> those rules then the whole exercise is pointless. You really want to 
> send policies not rules. I can imagine those policies being one of the 
> inputs that the MN uses to make a decision. I still fail to see how 
> anything happening on the HA's upstream interfaces/ISP link can 
> possibly influence the MN's decision for CoA selection. This is another unanswered question.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> [email-masked]
>> Cc: [email-masked]
>>> TCP fights alone with all problems and never tells to any other 
>>> layer what is going on. So what is left? Two options. Add this 
>>> support to operating system, which makes its (support) existence 
>>> questionable, or to applications, which is even more questionable.
>> 
>>> [email-masked]
>>> Cc: [email-masked]
>>>> The difference can be expressed in, let's say, number of hops, 
>>>> load, possibly something else. Such change is an event and may have 
>>>> an impact on the overall communication. This can be told directly 
>>>> to MN or HA. Direct communication to MN (if accepted as benefit:-)) 
>>>> in such case will need standardization. Communication of this 
>>> First, changing network conditions are best known e2e. So the MN 
>>> will know that anyway based on the traffic running between it and the CN.
>>> the MN selects. The selected CoA has zero impact on the HA's 
>>> upstream selection. Completely irrelevant actually.
>>>> [email-masked]
>>>> Cc: [email-masked]
>>>> => no no, I don't mean it literally, I mean that the message 
>>>> doesn't do anything, i.e. Has no benefit.
>>>> 
>>>>> 
>>>>> Speaking about benefits, everybody who knows the area is capable 
>>>>> of turning things up side down. I assume it is subjective 
>>>>> standpoint of considering things as benefits or disadvantages and 
>>>>> all is about to agree or disagree.
>>>> 
>>>> the HA and I responded by saying that the same (or more) 
>>>> information is available to the MN. Therefore, if you think there 
>>>> are additional benefits to doing this in the HA then you need to tell us.
>>>> 
>>>>> we do create limitation for benefits, or potential benefits if 
>>>>> this sounds better.
>>>> 
>>>>> [email-masked]
>>>>> Cc: [email-masked]
>>>>> => What's the event? A change in those conditions? The MN knows 
>>>>> the conditions of the e2e path as well as or better than the HA. 
>>>>> What is the benefit of having the HA send a hint and how reliable 
>>>>> is that hint anyway?
>>>>> 
>>>>> => First, by assuming that the MN can reject the "hint" as you 
>>>>> call it you invalidate the whole argument for the HA to install rules.
>>>>>> In my view these are events not scenarious. These events are 
>>>>>> known by HA but not MN. If HA acts upon events, given that it 
>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) can 
>>>>>> generate new rules and send them as hint to MN. Back again, MN 
>>>>>> has four
>>>>>> options:
>>>>>> 
>>>>>> The benefit will be obviously that the new rules (if accepted) 
>>>>>> may llead to a better overall communication characteristics.
>>>>>> 
>>>>>> /yuri
>>>>>> 
>>>>>> 
>>>>>>> [email-masked]
>>>>>>> Cc: [email-masked]
>>>>>>>>> The difference between policy and rules is not only a matter 
>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set of 
>>>>>>>>> quality) with a shorter period of variation. So, IMHO, there 
>>>>>>>>> is no requirement for updating policy on a short period and 
>>>>>>>>>> Subject: [MEXT] Important considerations for directionality 
>>>>>>>>>> of flow bindings
>>>>>>>>>> 
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> concensus (as opposed to voting). To me, this implies that 
>>>>>>>>>> you need to get your point across and get other people to see 
>>>>>>>>>> that point of view.
>>>>>>>>>> to mention how a solution should work, but rather what 
>>>>>>>>>> problem needs to be solved.
>>>>>>>>>> traffic) or port 8000 for that matter and doesn't even know 
>>>>>>>>>> if the AP of that wifi link works at all.
>>>>>>>>>> Finally, it
>>>>>>>>>> This type of information needs to be sent regularly because 
>>>>>>>>>> it changes all the time and requires serious cross layer 
>>>>>>>>>> 3. If the HA installed rules in the MN, what happens if the 
>>>>>>>>>> MN wants to change those rules. Say the wifi link went down, 
>>>>>>>>>> or the MN's wifi interface went down and it wants to move 
>>>>>>>>>> that traffic to another interface. Would the HA reject such move?
>>>>>>>>>> flows on the MN. I'm perfectly fine with that, just extend 
>>>>>>>>>> the binding revocation draft to handle flows and the rest is 
>>>>>>>>>> pretty straight forward.
>>>>>>>>>> 
>>>>>>>>>> few years ago when I found that my wifi link wasn't working 
>>>>>>>>>> in a hotel (no
>>>>>>>>>> radio)
>>>>>>>>>> I hope this helps with the realisation that decisions can't 
>>>>>>>>>> be made here based on voting and that there is little merit 
>>>>>>>>>> to transferring rules from the HA to the MN. Policies can be

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Jun 2009 19:37:03 +1000

Yuri,

> Some broadband providers (this is used in practice) have quota on the amount
> of traffic sent by users. Once quota is exceeded provider downgardes outgoing
> traffic from its network to 64Kbs (this figure is the real example from real
> provider). Such combination of to paths, where one is high speed, lets say 10
> Mbs and another one is 64Kbs is quite crusual to apps running on top of TCP.
> Not for all types of traffic though.

=> Yes I know the scenario but I keep saying to you that the change in
upstream routing in the HA has nothing to do with CoA selection by the MN in
the visited network. If anything, you want the MN to change it's HoA
depending on how the switch to another upstream ISP works. It's a completely
irrelevant issue to this discussion. Do you agree? If not why not? I really
want to see an answer to this point.

> 
> MN can not know about this situation. Nobody will send this information to MN.

=> Yes and if it knows what will it do??? If you can answer that you will
fix the deadlock we have.

> That means that MN will choose its interfaces based on its knowledge about
> 10Mbs link capabilities.

=> You're talking about two different things. The MN doesn't choose the HA's
outgoing interface! What am I missing?

 Obtaining this isnformation from HA is quite
> significant to make a better decision about choice of interfaces for its
> flows.

=> Completely useless. Unless I'm missing something in your scenario. Just
write down step by step what will happen and include messages. I don't see
how this can possibly be relevant to the MN.

Hesham

Hesham

> discuss it further. If you disagree you certainly didn't tell me why. You have
> the charge of proof because you want to change the way MIP works currently,
> that's all I'm trying to say.
> 
> Hesham 
> 
>> 
>> /yuri
>> 
>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Fri, 5 Jun 2009 14:46:37 +0200

Hesham,

Let's proceed with sorting out what we are talking about, this probably will help structuring examples and scenarious

My assumptions: (probably shuold have been mentioned earlier)
If we will agree on assumptions, then it will make sense to go further on.

First is that I assume that we have simulteneous multiaccess in mind, i.e. MN has more than one interface to choose from for its flows. If this is not the case then I will stop the discussion. This assumption is based on the fact that we are (I hope at least) discussing flow mobility.

Secondly, I consider that MN chooses an interface but not CoA. I gave a though about that and did not come up with any information which can be derived from CoA in order to choose it. An interface has at least expected characteristics, thus can be a subject of choice. Any clarification about that would be appreciated.

Next assumptions are about possible configurations of HA
- Single HA for all interfaces configured in the mobile. HA can belong to any of the access providers of each of access technology used by MN.

- One HA per access or set of accesses, which is subset of all access techologies presented or potentially may be presented (detached devices) in MN.
Anticipating numerous questions about that can say that I looked at such configuration and did not find anything strange with it, i.e. (1) it works, (2) it does not require any change to MIP or any other of its extensions. (3) Configuration is performed per interface and does not introduce any ambiguities. (4) it is natural for access provider to offer HA service.

- "Residential" HA. Assumption is that it can be either one of HA's or a single HA for all types of accesses. This is the matter of MN configuration.
"Residential".

- Any HA may have multiple interfaces, e.g. "residential" HA may be connected to mobile broadband, DSL, etc.

Next assumption comes from the example (e.g. latest one)
- Traffic shaping is applied in both directions (up/down) link (in practice this is the case).
- Traffic shaping (TS) is applied to user subscription. In other words TS is applied to packets belonging to a particular subscription but not to an aggregated traffic on gateway interfaces. HA is not necessary (however, nothing prevents from that) a gateway where TS is applied.

I hope that I have not missed something, although it may be possible.
If we can agree on that or correct if something is wrong here and agree later then we know how to proceed further on

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 11:37 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

> Some broadband providers (this is used in practice) have quota on the 
> amount of traffic sent by users. Once quota is exceeded provider 
> downgardes outgoing traffic from its network to 64Kbs (this figure is 
> the real example from real provider). Such combination of to paths, 
> where one is high speed, lets say 10 Mbs and another one is 64Kbs is quite crusual to apps running on top of TCP.

=> Yes I know the scenario but I keep saying to you that the change in upstream routing in the HA has nothing to do with CoA selection by the MN in the visited network. If anything, you want the MN to change it's HoA depending on how the switch to another upstream ISP works. It's a completely irrelevant issue to this discussion. Do you agree? If not why not? I really want to see an answer to this point.

> MN can not know about this situation. Nobody will send this information to MN.

=> Yes and if it knows what will it do??? If you can answer that you will fix the deadlock we have.

> That means that MN will choose its interfaces based on its knowledge 
> about 10Mbs link capabilities.

=> You're talking about two different things. The MN doesn't choose the HA's outgoing interface! What am I missing?

> significant to make a better decision about choice of interfaces for 
> its flows.

=> Completely useless. Unless I'm missing something in your scenario. Just write down step by step what will happen and include messages. I don't see how this can possibly be relevant to the MN.

Hesham

Hesham

> => It changes the outcome for the work item we're discussing. I'm 
> trying to come to a conclusion on this and there is a huge difference 
> between transferring policies and installing flow bindings.
> 
>> By sending rules HA does not install anything in MN. Likewise, MN 
>> does not install rules in HA, it informs HA about currently made choices.
>> Niether rules nor polices are specific to MIP. As I wrote those can 
>> be exchanged between hosts without any MIP implementation, just for 
> Because if you agree with my previous explanations then we don't need 
> to discuss it further. If you disagree you certainly didn't tell me 
> why. You have the charge of proof because you want to change the way 
> MIP works currently, that's all I'm trying to say.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> 
>>> changed traffic shaping parameters on one of the incoming or 
>>> outgoing interfaces, this will be important information for MN to know.
>> the MN's knowledge on e2e basis. Once we have "standpoints" then 
>> we're getting outside the technical realm. The reason I don't think 
>> it's useful is that this information cannot be used by the MN to 
>> select a CoA. I've already stated that before and you seemed to agree 
>> so I don't know why you repeat this as a reason for the HA to install 
>> send policies not rules. I can imagine those policies being one of 
>> the inputs that the MN uses to make a decision. I still fail to see 
>> how anything happening on the HA's upstream interfaces/ISP link can 
>>>> While selection of an interface is based on expected 
>>>> characteristics of the communication. Routes (up/down)link in my 
>>>> opinion do have impact on the characteristics and this is exactly 
>>>> the information missing in the MN when selecting interface.
>>> 
>>> => There is nothing missing for the MN to make this selection. 
>>> Please tell us specifically what is missing. You're changing points 
>>> on me all the time now.
>>> support to the MN's OS but not questionable to add the support to 
>>> the HA's OS, which will not lead to the same reliability as if it 
>>> were done in the MN. It doesn't make sense to me.
>>> 
>>>> 
>>>>>> 
>>> => Yes! It's not designed to do what you want to do. Luckily, in 
>>> this case what you want, IMO, is broken anyway so it's not a problem.
>>> 
>>> Hesham
>>> 
>>>> 
>>>> /yuri
>>>> 
>>>> 
>>>>> load, possibly something else. Such change is an event and may 
>>>>> have an impact on the overall communication. This can be told 
>>>>> directly to MN or HA. Direct communication to MN (if accepted as 
>>>>> benefit:-)) in such case will need standardization. Communication 
>>>>> of this information to HA does not (I consider this as a benefit). 
>>>>> HA may act upon that event, and the rest you
>>>> The other issue is related to cost for certain times of day. This 
>>>> is a routing issue in the HA and has nothing to do with which 
>>>> interface the MN selects. The selected CoA has zero impact on the 
>>>> HA's upstream selection. Completely irrelevant actually.
>>>> are completely orthogonal. Selecting CoA1 or CoA2 has zero impact 
>>>> on the HA's upstream route.
>>>> 
>>>>> 
>>>> routing and CoA selection. That's not the case at all. These are 
>>>> two different addresses from two different networks.
>>>> 
>>>> Hesham
>>>> 
>>>>> 
>>>>> /yuri
>>>>> 
>>>>> It's impossible to discuss this if I can't see any benefits 
>>>>> because you didn't send any. What you sent were actions that can 
>>>>> be done by the HA and I responded by saying that the same (or 
>>>>> more) information is available to the MN. Therefore, if you think 
>>>>> there are additional benefits to doing this in the HA then you need to tell us.
>>>>> 
>>>>>> forgotten later is that by making rules distribution one way 
>>>>>> only, we do create limitation for benefits, or potential benefits 
>>>>>> if this sounds better.
>>>>> 
>>>>>> the hints? This whole proposal makes no sense to me at all. Not 
>>>>>> to mention the complexity you implicitly assume in order to 
>>>>>> generate those, hopefully reliable, hints.
>>>>>> 
>>>>>> Hesham
>>>>>> 
>>>>>> 
>>>>>>>> Pretty much sure that there are more examples and I encourage 
>>>>>>>> to think about those not from MN point of view but rather from 
>>>>>>>> the HA service provider.
>>>>>>>> 
>>>>>>>> /yuri
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> advocating the other direction) need to come up with reasons 
>>>>>>>> for doing things this way. This way we can think like engineers 
>>>>>>>> about tradeoffs.
>>>>>>>>>>> Think of the situation when superior of a heldesk person 
>>>>>>>>>>> will tell him/her to check access point in some room. Would 
>>>>>>>>>>> it be the same reaction? I assume not. By that I mean that 
>>>>>>>>>>> if, for example, I'll install home agent in my home network, 
>>>>>>>>>>> I can make it know anything I want about MN, and more 
>>>>>>>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>>>>>>>> On Behalf Of Hesham Soliman
>>>>>>>>>>> you need to get your point across and get other people to 
>>>>>>>>>>> see that point of view.
>>>>>>>>>>> On the charter question, I said that the charter doesn't 
>>>>>>>>>>> need to mention how a solution should work, but rather what 
>>>>>>>>>>> the HA to the MN and that the only direction that makes 
>>>>>>>>>>> sense in MIP is
>>>>>>>>>>> policy) and a completely different thing to say "forward 
>>>>>>>>>>> port 80 traffic using CoA 3ffe::1"
>>>>>>>>>>> (a rule).
>>>>>>>>>>> 
>>>>>>>>>>> The way to control how users do things is to incentivise 
>>>>>>>>>>> them with charging models and show them that things work 
>>>>>>>>>>> better on certain technologies, not by installing rules that 
>>>>>>>>>>> can't be followed. It's a broken mindset and we've known 
>>>>>>>>>>> that it's broken for a long time.
>>>>>>>>>>> 
>>>>>>>>>>> 4. Some people mentioned that the HA should be able to 
>>>>>>>>>>> revoke flows on the MN. I'm perfectly fine with that, just 
>>>>>>>>>>> extend the binding revocation draft to handle flows and the 
>>>>>>>>>>> rest is pretty straight forward.
>>>>>>>>>>> 
>>>>>>>>>>> and called the help desk. He insisted that the link was up 
>>>>>>>>>>> an I insisted that it wasn't. When I asked him to tell me 
>>>>>>>>>>> how he knows the link is up he said: I can ping the AP! Of 
>>>>>>>>>>> course after another
>>>>>>>>>>> doesn't mean the radio is actually working he sent someone 
>>>>>>>>>>> to the hotel who in turn realised that the radio was not working.
>>>>>>>>>>> For those people who want rules to be transferred from the 
>>>>>>>>>>> HA to the MN, please think of your HA as this help desk person, i.e.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 06 Jun 2009 00:17:54 +1000

> First is that I assume that we have simulteneous multiaccess in mind, i.e. MN
> has more than one interface to choose from for its flows. If this is not the
> case then I will stop the discussion. This assumption is based on the fact
> that we are (I hope at least) discussing flow mobility.

=> Sure.

> 
> Secondly, I consider that MN chooses an interface but not CoA. I gave a though
> about that and did not come up with any information which can be derived from
> CoA in order to choose it. An interface has at least expected characteristics,
> thus can be a subject of choice. Any clarification about that would be
> appreciated.
=> An application would choose an interface, but of course the IP stack
selects the corresponding address. I'm sure there is no disagreement there.

> - Single HA for all interfaces configured in the mobile. HA can belong to any
> of the access providers of each of access technology used by MN.

=> Ok.

> 
> - One HA per access or set of accesses, which is subset of all access
> techologies presented or potentially may be presented (detached devices) in
> MN.

=> Now you're getting into a different problem space from flow mobility.
This is why I wanted you to break the scenario down. We are not dealing with
multiple HoAs in this work item, we're dealing with multiple CoAs, i.e. One
HoA.

> Anticipating numerous questions about that can say that I looked at such
> configuration and did not find anything strange with it, i.e. (1) it works,
> (2) it does not require any change to MIP or any other of its extensions. (3)
> Configuration is performed per interface and does not introduce any
> ambiguities. (4) it is natural for access provider to offer HA service.

=> Yes of course it works but as I read this I'm guessing that you want the
MN to change HoA. This is not the problem we're discussing in this WG.
Another issue, I'm not comfortable with the wording of "HA per access"
because they're not tied to access. Let's just say there are multiple Has
and not associate it with an access.

> 
> - "Residential" HA. Assumption is that it can be either one of HA's or a
> single HA for all types of accesses. This is the matter of MN configuration.
> "Residential".

=> Please don't tie HA to access.

> to mobile broadband, DSL, etc.

=> sure

> - Traffic shaping (TS) is applied to user subscription. In other words TS is
> applied to packets belonging to a particular subscription but not to an
> aggregated traffic on gateway interfaces. HA is not necessary (however,
> nothing prevents from that) a gateway where TS is applied.
> 
> 

=> Your scenario is fine (with the wording changes for tying Has to access).
But I want to pre-empt any suggestion that the HA will tell the MN to use a
different HoA. This is very possible but it's not the problem being
discussed here. It may well be something for charter discussion but it has
zero impact on flow bindings for multiple CoAs.

Hesham

> the visited network. If anything, you want the MN to change it's HoA depending
> on how the switch to another upstream ISP works. It's a completely irrelevant
> issue to this discussion. Do you agree? If not why not? I really want to see
> an answer to this point.
> 
>  
> 
> 
>> 
> write down step by step what will happen and include messages. I don't see how
> this can possibly be relevant to the MN.
> 
> Hesham
> 
> Hesham
> 
>> 
>> /yuri
>> 
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 5 Jun 2009 09:27:19 -0700 (PDT)

Hi Yuri,
  I agree with all of your assumptions, I think they are all relevant to flow mobility discussions.
  However in order to have some progress, I would like to know the results of Marcelo's poll. I would like to see people stop questioning the charter, esp. no HA to MN flow binding, etc..
  Once that is done, I think the next thing is to discuss on a specific draft which gives a solution to HA to MN flow binding.

Regards,

Behcet

----- Original Message ----
From: Yuri Ismailov <[email-masked]>
To: Hesham Soliman <[email-masked]>; Nicolas Montavont <[email-masked]>; [email-masked]
Cc: [email-masked]
Sent: Friday, June 5, 2009 7:46:37 AM
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Hesham,

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 11:37 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

Hesham

Hesham

>>>  Moreover, this notice can not be made at IP layer..
>>>>> First of all MIP will not be breaked if the rules will be sent in 
>>>>> both directions..
>>>> 
>>>>> => No you didn't.. You wrote about things that can be done. Many

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 8 Jun 2009 09:50:40 +0200

Behcet,

This is what I found in the charter. (http://www.ietf.org/html.charters/mext-charter.html)

********************************************************************
- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].
*********************************************************************

So the discussion how HA can influence choice of interfaces in MN is under the charter cover or I missunderstood something?

/yuri

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 6:27 PM
To: Yuri Ismailov
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Hi Yuri,

Regards,

Behcet

----- Original Message ----
From: Yuri Ismailov <[email-masked]>
To: Hesham Soliman <[email-masked]>; Nicolas Montavont <[email-masked]>; [email-masked]
Cc: [email-masked]
Sent: Friday, June 5, 2009 7:46:37 AM
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Hesham,

My assumptions: (probably shuold have been mentioned earlier) If we will agree on assumptions, then it will make sense to go further on.

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]]
Sent: Friday, June 05, 2009 11:37 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri,

Hesham

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 8 Jun 2009 10:29:20 +0200

Hesham, It looks like that the only point of disagreement is about changing HA and mapping between HA and access.
Some explanations of what I mean below:

1. Changing HA.
As it follows from group charter change of HA is in the plans of MEXT WG. I assume that this is going to be a separate work item because the reason specified for that is very specific and relates to deployment more than to flow mobility. Do not want to speculate, about this right now but the change of HA does not necessarily means change of rules.
So the proposal is to not to discuss change of HA as you suggested.

2. In my example I do not mean change of HA as an explicit procedure specified separately. One confirmation to that is that single HA for all interfaces is included and valid option. Based on the HA -> MN exchange, the MN may perform interface selection procedure and may choose another interface for some flow(s). In multiple HA case it will result of the rules update MN -> HA to the HA which is relevant for the new interface chosen for flows. Please notice, There is nothing about HA change, only about interface selection.

3. I do not map HA and access. It is allowed for any access provider to offer HA service and once this is the case it will be so. Thus an MN can have multiple HA configured for the use on different interfaces.

Regards
Yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 4:18 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

> First is that I assume that we have simulteneous multiaccess in mind, 
> i.e. MN has more than one interface to choose from for its flows. If 
> this is not the case then I will stop the discussion. This assumption 
> is based on the fact that we are (I hope at least) discussing flow mobility.

=> Sure.

> 
> Secondly, I consider that MN chooses an interface but not CoA. I gave 
> a though about that and did not come up with any information which can 
> be derived from CoA in order to choose it. An interface has at least 
> expected characteristics, thus can be a subject of choice. Any 
> clarification about that would be appreciated.
=> An application would choose an interface, but of course the IP stack selects the corresponding address. I'm sure there is no disagreement there.

> - Single HA for all interfaces configured in the mobile. HA can belong 
> to any of the access providers of each of access technology used by MN.

=> Ok.

> techologies presented or potentially may be presented (detached 
> devices) in MN.

=> Now you're getting into a different problem space from flow mobility.
This is why I wanted you to break the scenario down. We are not dealing with multiple HoAs in this work item, we're dealing with multiple CoAs, i.e. One HoA.

> Anticipating numerous questions about that can say that I looked at 
> such configuration and did not find anything strange with it, i.e. (1) 
> it works,
> (2) it does not require any change to MIP or any other of its 
> extensions. (3) Configuration is performed per interface and does not 
> introduce any ambiguities. (4) it is natural for access provider to offer HA service.

=> Yes of course it works but as I read this I'm guessing that you want the MN to change HoA. This is not the problem we're discussing in this WG.
Another issue, I'm not comfortable with the wording of "HA per access"
because they're not tied to access. Let's just say there are multiple Has and not associate it with an access.

> 
> - "Residential" HA. Assumption is that it can be either one of HA's or 
> a single HA for all types of accesses. This is the matter of MN configuration.
> "Residential".

=> sure

> - Traffic shaping (TS) is applied to user subscription. In other words 
> TS is applied to packets belonging to a particular subscription but 
> not to an aggregated traffic on gateway interfaces. HA is not 
> necessary (however, nothing prevents from that) a gateway where TS is applied.
> 
> 
> If we can agree on that or correct if something is wrong here and 
> agree later then we know how to proceed further on

=> Your scenario is fine (with the wording changes for tying Has to access).
But I want to pre-empt any suggestion that the HA will tell the MN to use a different HoA. This is very possible but it's not the problem being discussed here. It may well be something for charter discussion but it has zero impact on flow bindings for multiple CoAs.

Hesham

>> where one is high speed, lets say 10 Mbs and another one is 64Kbs is 
>> quite crusual to apps running on top of TCP.
> upstream routing in the HA has nothing to do with CoA selection by the 
> MN in the visited network. If anything, you want the MN to change it's 
> HoA depending on how the switch to another upstream ISP works. It's a 
> completely irrelevant issue to this discussion. Do you agree? If not 
> why not? I really want to see an answer to this point.
> 
>  
> 
> 
>> 
> => You're talking about two different things. The MN doesn't choose 
> the HA's outgoing interface! What am I missing?
> 
> => Completely useless. Unless I'm missing something in your scenario. 
> Just write down step by step what will happen and include messages. I 
> don't see how this can possibly be relevant to the MN.
> 
> Hesham
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> 
>>> As I remember rules will not be valid until proper Ack arrival, 
>>> which for me means that may not be instantiated at all.
>>> That's why I asked you on every point you raised and compared this 
>>> to the MN's knowledge on e2e basis. Once we have "standpoints" then 
>>> select a CoA. I've already stated that before and you seemed to 
>>> agree so I don't know why you repeat this as a reason for the HA to 
>>> install filters in the MN. Let me say it
>>>> get to better decision about interface selection for its flows. 
>>>> This point has not changed since the beginning of the discussion.
>>> 
>>> 1. The hints you refer to are not the same things as installing 
>>> rules on the MN. Completely different information in fact. You've 
>>> 3. If we're sending rules from the HA to the MN and the MN can 
>>> reject those rules then the whole exercise is pointless. You really 
>>> want to send policies not rules. I can imagine those policies being 
>>> one of the inputs that the MN uses to make a decision. I still fail 
>>> to see how anything happening on the HA's upstream interfaces/ISP 
>>> link can possibly influence the MN's decision for CoA selection. 
>>> This is another unanswered question.
>>> 
>>> Hesham
>>> 
>>>> 
>>>> /yuri
>>>> 
>>>>> Whenever, MN decides to move a flow, the reason can be anything 
>>>>> but not which CoA it has configured on each interface.
>>>>> 
>>>>>> both directions.
>>>>>> provider can make quite big difference for commnication between 
>>>>>> HA (if HA service is provided by the same access provider) and CN(s).
>>>>> => But again, this has zero effect on CoA selection. The two 
>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has zero 
>>>>> impact on the HA's upstream route.
>>>>> 
>>>>>> 
>>>>>> - I presume that in RO mode this is similar to HA mode, and I'm 
>>>>>> in when it comes to send rules in reverse direction between CN and MN.
>>>>>>> Whenever we talk about sending additional information, the 
>>>>>>> "waste of bandwidth" can be brought up. So I do not have an 
>>>>>>> answer for that besides speculations around it.
>>>>>> 
>>>>>>> standpoint of considering things as benefits or disadvantages 
>>>>>>> and all is about to agree or disagree.
>>>>>> 
>>>>>> bindings in the HA. If you want things to work in reverse you 
>>>>>> need to justify it. I can't see any justifications because you're 
>>>>>> not answering my questions on your scenarios. So, count me out on 
>>>>>> the reverse direction :).
>>>>>> 
>>>>>> 
>>>>>> For
>>>>>>> only, we do create limitation for benefits, or potential 
>>>>>>> benefits if this sounds better.
>>>>>> 
>>>>>>> What is the benefit of having the HA send a hint and how 
>>>>>>> reliable is that hint anyway?
>>>>>>> 
>>>>>>>>> - Traffic condition on HA interface, which accepts traffic 
>>>>>>>>> from MN if MN sends on some particular local interface
>>>>>>> 
>>>>>>> => These are path changes. The HA has _no idea_ how such a 
>>>>>>> change affects each MN/CN combination and it's "hint" can cause 
>>>>>>> more problems than it solves. BTW, if you're talking about hints 
>>>>>>> then we're no longer talking about installing bindings in the 
>>>>>>> MN. This is a different topic. MIP doesn't transfer hints, it 
>>>>>>>> knows somewhat more about MN, not only IP addresses, it (HA) 
>>>>>>>> can generate new rules and send them as hint to MN. Back again, 
>>>>>>>> MN has four
>>>>>>>> options:
>>>>>>>> 
>>>>>>>> transfer rules? The HA will not know the path between the MN 
>>>>>>>> and CN more than either node does. So I don't understand what 
>>>>>>>> _benefits_ you see here.
>>>>>>>> 
>>>>>>>> Hesham
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> for doing things this way. This way we can think like 
>>>>>>>>> Absent that, I don't see any point in having theory Vs 
>>>>>>>>> practice high level discussions, which will lead nowhere.
>>>>>>>>> 
>>>>>>>>> Hesham
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Regards
>>>>>>>>>> Yuri
>>>>>>>>>> 
>>>>>>>>>> On Jun 2, 2009, at 4:11 PM, 
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi all,
>>>>>>>>>>> 
>>>>>>>>>>>> De : [email-masked] [mailto:[email-masked]] 
>>>>>>>>>>>> De la part de Yuri Ismailov Envoyé : vendredi 29 mai 2009 09:35 À :
>>>>>>>>>>>> however some details are ommited. In your adventure with 
>>>>>>>>>>>> the helpdesk, it (the
>>>>>>>>>>>> if, for example, I'll install home agent in my home 
>>>>>>>>>>>> network, I can make it know anything I want about MN, and 
>>>>>>>>>>>> more intresting is that how I will do it, does not require 
>>>>>>>>>>>> any standardization.
>>>>>>>>>>>> This situation is not unthinkable, I personally believe 
>>>>>>>>>>>> that this is much more efficient way of using HA 
>>>>>>>>>>>> fnctionality as opposed to big service providers who will 
>>>>>>>>>>>> have to fight with scalability and performance.
>>>>>>>>>>> of conversion. A policy, is a static, or quasi-static, set 
>>>>>>>>>>> of guidance for the MN (e.g use access network X for 
>>>>>>>>>>> application type
>>>>>>>>>>>> It is not really difficult to let an MN to reject rules 
>>>>>>>>>>>> sent by HA, which in my view would be quite natural. This 
>>>>>>>>>>>> implies that HA must follow the rules installed by MN until 
>>>>>>>>>>>> explicit acceptance has been received from MN.
>>>>>>>>>>>> As opposed to other organisations that require their 
>>>>>>>>>>>> members to vote and end up with rigid political positions.
>>>>>>>>>>>> 
>>>>>>>>>>>> The chairs asked us about the directionality question of 
>>>>>>>>>>>> the flows bindings.
>>>>>>>>>>>> requirement for the solution. And when it comes to this, 
>>>>>>>>>>>> I'm strongly against voting and I'll practice this by 
>>>>>>>>>>>> explaining in this email why I think rules can not be 
>>>>>>>>>>>> transferred from the HA to the MN and that the only 
>>>>>>>>>>>> direction that makes sense in MIP is
>>>>>>>>>>>> MN->HA. I'll deliberately ignore arguments like "some 
>>>>>>>>>>>> MN->people want
>>>>>>>>>>>> come with voting attitudes. They all need to be justified 
>>>>>>>>>>>> if the WG wants to have a technical _discussion_.
>>>>>>>>>>>> 
>>>>>>>>>>>> Here are my reasons:
>>>>>>>>>>>> 
>>>>>>>>>>>> The problem is that the HA has no idea about dynamic 
>>>>>>>>>>>> changes on that wifi link. It doesn't know if it's 
>>>>>>>>>>>> congested, it doesn't know what application is using port 
>>>>>>>>>>>> 80 (it doesn't have to be web
>>>>>>>>>>>> MN wants to change those rules. Say the wifi link went 
>>>>>>>>>>>> down, or the MN's wifi interface went down and it wants to 
>>>>>>>>>>>> move that traffic to another interface. Would the HA reject such move?
>>>>>>>>>>>> If you say "well in that case, the HA should let the MN 
>>>>>>>>>>>> move the traffic"
>>>>>>>>>>>> then I'll ask you: what's the point of having the HA 
>>>>>>>>>>>> install this stuff if it has no authority and how does it 
>>>>>>>>>>>> know the reason for the MN's movement of the flow?
>>>>>>>>>>>> better on certain technologies, not by installing rules 
>>>>>>>>>>>> that can't be followed. It's a broken mindset and we've 
>>>>>>>>>>>> known that it's broken for a long time.
>>>>>>>>>>>> 
>>>>>>>>>>>> to transferring rules from the HA to the MN. Policies can 
>>>>>>>>>>>> be transferred without any problems, but not rules.
>>>>>>>>>>>> 
>>>>>>>>>>>> Hesham
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 08 Jun 2009 22:00:24 +1000

Yuri, 

I think we're getting close here.

On 8/06/09 6:29 PM, "Yuri Ismailov" <[email-masked]> wrote:

> As it follows from group charter change of HA is in the plans of MEXT WG. I
> assume that this is going to be a separate work item because the reason
> specified for that is very specific and relates to deployment more than to
> flow mobility. Do not want to speculate, about this right now but the change
> of HA does not necessarily means change of rules.

=> Agreed.

> 
> 2. In my example I do not mean change of HA as an explicit procedure specified
> separately. One confirmation to that is that single HA for all interfaces is
> included and valid option. Based on the HA -> MN exchange, the MN may perform
> interface selection procedure and may choose another interface for some
> flow(s). In multiple HA case it will result of the rules update MN -> HA to
> the HA which is relevant for the new interface chosen for flows. Please
> notice, There is nothing about HA change, only about interface selection.

=> Yes but I still think you're talking about something else. The interface
you're talking about seems to be associated with the HoA. This is the only
case where I can see the relevance of HA hints (not rules). The interfaces
I'm talking about and discussed in the context of flow bindings are those
associated with CoAs. There is nothing coming from the HA about its links
...etc that can have any impact on CoA selection.

> 
> 3. I do not map HA and access. It is allowed for any access provider to offer
> HA service and once this is the case it will be so. Thus an MN can have
> multiple HA configured for the use on different interfaces.

=> Good, we agree on that too.

Hesham

> => Yes of course it works but as I read this I'm guessing that you want the MN
> to change HoA. This is not the problem we're discussing in this WG.
> different HoA. This is very possible but it's not the problem being discussed
> here. It may well be something for charter discussion but it has zero impact
> on flow bindings for multiple CoAs.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 8 Jun 2009 16:12:04 +0200

=> Yes but I still think you're talking about something else. The interface you're talking about seems to be associated with the HoA. This is the only case where I can see the relevance of HA hints (not rules). The interfaces I'm talking about and discussed in the context of flow bindings are those associated with CoAs. There is nothing coming from the HA about its links ...etc that can have any impact on CoA selection.

Hesham
here I tend to agree. I actually ment interfaces with CoA, but now realized that in such configuration, where each of interfaces has it's own HA configured, it is most likely that each of interfaces will have different HoA. Once this is the case then moving a flow between those interfaces will lead to change of HoA. As we are in MIP context, I would better avoid that. In the whole discussion I mean interafces with CoA because selection of HoA and/or associated to it interface can not be based on physical characteristics of that interface.

So the valid and meaningful scenario is moving flow(s) between interfaces associated with the same HA, whether all interfaces of the MN or some of them will be configured this way does not really matter.

Fine with me. Should we finalize then? As I see it, once there is a meaningful information, which can be sent in HA -> MN direction, then MN can use it for re-evaluting policies and producing the new set of rules. Definetely not at all times new rules will be produced, they may stay unchanged, as it will be the case with many other events taking place at either side: MN or HA.

Is that correct?

Regards
Yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Monday, June 08, 2009 2:00 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

Yuri, 

On 8/06/09 6:29 PM, "Yuri Ismailov" <[email-masked]> wrote:

> Hesham, It looks like that the only point of disagreement is about 
> changing HA and mapping between HA and access.
> As it follows from group charter change of HA is in the plans of MEXT 
> WG. I assume that this is going to be a separate work item because the 
> reason specified for that is very specific and relates to deployment 
> more than to flow mobility. Do not want to speculate, about this right 
> now but the change of HA does not necessarily means change of rules.

=> Agreed.

> 
> 2. In my example I do not mean change of HA as an explicit procedure 
> specified separately. One confirmation to that is that single HA for 
> all interfaces is included and valid option. Based on the HA -> MN 
> exchange, the MN may perform interface selection procedure and may 
> choose another interface for some flow(s). In multiple HA case it will 
> result of the rules update MN -> HA to the HA which is relevant for 
> the new interface chosen for flows. Please notice, There is nothing about HA change, only about interface selection.

=> Yes but I still think you're talking about something else. The interface you're talking about seems to be associated with the HoA. This is the only case where I can see the relevance of HA hints (not rules). The interfaces I'm talking about and discussed in the context of flow bindings are those associated with CoAs. There is nothing coming from the HA about its links ...etc that can have any impact on CoA selection.

> 
> 3. I do not map HA and access. It is allowed for any access provider 
> to offer HA service and once this is the case it will be so. Thus an 
> MN can have multiple HA configured for the use on different interfaces.

Hesham

>> a though about that and did not come up with any information which 
>> can be derived from CoA in order to choose it. An interface has at 
>> least expected characteristics, thus can be a subject of choice. Any 
> => An application would choose an interface, but of course the IP 
> stack selects the corresponding address. I'm sure there is no disagreement there.
> 
>> 
>> - Single HA for all interfaces configured in the mobile. HA can 
>> belong to any of the access providers of each of access technology used by MN.
> 
> => Ok.
> 
>> 
> This is why I wanted you to break the scenario down. We are not 
> dealing with multiple HoAs in this work item, we're dealing with 
> multiple CoAs, i.e. One HoA.
> 
>> such configuration and did not find anything strange with it, i.e. 
>> (1) it works,
> => Yes of course it works but as I read this I'm guessing that you 
> want the MN to change HoA. This is not the problem we're discussing in this WG.
>> - "Residential" HA. Assumption is that it can be either one of HA's 
>> or a single HA for all types of accesses. This is the matter of MN 
>> configuration.
>> "Residential".
> 
>> - Traffic shaping (TS) is applied to user subscription. In other 
>> words TS is applied to packets belonging to a particular subscription 
>> but not to an aggregated traffic on gateway interfaces. HA is not 
> But I want to pre-empt any suggestion that the HA will tell the MN to 
> use a different HoA. This is very possible but it's not the problem 
> being discussed here. It may well be something for charter discussion 
> but it has zero impact on flow bindings for multiple CoAs.
> 
> Hesham
> 
>> 
>> /yuri
>> 
>> 
>>> Some broadband providers (this is used in practice) have quota on 
>>> the amount of traffic sent by users. Once quota is exceeded provider 
>>> downgardes outgoing traffic from its network to 64Kbs (this figure 
>>> is the real example from real provider). Such combination of to 
>>> paths, where one is high speed, lets say 10 Mbs and another one is 
>>> 64Kbs is quite crusual to apps running on top of TCP.
>> => Yes I know the scenario but I keep saying to you that the change 
>> in upstream routing in the HA has nothing to do with CoA selection by 
>> the MN in the visited network. If anything, you want the MN to change 
>> it's HoA depending on how the switch to another upstream ISP works. 
>> It's a completely irrelevant issue to this discussion. Do you agree? 
>> If not why not? I really want to see an answer to this point.
>> 
>>  
>> 
>> 
>>> 
>>> trying to come to a conclusion on this and there is a huge 
>>> difference between transferring policies and installing flow bindings.
>>> 
>>>> access selection purposes. Once it was decided to make it as part 
>>>> of MIP protocol, I'm fine with that. Do not have any idea to 
>>>> discuss this, while personally consider that the work on rules 
>>>> transfer can very well fit into the MEXT group but as a separate 
>>>> work item, but this is not the case now, so good enough the way it is.
>>>> talking about, is not usefull. What can I say more? I can put you 
>>>> on my position and start asking questions instead of answering. So, 
>>>> why it is not usefull?
>>> 
>>> Because if you agree with my previous explanations then we don't 
>>> need to discuss it further. If you disagree you certainly didn't 
>>> tell me why. You have the charge of proof because you want to change 
>>> the way MIP works currently, that's all I'm trying to say.
>>> 
>>> Hesham
>>> 
>>>> 
>>>> /yuri
>>>> 
>>>> 
>>>>> Which information is that I wrote in my previous emails. Back to 
>>>>> my examples (not all, do not want to repeat myself). If HA will 
>>>>> have changed traffic shaping parameters on one of the incoming or 
>>>> essentially proved that when you suggested that the MN can accept 
>>>> or reject them. So, let's not call them rules. The more direct word 
>>>> for what you want to send is policies
>>>> 
>>>> 2. You didn't provide a valid scenario that we can discuss as to 
>>>> why it's needed or how it could work. I've asked numerous questions 
>>>> in each email that were not answered (with the exception of the 
>>>> last email). It's not possible to progress the discussion without 
>>>> answering each others'
>>>>> Please tell us specifically what is missing. You're changing 
>>>>> points on me all the time now.
>>>>>>> benefit:-)) in such case will need standardization. 
>>>>>>> Communication of this information to HA does not (I consider this as a benefit).
>>>>>> => You seem to think that there is a relationship between 
>>>>>> upstream routing and CoA selection. That's not the case at all. 
>>>>>> These are two different addresses from two different networks.
>>>>>> 
>>>>>> Hesham
>>>>>> 
>>>>>>> 
>>>>>>> /yuri
>>>>>>> 
>>>>>>>> Speaking about benefits, everybody who knows the area is 
>>>>>>>> capable of turning things up side down. I assume it is 
>>>>>>>> subjective standpoint of considering things as benefits or 
>>>>>>>> disadvantages and all is about to agree or disagree.
>>>>>>> 
>>>>>>> more) information is available to the MN. Therefore, if you 
>>>>>>> think there are additional benefits to doing this in the HA then 
>>>>>>> you need to tell us.
>>>>>>> 
>>>>>>> need to justify it. I can't see any justifications because 
>>>>>>> you're not answering my questions on your scenarios. So, count 
>>>>>>> me out on the reverse direction :).
>>>>>>> 
>>>>>>> 
>>>>>>> For
>>>>>>> So far no one has mentioned the advantages of doing things in 
>>>>>>> the reverse direction.
>>>>>>>> more problems than it solves. BTW, if you're talking about 
>>>>>>>> hints then we're no longer talking about installing bindings in 
>>>>>>>> the MN. This is a different topic. MIP doesn't transfer hints, 
>>>>>>>> it pretty much sends "orders"
>>>>>>>> from one end to another.
>>>>>>>> 
>>>>>>>> I'm still confused about the _benefits_ you see here. Or are 
>>>>>>>> you assuming that the MN can't know those hints without the 
>>>>>>>> HA's involvement? But if you're assuming that, then how can it 
>>>>>>>> reject the hints? This whole proposal makes no sense to me at 
>>>>>>>> all. Not to mention the complexity you implicitly assume in 
>>>>>>>>> can generate new rules and send them as hint to MN. Back 
>>>>>>>>> again, MN has four
>>>>>>>>> options:
>>>>>>>>> 
>>>>>>>>>> to think about those not from MN point of view but rather 
>>>>>>>>>> from the HA service provider.
>>>>>>>>>> 
>>>>>>>>>> /yuri
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> The difference between policy and rules is not only a 
>>>>>>>>>>>> matter of conversion. A policy, is a static, or 
>>>>>>>>>>>> quasi-static, set of guidance for the MN (e.g use access 
>>>>>>>>>>>> network X for application type
>>>>>>>>>>>> quality) with a shorter period of variation. So, IMHO, 
>>>>>>>>>>>> there is no requirement for updating policy on a short 
>>>>>>>>>>>> period and out-of-band mechanism can be used (e.g. IEEE 
>>>>>>>>>>>> 802.21 in push mode,...).
>>>>>>>>>>> 
>>>>>>>>>>> Fully agree!

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 00:29:22 +1000

On 9/06/09 12:12 AM, "Yuri Ismailov" <[email-masked]> wrote:

> case where I can see the relevance of HA hints (not rules). The interfaces I'm
> talking about and discussed in the context of flow bindings are those
> here I tend to agree. I actually ment interfaces with CoA, but now realized
> that in such configuration, where each of interfaces has it's own HA
> configured, it is most likely that each of interfaces will have different HoA.
> Once this is the case then moving a flow between those interfaces will lead to
> change of HoA. As we are in MIP context, I would better avoid that. In the
> whole discussion I mean interafces with CoA because selection of HoA and/or
> associated to it interface can not be based on physical characteristics of
> that interface.

=> Sounds fine to me.

> 
> So the valid and meaningful scenario is moving flow(s) between interfaces
> associated with the same HA, whether all interfaces of the MN or some of them
> will be configured this way does not really matter.
> 
> Fine with me. Should we finalize then? As I see it, once there is a meaningful
> information, which can be sent in HA -> MN direction, then MN can use it for
> re-evaluting policies and producing the new set of rules. Definetely not at
> all times new rules will be produced, they may stay unchanged, as it will be
> the case with many other events taking place at either side: MN or HA.
> 
> Is that correct?

=> So now that we agree that we are only talking about CoAs then I don't see
any meaningful information coming from the HA. Hints about upstream routing
changes ...etc are relevant to HoA selection (even if the HoA is not tied to
a physical interface it doesn't matter). This is an interesting problem to
discuss but I want to be clear on its context. So to summarise my opinion:
HA-> MN hints (not rules) may be relevant for intial HoA selection for
certain connections. The types of hints and how to formulate this in a
global manner can lead to interesting work (although it's a complex
problem). However, this information is not in anyway relevant to
CoA/physical interface selection on the MN.

Hesham

> case where I can see the relevance of HA hints (not rules). The interfaces I'm
> talking about and discussed in the context of flow bindings are those

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 09:07:20 +0200

Hesham, below is my attempt to understand what the following means (not an easy task though)

> => So now that we agree that we are only talking about CoAs then I don't see any meaningful information coming from the HA. Hints about upstream
> routing changes ...etc are relevant to HoA selection (even if the HoA is not tied to a physical interface it doesn't matter). This is an 
> interesting problem to discuss but I want to be clear on its context. So to summarise my opinion:
> certain connections. The types of hints and how to formulate this in a global manner can lead to interesting work (although it's a complex 
> problem). However, this information is not in anyway relevant to CoA/physical interface selection on the MN.

First, is that we have agreed already that we are talking about interfaces. Yes, we are talking about interfaces configured with CoA. Interfaces configured with HoA does not give any information about characteristices of interfaces configured with CoA, thus choosing HoA or HA can not provide any meaningful information about access characteristics. Thus it is not clear at all where from comes idea about relevance to HA selection.
In all my examples (e.g. the latest one about broadband operators) it does not matter which HA (HoA) is used. All what matters is which access MN uses and if there was traffic shaping policy applied to that access by an access provider. We have agreed that MN can not know about the later. HA can.

Second, is that we are talking about sending rules from HA to MN. I call these rules hints, because and only because in my view MN should have rights to ignore the rules from HA. Both transportwise and contentwise, we are still talking about rules. At the moment I do not see any specific need for specific types of hints.

Information about the fact that up/down link from/to HA for a particular interface was downgraded is very relevant for MN because based on this information MN can select another interface for some of its flows and make correspondent move. If this is not the case then what is the objactive of interfaces selection? If better choice of interface for applications is not an objective then why bother about flow mobility at all?

Regards
Yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Monday, June 08, 2009 4:29 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

On 9/06/09 12:12 AM, "Yuri Ismailov" <[email-masked]> wrote:

>  
> => Yes but I still think you're talking about something else. The 
> interface you're talking about seems to be associated with the HoA. 
> This is the only case where I can see the relevance of HA hints (not 
> rules). The interfaces I'm talking about and discussed in the context 
> of flow bindings are those associated with CoAs. There is nothing 
> coming from the HA about its links ...etc that can have any impact on CoA selection.
> 
> Hesham
> here I tend to agree. I actually ment interfaces with CoA, but now 
> realized that in such configuration, where each of interfaces has it's 
> own HA configured, it is most likely that each of interfaces will have different HoA.
> Once this is the case then moving a flow between those interfaces will 
> lead to change of HoA. As we are in MIP context, I would better avoid 
> that. In the whole discussion I mean interafces with CoA because 
> selection of HoA and/or associated to it interface can not be based on 
> physical characteristics of that interface.

=> Sounds fine to me.

> 
> So the valid and meaningful scenario is moving flow(s) between 
> interfaces associated with the same HA, whether all interfaces of the 
> MN or some of them will be configured this way does not really matter.
> 
> Fine with me. Should we finalize then? As I see it, once there is a 
> meaningful information, which can be sent in HA -> MN direction, then 
> MN can use it for re-evaluting policies and producing the new set of 
> rules. Definetely not at all times new rules will be produced, they 
> may stay unchanged, as it will be the case with many other events taking place at either side: MN or HA.
> 
> Is that correct?

=> So now that we agree that we are only talking about CoAs then I don't see any meaningful information coming from the HA. Hints about upstream routing changes ...etc are relevant to HoA selection (even if the HoA is not tied to a physical interface it doesn't matter). This is an interesting problem to discuss but I want to be clear on its context. So to summarise my opinion:
HA-> MN hints (not rules) may be relevant for intial HoA selection for
certain connections. The types of hints and how to formulate this in a global manner can lead to interesting work (although it's a complex problem). However, this information is not in anyway relevant to CoA/physical interface selection on the MN.

Hesham

>> WG. I assume that this is going to be a separate work item because 
>> the reason specified for that is very specific and relates to 
>> deployment more than to flow mobility. Do not want to speculate, 
>> about this right now but the change of HA does not necessarily means change of rules.
>> choose another interface for some flow(s). In multiple HA case it 
>> will result of the rules update MN -> HA to the HA which is relevant 
>> for the new interface chosen for flows. Please notice, There is 
>> nothing about HA change, only about interface selection.
> 
> => Yes but I still think you're talking about something else. The 
> interface you're talking about seems to be associated with the HoA. 
> This is the only case where I can see the relevance of HA hints (not 
> rules). The interfaces I'm talking about and discussed in the context 
> of flow bindings are those associated with CoAs. There is nothing 
> coming from the HA about its links ...etc that can have any impact on CoA selection.
> 
>> 
>>> First is that I assume that we have simulteneous multiaccess in 
>>> mind, i.e. MN has more than one interface to choose from for its 
>>> flows. If this is not the case then I will stop the discussion. This 
>>> assumption is based on the fact that we are (I hope at least) discussing flow mobility.
>> 
>> => Sure.
>> 
>>> 
>>> Secondly, I consider that MN chooses an interface but not CoA. I 
>>> gave a though about that and did not come up with any information 
>>> which can be derived from CoA in order to choose it. An interface 
>>> has at least expected characteristics, thus can be a subject of 
>>> choice. Any clarification about that would be appreciated.
>>> - One HA per access or set of accesses, which is subset of all 
>>> access techologies presented or potentially may be presented 
>>> (detached
>>> devices) in MN.
>> 
>>> extensions. (3) Configuration is performed per interface and does 
>>> not introduce any ambiguities. (4) it is natural for access provider 
>>> to offer HA service.
>> 
>>> words TS is applied to packets belonging to a particular 
>>> subscription but not to an aggregated traffic on gateway interfaces. 
>>> HA is not necessary (however, nothing prevents from that) a gateway 
>>> where TS is applied.
>>> 
>>> 
>>>> the amount of traffic sent by users. Once quota is exceeded 
>>>> provider downgardes outgoing traffic from its network to 64Kbs 
>>>> (this figure is the real example from real provider). Such 
>>>> combination of to paths, where one is high speed, lets say 10 Mbs 
>>>> and another one is 64Kbs is quite crusual to apps running on top of TCP.
>>> in upstream routing in the HA has nothing to do with CoA selection 
>>> by the MN in the visited network. If anything, you want the MN to 
>>> change it's HoA depending on how the switch to another upstream ISP works.
>>>> That means that MN will choose its interfaces based on its 
>>>> knowledge about 10Mbs link capabilities.
>>> 
>>>> significant to make a better decision about choice of interfaces 
>>>> for its flows.
>>> Just write down step by step what will happen and include messages. 
>>> I don't see how this can possibly be relevant to the MN.
>>> 
>>> Hesham
>>> 
>>> Hesham
>>> 
>>>> 
>>>> /yuri
>>>> 
>>>> 
>>>>> Niether rules nor polices are specific to MIP. As I wrote those 
>>>>> can be exchanged between hosts without any MIP implementation, 
>>>>> just for access selection purposes. Once it was decided to make it 
>>>>> as part of MIP protocol, I'm fine with that. Do not have any idea 
>>>>> to discuss this, while personally consider that the work on rules 
>>>>> on my position and start asking questions instead of answering. 
>>>>> So, why it is not usefull?
>>>> 
>>>> tell me why. You have the charge of proof because you want to 
>>>> change the way MIP works currently, that's all I'm trying to say.
>>>> 
>>>> Hesham
>>>> 
>>>>> 
>>>>> /yuri
>>>>> 
>>>>> 
>>>>> to the MN's knowledge on e2e basis. Once we have "standpoints" 
>>>>> then we're getting outside the technical realm. The reason I don't 
>>>>> think it's useful is that this information cannot be used by the 
>>>>> MN to select a CoA. I've already stated that before and you seemed 
>>>>> to agree so I don't know why you repeat this as a reason for the 
>>>>> HA to install filters in the MN. Let me say it
>>>>>> possibility to provide more information to the MN, thus make MN 
>>>>>> to get to better decision about interface selection for its flows.
>>>>> or reject them. So, let's not call them rules. The more direct 
>>>>> word for what you want to send is policies
>>>>> 
>>>>> why it's needed or how it could work. I've asked numerous 
>>>>> questions in each email that were not answered (with the exception 
>>>>> of the last email). It's not possible to progress the discussion 
>>>>> without answering each others'
>>>>> reject those rules then the whole exercise is pointless. You 
>>>>> really want to send policies not rules. I can imagine those 
>>>>> policies being one of the inputs that the MN uses to make a 
>>>>> decision. I still fail to see how anything happening on the HA's 
>>>>> upstream interfaces/ISP link can possibly influence the MN's decision for CoA selection.
>>>>>>> opinion do have impact on the characteristics and this is 
>>>>>>> exactly the information missing in the MN when selecting interface.
>>>>>> 
>>>>>>> Another thing is that MN will notice something e2e if and only 
>>>>>>> if such support is implemented in the MN.
>>>>>> 
>>>>>> => Of course, so what?
>>>>>> 
>>>>>>>> provider, which may vary with the time of day. Changing 
>>>>>>>> backbone provider can make quite big difference for 
>>>>>>>> commnication between HA (if HA service is provided by the same access provider) and CN(s).
>>>>>>> The other issue is related to cost for certain times of day. 
>>>>>>> This is a routing issue in the HA and has nothing to do with 
>>>>>>> which interface the MN selects. The selected CoA has zero impact 
>>>>>>> on the HA's upstream selection. Completely irrelevant actually.
>>>>>>> issues are completely orthogonal. Selecting CoA1 or CoA2 has 
>>>>>>> zero impact on the HA's upstream route.
>>>>>>> 
>>>>>>>> 
>>>>>>>> because you didn't send any. What you sent were actions that 
>>>>>>>> can be done by the HA and I responded by saying that the same 
>>>>>>>> (or
>>>>>>>> think there are additional benefits to doing this in the HA 
>>>>>>>> then you need to tell us.
>>>>>>>> 
>>>>>>>>> => What's the event? A change in those conditions? The MN 
>>>>>>>>> knows the conditions of the e2e path as well as or better than the HA.
>>>>>>>>> => Preferences change to what?? How does it know if such 
>>>>>>>>> change works for the MN at all? This is way too vague to be 
>>>>>>>>> able to discuss tradeoffs.
>>>>>>>>> 
>>>>>>>>> change affects each MN/CN combination and it's "hint" can 
>>>>>>>>> cause more problems than it solves. BTW, if you're talking 
>>>>>>>>> about hints then we're no longer talking about installing 
>>>>>>>>> bindings in the MN. This is a different topic. MIP doesn't 
>>>>>>>>> On 3/06/09 5:23 PM, "Yuri Ismailov" 
>>>>>>>>>> The benefit will be obviously that the new rules (if 
>>>>>>>>>> accepted) may llead to a better overall communication characteristics.
>>>>>>>>>> 
>>>>>>>>>> /yuri
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> => I'm trying to understand what you mean above. These are 
>>>>>>>>>> all scenarios, the question is: What is the benefit for the 
>>>>>>>>>> HA to transfer rules? The HA will not know the path between 
>>>>>>>>>> the MN and CN more than either node does. So I don't 
>>>>>>>>>>> Pretty much sure that there are more examples and I 
>>>>>>>>>>> encourage to think about those not from MN point of view but 
>>>>>>>>>>> rather from the HA service provider.
>>>>>>>>>>> 
>>>>>>>>>>> /yuri
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 17:38:21 +1000

On 9/06/09 5:07 PM, "Yuri Ismailov" <[email-masked]> wrote:

>> any meaningful information coming from the HA. Hints about upstream
>> routing changes ...etc are relevant to HoA selection (even if the HoA is not
>> tied to a physical interface it doesn't matter). This is an
>> certain connections. The types of hints and how to formulate this in a global
>> manner can lead to interesting work (although it's a complex
> First, is that we have agreed already that we are talking about interfaces.
> Yes, we are talking about interfaces configured with CoA. Interfaces
> configured with HoA does not give any information about characteristices of
> interfaces configured with CoA, thus choosing HoA or HA can not provide any
> meaningful information about access characteristics. Thus it is not clear at
> all where from comes idea about relevance to HA selection.

=> The hints that you were suggesting that the HA sends are only relevant to
HoA selection. Do you agree?

> In all my examples (e.g. the latest one about broadband operators) it does not
> matter which HA (HoA) is used. All what matters is which access MN uses and if
> there was traffic shaping policy applied to that access by an access provider.
> We have agreed that MN can not know about the later. HA can.

=> No! You were talking about traffic shaping by the HA or its upstream ISP.
What do you mean by "provider" above? Where is the traffic being impacted?

> 
> Second, is that we are talking about sending rules from HA to MN. I call these
> rules hints, because and only because in my view MN should have rights to
> ignore the rules from HA. Both transportwise and contentwise, we are still
> talking about rules. At the moment I do not see any specific need for specific
> types of hints.

=> If we're talking about CoA selection I don't see any relevance to those
hints. The only way you can show there is relevance is by providing an
example. The example you provided had no relevance to CoA selection. I don't
understand why we need to go back two emails again. If you still think your
scenario had relevance to CoA selection then please respond to my earlier
response to your scenario.

> 
> Information about the fact that up/down link from/to HA for a particular
> interface was downgraded is very relevant for MN because based on this
> information MN can select another interface for some of its flows and make
> correspondent move.
=> Are you saying the MN will notify the HA everytime I do this:
Ifdown eth1: ifup eth1

Why on earth would you do that?

 If this is not the case then what is the objactive of
> interfaces selection? If better choice of interface for applications is not an
> objective then why bother about flow mobility at all?

=> I don't understand what you're saying Yuri. Please respond to my earlier
email which responded to your scenario. I can't see how you still think that
the HA can influence CoA selection.

Hesham

> changes ...etc are relevant to HoA selection (even if the HoA is not tied to a
> physical interface it doesn't matter). This is an interesting problem to
> certain connections. The types of hints and how to formulate this in a global
> manner can lead to interesting work (although it's a complex problem).
> However, this information is not in anyway relevant to CoA/physical interface
> selection on the MN.
> 
> Hesham
> 
> 
>> 
>> Regards
>> Yuri
>> 
>> 
>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 10:21:48 +0200

Hesham,
See inline (have you read what I wrote before answering?)

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 9:38 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

On 9/06/09 5:07 PM, "Yuri Ismailov" <[email-masked]> wrote:

>> => So now that we agree that we are only talking about CoAs then I 
>> don't see any meaningful information coming from the HA. Hints about 
>> upstream routing changes ...etc are relevant to HoA selection (even 
>> if the HoA is not tied to a physical interface it doesn't matter). 
>> This is an interesting problem to discuss but I want to be clear on 
>> its context. So to summarise my opinion:
>> HA-> MN hints (not rules) may be relevant for intial HoA selection 
>> HA-> for
>> certain connections. The types of hints and how to formulate this in 
>> a global manner can lead to interesting work (although it's a complex 
> configured with HoA does not give any information about 
> characteristices of interfaces configured with CoA, thus choosing HoA 
> or HA can not provide any meaningful information about access 
> characteristics. Thus it is not clear at all where from comes idea about relevance to HA selection.

=> The hints that you were suggesting that the HA sends are only relevant to HoA selection. Do you agree?
No, I explained above why. HoA selection is meaningless in general because does not provide any usable information for selection of interfaces.

> In all my examples (e.g. the latest one about broadband operators) it 
> does not matter which HA (HoA) is used. All what matters is which 
> access MN uses and if there was traffic shaping policy applied to that access by an access provider.

=> No! You were talking about traffic shaping by the HA or its upstream ISP.
What do you mean by "provider" above? Where is the traffic being impacted?
I'm not aware of any HA installed by any of access providers at the moment (any information about that would be highly appreciated). Traffic shaping, on the other hand, is applied in reality by some access providers, which have a quota on the amount of traffic sent within a period of time, typically over a month.
By provider I mean any provider who offers connectctivity to global Internet. A provider can offer such connectivity over single access technology or multiple different access technologies

> 
> Second, is that we are talking about sending rules from HA to MN. I 
> call these rules hints, because and only because in my view MN should 
> have rights to ignore the rules from HA. Both transportwise and 
> contentwise, we are still talking about rules. At the moment I do not 
> see any specific need for specific types of hints.

=> If we're talking about CoA selection I don't see any relevance to those hints. The only way you can show there is relevance is by providing an example. The example you provided had no relevance to CoA selection. I don't understand why we need to go back two emails again. If you still think your scenario had relevance to CoA selection then please respond to my earlier response to your scenario.

Here I call you to read my emails as well. I explained that CoA selection is the result of interface selection. We are talking about selecting interfaces based on their characteristics for particular flows. Information about downgrading the link performance is relevant to the communication charachteristics of flows sent through that interface.

> 
> Information about the fact that up/down link from/to HA for a 
> particular interface was downgraded is very relevant for MN because 
> based on this information MN can select another interface for some of 
> its flows and make correspondent move.

Why on earth would you do that?
If you had flows running on eth1 before you have performed "ifdown eth1" and you want this flows to continue, you apperantly should move flows to another interface. If the current rule set in the MN changes, then the rule set in the HA has to be synchronized with what MN has generated due to "ifdown eth1" event.

> interfaces selection? If better choice of interface for applications 
> is not an objective then why bother about flow mobility at all?

=> I don't understand what you're saying Yuri. Please respond to my earlier email which responded to your scenario. I can't see how you still think that the HA can influence CoA selection.

The HA is sending the rules where particlar flow(s) are suggested to move to another interface.

/yuri
Hesham

>> realized that in such configuration, where each of interfaces has 
>> it's own HA configured, it is most likely that each of interfaces 
>> will have different HoA.
>> Once this is the case then moving a flow between those interfaces 
>> will lead to change of HoA. As we are in MIP context, I would better 
>> avoid that. In the whole discussion I mean interafces with CoA 
>> because selection of HoA and/or associated to it interface can not be 
>> based on physical characteristics of that interface.
> 
> => Sounds fine to me.
> 
>> 
> => So now that we agree that we are only talking about CoAs then I 
> don't see any meaningful information coming from the HA. Hints about 
> upstream routing changes ...etc are relevant to HoA selection (even if 
> the HoA is not tied to a physical interface it doesn't matter). This 
> is an interesting problem to discuss but I want to be clear on its context. So to summarise my opinion:
> global manner can lead to interesting work (although it's a complex problem).
> However, this information is not in anyway relevant to CoA/physical 
> interface selection on the MN.
> 
> Hesham
> 
> 
>> 
>> Regards
>> Yuri
>> 
>> 
>> 
>>> As it follows from group charter change of HA is in the plans of 
>>> MEXT WG. I assume that this is going to be a separate work item 
>>> because the reason specified for that is very specific and relates 
>>> to deployment more than to flow mobility. Do not want to speculate, 
>>>> flows. If this is not the case then I will stop the discussion. 
>>>> This assumption is based on the fact that we are (I hope at least) 
>>>> discussing flow mobility.
>>> 
>>> => Sure.
>>> 
>>>> 
>>>> not introduce any ambiguities. (4) it is natural for access 
>>>> provider to offer HA service.
>>> 
>>> because they're not tied to access. Let's just say there are 
>>> multiple Has and not associate it with an access.
>>> 
>>>> 
>>> But I want to pre-empt any suggestion that the HA will tell the MN 
>>> to use a different HoA. This is very possible but it's not the 
>>> problem being discussed here. It may well be something for charter 
>>> discussion but it has zero impact on flow bindings for multiple CoAs.
>>> 
>>> Hesham
>>> 
>>>> 
>>>> /yuri
>>>> 
>>>> 
>>>>>> just for access selection purposes. Once it was decided to make 
>>>>>> it as part of MIP protocol, I'm fine with that. Do not have any 
>>>>>> idea to discuss this, while personally consider that the work on 
>>>>>> rules transfer can very well fit into the MEXT group but as a 
>>>>>> separate work item, but this is not the case now, so good enough the way it is.
>>>>>>> have changed traffic shaping parameters on one of the incoming 
>>>>>>> or outgoing interfaces, this will be important information for MN to know.
>>>>>>> We have agreed already that whether this information important 
>>>>>>> or not, benfitial or not is a matter of standpoint.
>>>>>> 
>>>>>> That's why I asked you on every point you raised and compared 
>>>>>> this to the MN's knowledge on e2e basis. Once we have "standpoints"
>>>>>> then we're getting outside the technical realm. The reason I 
>>>>>> don't think it's useful is that this information cannot be used 
>>>>>> by the MN to select a CoA. I've already stated that before and 
>>>>>> you seemed to agree so I don't know why you repeat this as a 
>>>>>> reason for the HA to install filters in the MN. Let me say it
>>>>>> questions in each email that were not answered (with the 
>>>>>> exception of the last email). It's not possible to progress the 
>>>>>> discussion without answering each others'
>>>>>>> => No, that's not the point really. The point is that there is 
>>>>>>> no relationship between CoA/interface selection on the MN and 
>>>>>>> the upstream ISP for the home network.
>>>>>>> 
>>>>>>>> characteristics of the communication. Routes (up/down)link in 
>>>>>>>> my opinion do have impact on the characteristics and this is 
>>>>>>>> support to operating system, which makes its (support) 
>>>>>>>> existence questionable, or to applications, which is even more questionable.
>>>>>>> 
>>>>>>> support to the MN's OS but not questionable to add the support 
>>>>>>> to the HA's OS, which will not lead to the same reliability as 
>>>>>>> if it were done in the MN. It doesn't make sense to me.
>>>>>>> 
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> commnication between HA (if HA service is provided by the same 
>>>>>>>>> access
>>>>>>>>> provider) and CN(s).
>>>>>>>> First, changing network conditions are best known e2e. So the 
>>>>>>>> MN will know that anyway based on the traffic running between 
>>>>>>>> it and the CN.
>>>>>>>> which interface the MN selects. The selected CoA has zero 
>>>>>>>> impact on the HA's upstream selection. Completely irrelevant actually.
>>>>>>>>> - I presume that in RO mode this is similar to HA mode, and 
>>>>>>>>> I'm in when it comes to send rules in reverse direction between CN and MN.
>>>>>>>>> The sources causing changes may include but not limited to, 
>>>>>>>>> are user, network managemnt events, application generated events, etc.
>>>>>>>>> 
>>>>>>>>> On 3/06/09 7:33 PM, "Yuri Ismailov" 
>>>>>>>>> => No you didn't. You wrote about things that can be done. 
>>>>>>>>> Many things can be done by many entities, the question is why 
>>>>>>>>> the HA and not the MN.
>>>>>>>>> 
>>>>>>>>>> One important thing in the discussion, although mentioned, 
>>>>>>>>>> but forgotten later is that by making rules distribution one 
>>>>>>>>>> way only, we do create limitation for benefits, or potential 
>>>>>>>>>>>> - Access provider (any access, not necessarily wireless) 
>>>>>>>>>>>> who offeres HA services preferences change
>>>>>>>>>> 
>>>>>>>>>> => First, by assuming that the MN can reject the "hint" as 
>>>>>>>>>> you call it you invalidate the whole argument for the HA to 
>>>>>>>>>> install rules.
>>>>>>>>>> HA's involvement? But if you're assuming that, then how can 
>>>>>>>>>> it reject the hints? This whole proposal makes no sense to me 
>>>>>>>>>> at all. Not to mention the complexity you implicitly assume 
>>>>>>>>>> in order to generate those, hopefully reliable, hints.
>>>>>>>>>> 
>>>>>>>>>> Hesham
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> known by HA but not MN. If HA acts upon events, given that 
>>>>>>>>>>> it knows somewhat more about MN, not only IP addresses, it 
>>>>>>>>>>> (HA) can generate new rules and send them as hint to MN. 
>>>>>>>>>>> Back again, MN has four
>>>>>>>>>>> options:
>>>>>>>>>>> 
>>>>>>>>>>>> encourage to think about those not from MN point of view 
>>>>>>>>>>>> but rather from the HA service provider.
>>>>>>>>>>>> 
>>>>>>>>>>>> /yuri
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>  It is just rules TRANSFER which is the matter of MIP. So 
>>>>>>>>>>>> where is the logic when saying that MN to HA rules transfer 
>>>>>>>>>>>> is a practical engineering and HA to MN is an academic 
>>>>>>>>>>>> interest?
>>>>>>>>>>>> 
>>>>>>>>>>>> advocating the other direction) need to come up with 
>>>>>>>>>>>> reasons for doing things this way. This way we can think

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 18:32:44 +1000

> No, I explained above why. HoA selection is meaningless in general because
> does not provide any usable information for selection of interfaces.

=> Sigh..Yuri, we agree on that. But then you still think that HA hints
somehow magically give information to the MN about its interfaces so it
knows better what to choose.

> I'm not aware of any HA installed by any of access providers at the moment
> (any information about that would be highly appreciated). Traffic shaping, on
> the other hand, is applied in reality by some access providers, which have a
> quota on the amount of traffic sent within a period of time, typically over a
> month.
> By provider I mean any provider who offers connectctivity to global Internet.
> A provider can offer such connectivity over single access technology or
> multiple different access technologies

=> So where is the traffic shaping done in your scenario? Before you said it
was upstream from the HA, which led me to the answers I gave earlier. Now
where is it done in this discussion? FWIW, if it's done by the HA or
upstream from the HA it's completely irrelevant to this discussion.

> Here I call you to read my emails as well. I explained that CoA selection is
> the result of interface selection. We are talking about selecting interfaces
> based on their characteristics for particular flows. Information about
> downgrading the link performance is relevant to the communication
> charachteristics of flows sent through that interface.

=> Relevant to who??? It's relevant to the MN and is known by the MN. How
does the HA fit in here?

> If you had flows running on eth1 before you have performed "ifdown eth1" and
> you want this flows to continue, you apperantly should move flows to another
> interface. If the current rule set in the MN changes, then the rule set in the
> HA has to be synchronized with what MN has generated due to "ifdown eth1"
> event.

=> Yes we do that with the BU, I still don't see what the HA->MN does here.

> The HA is sending the rules where particlar flow(s) are suggested to move to

=> Well, as I said, at least a dozen times,  there is zero information
available to the HA to make this suggestion. So unless you provide concrete
information to transfer I really can't see any point in this proposal.

Hesham

>>>>>>>>>>> I can't parse those events you refer to. I'l answer both emails 
>>>>>>>>>>> here.
>>>>>>>>>>> First the events you refer to:
>>>>>>>>>>>

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 11:09:07 +0200

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 10:33 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of flowbindings

HA knows which CoA (according to installed bindings) have got changes in communication due to link downgrade.
By receiving rules from HA, MN will know which interfaces are affected.
Changes may take place either on a local access (within access provider network) or towards backbone provider, or in the worst case both.
I explained earlier that in either case MN does not know about that. In the best case MN may know about local changes
if and only if correspondent support is implemented in the MN. This can be done either as application or operating system support.
Both are questionable to expect.
IP and any of its sublayers do not have this information.

That's what you've said. I repeateadly wrote about what I have written above without any objection and/or attention.
The traffic shaping is applied by an access provider.

It is relevant to MN for interface selction. Why it is not known by MN see above

=> Yes we do that with the BU, I still don't see what the HA->MN does here.
Does this imply that rule sets may be out of sync between MN and HA?

You re saying, and I'm providing examples and scenarious. The point is to have meaning in interface selection.

/yuri

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 19:19:57 +1000

> communication due to link downgrade.

=> Which link?? HA knows nothing about the visited link.

> By receiving rules from HA, MN will know which interfaces are affected.

=> Really? It doesn't know that the link it is connected to is affected
until the HA tells it? Does that really make sense to you? If it does then
we have to just leave it here because I can't start from this point in the
discussion.

> Changes may take place either on a local access (within access provider
> network) or towards backbone provider, or in the worst case both.
> I explained earlier that in either case MN does not know about that. In the
> best case MN may know about local changes

=> There no "may" above. It knows about the local access. And I also
explained more times than I can rememeber that changes in the HA's provider
links have no bearing on CoA selection. And when you say changes in the
"backbone" you seem to assume that an HA has a picture of Internet topology
and knows which changes in which part of the backbone affect a specific MN
interface. That makes no sense at all but that's the only way that such a
change would affect a CoA selection.

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 11:46:39 +0200

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 11:20 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

=> Which link?? HA knows nothing about the visited link.
I assume that traffic from/to MN (apart from RO mode) passes through HA,
which is offered by my home network access provider, whichever is chosen
if multiple exist. HA knows whether downgrade policies were applied by
the access provider either inside access network (less probable, but
possible) or towards backbone provider. This has nothing to do with
visited link.

=> Really? It doesn't know that the link it is connected to is affected
until the HA tells it? Does that really make sense to you? If it does
then we have to just leave it here because I can't start from this point
in the discussion.

HA does not tell about the link MN connected to. As you said HA can not
know about visited link. It knows about Home network and connection
towards backbone. This is where policies are applied (e.g. traffic
shaping)

> I explained earlier that in either case MN does not know about that. 
> In the best case MN may know about local changes

=> There no "may" above. It knows about the local access.

MN knows only about EXPECTED characteristics of its interfaces, not
about policies applied by access provider in the access network.

And I also explained more times than I can rememeber that changes in the
HA's provider links have no bearing on CoA selection. And when you say
changes in the "backbone" you seem to assume that an HA has a picture of
Internet topology and knows which changes in which part of the backbone
affect a specific MN interface. That makes no sense at all but that's
the only way that such a change would affect a CoA selection.

Do not revert my words. I said that HA knows whether, for example,
traffic shaping is applied. This does not have to do with changes in the
backbone or knowledge of the Internet topology. This information sets
the upper limit on what an interface can expect. Let's say traffic
shaping will give you 64Kbs and what MN knows is that it is connected
over 54Mbs WLAN and MN will keep going with already running flows and
select interfaces for new flows with 54Mbs in mind.

Yuri

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 20:08:12 +1000

> possible) or towards backbone provider. This has nothing to do with

=> Good, so you're not talking about the visited link. Let's underscore this
fact. Now, what happens in those other links "near" the HA (upstream or
downstrean) has nothing to do with CoA selection.

> towards backbone. This is where policies are applied (e.g. traffic

=> Great. So see my answer above.

> about policies applied by access provider in the access network.

=> It knows the outcome, it doesn't care how a link became congested. Why
are you assuming the HA knows about those policies done by the visited
provider anyway? Are you assuming the MN and HA are always under the same
admin domain? I hope not.

> the upper limit on what an interface can expect.

=> No no no. It sets the upper limit for THAT HoA being used. You're not
responding to my point which is stated in every email. There is no
consequences on the CoA/interface selection by the change in the HA's
upstream or HA interfaces policies, traffic shaping, or whatever you think
will happen.
 
 Let's say traffic
> select interfaces for new flows with 54Mbs in mind.

=> Of course, and if it changes CoA why would that 64k link suddenly become
54M?? It's the same HA and the same HoA. On the other hand, if that shaping
was associated with one HA or one home prefix on that HA then changing the
HoA can make a difference.

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 12:52:25 +0200

Hesham,
Re-read my assumptions please. In my example and in reality traffic
shaping is applied per subscription, if MN connected with two different
interfaces does not mean that the quota exceeded on both. One may exceed
but not the other. I wrote that this has nothing to do with aggregated
traffic.
The rest see inline.

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 12:08 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

> I assume that traffic from/to MN (apart from RO mode) passes through 
> HA, which is offered by my home network access provider, whichever is 
> chosen if multiple exist. HA knows whether downgrade policies were 
> applied by the access provider either inside access network (less 
> probable, but

=> Good, so you're not talking about the visited link. Let's underscore
this fact. Now, what happens in those other links "near" the HA
(upstream or
downstrean) has nothing to do with CoA selection.

This is exactly what matters, because this is place where policies are
applied.

> => Really? It doesn't know that the link it is connected to is 
> affected until the HA tells it? Does that really make sense to you? If

> it does then we have to just leave it here because I can't start from 
> this point in the discussion.
> 
> HA does not tell about the link MN connected to. As you said HA can 
> not know about visited link. It knows about Home network and 
> connection towards backbone. This is where policies are applied (e.g. 
> traffic
> shaping)

=> Great. So see my answer above.
I've seen and can only confirm that that policies are applied at home
network, where HA can and will know about that.

> about policies applied by access provider in the access network.

=> It knows the outcome, it doesn't care how a link became congested.
Why are you assuming the HA knows about those policies done by the
visited provider anyway? Are you assuming the MN and HA are always under
the same admin domain? I hope not.
Never said that policies are applied by visited provider, but this is an
interesting point, probably does not have much to do with interface
selection as long as this knowledge become available.

> 
> And I also explained more times than I can rememeber that changes in 
> the HA's provider links have no bearing on CoA selection. And when you

> say changes in the "backbone" you seem to assume that an HA has a 
> picture of Internet topology and knows which changes in which part of 
> the backbone affect a specific MN interface. That makes no sense at 
> all but that's the only way that such a change would affect a CoA
selection.
> traffic shaping is applied. This does not have to do with changes in 
> the backbone or knowledge of the Internet topology. This information 
> sets the upper limit on what an interface can expect.

=> No no no. It sets the upper limit for THAT HoA being used. You're not
responding to my point which is stated in every email. There is no
consequences on the CoA/interface selection by the change in the HA's
upstream or HA interfaces policies, traffic shaping, or whatever you
think will happen.
 
 Let's say traffic
> select interfaces for new flows with 54Mbs in mind.

=> Of course, and if it changes CoA why would that 64k link suddenly
become 54M?? It's the same HA and the same HoA. On the other hand, if
that shaping was associated with one HA or one home prefix on that HA
then changing the HoA can make a difference.

As wrote, above and earlier traffic shaping is not performed for
aggregated traffic but on subscription basis.

/yuri

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 21:01:09 +1000

> but not the other. I wrote that this has nothing to do with aggregated

=> How can you apply traffic shaping based on a CoA? This a flawed way of
doing it. Not to mention, there is no practical or charging reason for doing
that. If it's per subscriber as you say then it's done per HoA not per CoA.
In your scenario traffic shaping would fail miserably if the MN didn't use
flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would your
traffic shaping function do then?

> This is exactly what matters, because this is place where policies are

=> What exactly matters? I have no idea what you mean above.

> network, where HA can and will know about that.

=> Yuri, what you're saying above is factually wrong. No traffic shaping in
the home network can rely on a CoA. It's just wrong, not a matter of
opinion. It's almost like you don't know that the CoA doesn't even appear
upstream of the HA. And if the HA is doing the shaping it will fail as I
described above.

> aggregated traffic but on subscription basis.

=> Now I'm convinced that you don't understand that subscription != CoA.
This is a fact. 

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 14:02:02 +0200

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 1:01 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

> shaping is applied per subscription, if MN connected with two 
> different interfaces does not mean that the quota exceeded on both. 
> One may exceed but not the other. I wrote that this has nothing to do 
> with aggregated traffic.

=> How can you apply traffic shaping based on a CoA? This a flawed way
of doing it. Not to mention, there is no practical or charging reason
for doing that. If it's per subscriber as you say then it's done per HoA
not per CoA.
In your scenario traffic shaping would fail miserably if the MN didn't
use flow binding. I.e., if a 3775 MN sends a BU with CoA1, what would
your traffic shaping function do then?

That means that Home access provider and consequently HA do not know
which mobile and on which interface sends traffic.
At the moment (no HA deployed) an access provider has means for that,
not necessarily IP addresses identify that.
When MN sends binding update, it's not only IP addresses involved. There
is an authentication procedure as well. This is why actual CoA does not
matter for knowing which subscription is that. When it comes to mobile
networks then this knowledge is explicit because obtained through the
mobile and made known for home operator.

> => Good, so you're not talking about the visited link. Let's 
> underscore this fact. Now, what happens in those other links "near" 
> the HA (upstream or

Because HA knows about applied policies and can inform MN about that in
the form of rules.

> network, where HA can and will know about that.

=> Yuri, what you're saying above is factually wrong. No traffic shaping
in the home network can rely on a CoA. It's just wrong, not a matter of
opinion. It's almost like you don't know that the CoA doesn't even
appear upstream of the HA. And if the HA is doing the shaping it will
fail as I described above.
True, traffic shaping relies on subscription.

=> Now I'm convinced that you don't understand that subscription != CoA.
I'm convinced that subscription != CoA, which may change more often than
one changes subscription

This is a fact.
????? The fact is something obvious, as you see in my answer the fact is
the opposite.

Yuri

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 22:16:03 +1000

> which mobile and on which interface sends traffic.

=> Bingo, therefore your shaping scenario falls apart, which is a good thing
because it's broken. A solid per-subscriber shaping scenario in the home
network would use the HoA to identify packets of course.

> mobile and made known for home operator.

=> You keep contradicting yourself. Previously you said that traffic shaping
affects the CoA selection, which implies that you're doing policies based on
the CoA. Now you're saying that you're not. There is only two options here
CoA or HoA, which is it?
The authentication you're referring to is based on the HoA. CoA means
nothing to the HA. 

> True, traffic shaping relies on subscription.

=> Good, so there is no way the CoA can be involved in such policies.
Therefore your example of informing the MN to choose a different CoA based
on traffic shaping in the home network is wrong.

> I'm convinced that subscription != CoA, which may change more often than

=> Great then you should not be proposing that the HA sends hints for the MN
to change it's CoA based on traffic shaping which takes place on the basis
of subscription. If you want to map a subscription to an IP packet you would
map it to the HoA. There is nothing else in the packet that can be mapped
for this purpose.

> ????? The fact is something obvious, as you see in my answer the fact is

=> It's pretty obvious that you can't use a CoA for what you're doing. It's
also a FACT that the authentication you refer to at the beginning is based
on the HoA. 

I think if you want to progress this further you should go through the
exercise of writing down a draft with what you're proposing. I'm pretty sure
you will find some fundamental holes in the scenario you mentioned.

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 14:52:42 +0200

Hesham,
Please read what I'm writing, otherwise it gets really funny you answer
your own questions
See below

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 2:16 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

> for doing that. If it's per subscriber as you say then it's done per 
> HoA not per CoA.

> which mobile and on which interface sends traffic.

=> Bingo, therefore your shaping scenario falls apart, which is a good
thing because it's broken. A solid per-subscriber shaping scenario in
the home network would use the HoA to identify packets of course.

I hope you simply missunderstood the above:-), which says that the
meaning follows from what you wrote, but not from what I'm saying.

> When MN sends binding update, it's not only IP addresses involved. 
> There is an authentication procedure as well. This is why actual CoA 
> does not matter for knowing which subscription is that. When it comes 
> to mobile networks then this knowledge is explicit because obtained 
> through the mobile and made known for home operator.

=> You keep contradicting yourself. Previously you said that traffic
shaping affects the CoA selection, which implies that you're doing
policies based on the CoA. Now you're saying that you're not. There is
only two options here CoA or HoA, which is it?
The authentication you're referring to is based on the HoA. CoA means
nothing to the HA.

Please refer to my text where I said that traffic shaping affects CoA.
During all discussion I stress the fact that it is subscription related.
Another thing is that interfaces in the middle of discussion, not any
CoA.

> => Yuri, what you're saying above is factually wrong. No traffic 
> shaping in the home network can rely on a CoA. It's just wrong, not a 
> matter of opinion. It's almost like you don't know that the CoA 
> doesn't even appear upstream of the HA. And if the HA is doing the 
> shaping it will fail as I described above.

=> Good, so there is no way the CoA can be involved in such policies.
Therefore your example of informing the MN to choose a different CoA
based on traffic shaping in the home network is wrong.

And again we are discussing choice of interfaces, not CoA.

> I'm convinced that subscription != CoA, which may change more often 
> than one changes subscription

=> Great then you should not be proposing that the HA sends hints for
the MN to change it's CoA based on traffic shaping which takes place on
the basis of subscription. If you want to map a subscription to an IP
packet you would map it to the HoA. There is nothing else in the packet
that can be mapped for this purpose.

Since we are in the context of MEXT group and discussing flow mobility
and related transport of rules, CoA will be sent to MN (if CoA is a part
of rules representation), but not for change of CoA, for re-evaluation
of rules and eventually possible another interface selection

> ????? The fact is something obvious, as you see in my answer the fact 
> is the opposite.

=> It's pretty obvious that you can't use a CoA for what you're doing.
It's also a FACT that the authentication you refer to at the beginning
is based on the HoA.

According to my knowledge authentication starts before any address is
configured on interfaces, not HoA either.

I think if you want to progress this further you should go through the
exercise of writing down a draft with what you're proposing. I'm pretty
sure you will find some fundamental holes in the scenario you mentioned.

How is that possible to find holes in the fact of transporting rules
from HA to MN. All you found so far is that this is useless information,
but I explained why not.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 23:04:47 +1000

> meaning follows from what you wrote, but not from what I'm saying.

=> I know the meaning of what I wrote, it's not a debating society, I'm
trying to explain to you that what I wrote means your traffic shaping
assumptions are wrong.

> Please refer to my text where I said that traffic shaping affects CoA.

=> It doesn't. Write it down on a piece of paper and trace the packets
yourself. It's a broken scenario.

> During all discussion I stress the fact that it is subscription related.

=> And you also said that you understand that subscription and CoA are not
related. So...

> And again we are discussing choice of interfaces, not CoA.

=> Oh come on, it's impossible to have a discussion like this. Interface
maps to CoA, there is no interface in the packet on the wire.

> of rules and eventually possible another interface selection

=> Ok please write your scenario, which is the basis for your motives in a
draft. This makes no sense to me.

> configured on interfaces, not HoA either.

=> Wrong. If the HoA is allocated dynamically it is done during IKE
authentication, if it's static it is allocated before the authentication.
See RFCs 3775/6 and 4977.

> from HA to MN. All you found so far is that this is useless information,

=> Ok if you think it's correct please put this scenario in your draft.

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 15:28:27 +0200

Hesham, 
Once in the discussion we were at the point when you requested examples,
scenarious, etc
I provided all what is needed. Now we are back to the same point.

I'm not a part of debating society, rather engineering and my discussion
is not directed to you personally. Sorry but I've got an impression that
you took it this way. I'm discussing support for flow mobility, nothing
else.

There is another point I've been thinking about - route optimization
mode.
Here I probably need some help in understanding whether I see it the
right way or not.
I consider the following situation: two mobile IP hosts communicate to
each other in RO mode, and both have support for multi-access and flow
mobility and both equipped with multiple interfaces.
As far as I understand there is a need to send routing rules between
them. It could be one, another or both exchanging the rules.
If this is the case, does that mean that an MN must be capable of
receiving rules. If so, then it does not matter where the rules come
from. It looks like that the need for that functionality is anyway
there.
Is that correct understanding?

/yuri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 3:05 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

> During all discussion I stress the fact that it is subscription
related.

=> And you also said that you understand that subscription and CoA are
not related. So...

> the MN to change it's CoA based on traffic shaping which takes place 
> on the basis of subscription. If you want to map a subscription to an 
> IP packet you would map it to the HoA. There is nothing else in the 
> packet that can be mapped for this purpose.
> 

> and related transport of rules, CoA will be sent to MN (if CoA is a 
> part of rules representation), but not for change of CoA, for 
> re-evaluation of rules and eventually possible another interface 
> selection

=> Ok please write your scenario, which is the basis for your motives in
a draft. This makes no sense to me.

=> Wrong. If the HoA is allocated dynamically it is done during IKE
authentication, if it's static it is allocated before the
authentication.
See RFCs 3775/6 and 4977.

> exercise of writing down a draft with what you're proposing. I'm 
> pretty sure you will find some fundamental holes in the scenario you
mentioned.
> from HA to MN. All you found so far is that this is useless 
> information, but I explained why not.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 09 Jun 2009 23:34:16 +1000

> you took it this way. I'm discussing support for flow mobility, nothing

=> No problem, we'll solve it on the chess board :). I just find it
frustrating that we can't get to a common ground (which to me seems clear)
but anyway, best to write a draft.

> Is that correct understanding?

=> Well, so far we haven't seen the need for the CN to send any rules to the
MN (for the MN's selections). I certainly think the MN should send the rules
to the CN as described in the flow bindings draft but not the reverse
direction. 

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 9 Jun 2009 16:15:41 +0200

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 3:34 PM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

> Hesham,
> Once in the discussion we were at the point when you requested 
> examples, scenarious, etc I provided all what is needed. Now we are 
> back to the same point.
> 
> I'm not a part of debating society, rather engineering and my 
> discussion is not directed to you personally. Sorry but I've got an 
> impression that you took it this way. I'm discussing support for flow 
> mobility, nothing else.

=> No problem, we'll solve it on the chess board :). I just find it
frustrating that we can't get to a common ground (which to me seems
clear) but anyway, best to write a draft.

Chessboard is a good thing to go for:-) Here I'm always in. Writing
draft with one message (+ ack) specified, looks a bit too ambitious,
does it?
It's not frustrating for me it is rather suprizing that we cannot agree
on, in my view, such obvious things.

> Is that correct understanding?

=> Well, so far we haven't seen the need for the CN to send any rules to
the MN (for the MN's selections). I certainly think the MN should send
the rules to the CN as described in the flow bindings draft but not the
reverse direction.

I specifically mentioned both MNs in the above scenario. Things get more
interesting whith multimedia applications in mind, where an application
often acts as a client and a server. In such case both mobiles will have
to initiate communication at some point and serve as MN and CN
simulteneously. (Confused by myself: is there any difference between CN
and MN? Any host, even stationary computer may change address and it is
allowed to have MIP with extentions on any host. In the case of multiple
interfaces, even without MIP, the selection procedure should be
performed anyway. So, do not really know how to distinguish between MN
and CN)
If such scenario is out of scope so far, then I hope  at least that it
is not out of scope in general. Together with the previous scenario
another draft will make sense, because it will cover significant part of
the work. If MEXT is not the right place for that, then as I said "one
message draft" does not make sense to me, I think that small changes can
be made to existing documents.

Any ideas about that?

Yuri

Hesham

> => I know the meaning of what I wrote, it's not a debating society, 
> I'm trying to explain to you that what I wrote means your traffic 
> shaping assumptions are wrong.
> 

> => Oh come on, it's impossible to have a discussion like this. 
> Interface maps to CoA, there is no interface in the packet on the
wire.

> => Ok please write your scenario, which is the basis for your motives 
> in a draft. This makes no sense to me.
>

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 10 Jun 2009 16:35:31 +1000

> draft with one message (+ ack) specified, looks a bit too ambitious,

=> I don't think the message is the issue. The message part is always easy
it's the justification for this message with concrete scenarios, triggers
that lead to sending the message ....etc.

> be made to existing documents.

=> The difference between MN and CN is a functional one and describes the
context of communication in MIP. A CN receives a BU and an MN sends the BU.
So being a CN or MN is not a permanent attribute.

I'm not sure I understand what you want to do from the CN to the MN but I
think if you write a draft this will become clearer (I hope).

Hesham

Hesham

---

From: "Yuri Ismailov" <[email-masked]>
Date: Wed, 10 Jun 2009 09:30:54 +0200

Yep,
Scenarious are pretty much clear, so should not be a problem either.

/yuri 

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2009 8:36 AM
To: Yuri Ismailov; Nicolas Montavont; [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Important considerations for directionality of
flowbindings

> draft with one message (+ ack) specified, looks a bit too ambitious, 

=> I don't think the message is the issue. The message part is always
easy it's the justification for this message with concrete scenarios,
triggers that lead to sending the message ....etc.

> => Well, so far we haven't seen the need for the CN to send any rules 
> to the MN (for the MN's selections). I certainly think the MN should 
> send the rules to the CN as described in the flow bindings draft but 
> not the reverse direction.
> 
> I specifically mentioned both MNs in the above scenario. Things get 
> more interesting whith multimedia applications in mind, where an 
> application often acts as a client and a server. In such case both 
> mobiles will have to initiate communication at some point and serve as

> MN and CN simulteneously. (Confused by myself: is there any difference

> between CN and MN? Any host, even stationary computer may change 
> address and it is allowed to have MIP with extentions on any host. In 
> the case of multiple interfaces, even without MIP, the selection 
> procedure should be performed anyway. So, do not really know how to 
> distinguish between MN and CN) If such scenario is out of scope so 
> far, then I hope  at least that it is not out of scope in general. 
> Together with the previous scenario another draft will make sense, 
> because it will cover significant part of the work. If MEXT is not the

> right place for that, then as I said "one message draft" does not make

> sense to me, I think that small changes can be made to existing 
> documents.
> 
> Any ideas about that?

=> The difference between MN and CN is a functional one and describes
the context of communication in MIP. A CN receives a BU and an MN sends
the BU.
So being a CN or MN is not a permanent attribute.

I'm not sure I understand what you want to do from the CN to the MN but
I think if you write a draft this will become clearer (I hope).

Hesham

Hesham

>>>> shaping in the home network can rely on a CoA. It's just wrong, not

>>>> a

---

From: Yungui Wang <[email-masked]>
Date: Thu, 18 Jun 2009 10:59:23 +0800

Hello

There is a scenario for the HA service provider.

One MN is watching a real-time TV service from internet. For
mobile IP service, 
a video flow is created on HA. At the time, a video call is
incoming, the MN 
decides to response the call and pause the TV service.  Due to
lack of 
bandwidth he can't receive and buffer it locally. He may then ask
the HA 
buffering the TV flow un-interruptted. Thus, new action "Buffer"
may be 
needed for flow binding.

4 Buffer.  This value indicates a request to buffer all packets
      in the flow described by the option.  No BIDs are associated
with
      this Action.

Does it make sense?

B.R.
Yungui

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 18 Jun 2009 13:09:42 +1000

>       in the flow described by the option.  No BIDs are associated

=> I'm not sure about that specific scenario but I think buffering is
potentially a useful action. A couple of things we need to address in order
to introduce this action:
1. How long do you buffer? I assume this has to be explicitly said in the
BU. It could be a certain amount of time, an automatic buffer/release
mechanism ...etc. We need to know what to do with this.

2. If you're buffering for some time I assume you need a release message?

It would be helpful if you/others can help with answering these questions.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Thu, 18 Jun 2009 11:59:39 +0800

Hello

> => I'm not sure about that specific scenario but I think 
> buffering is potentially a useful action. A couple of things 
> we need to address in order to introduce this action:
> 1. How long do you buffer? I assume this has to be explicitly 
> said in the BU. It could be a certain amount of time, an 
> automatic buffer/release mechanism ...etc. We need to know 
> what to do with this.

Yeah. If supported, it is necessary to extend the Flow Identifier 
option to include some flow attributes, such as time and/or 
volume.

> 2. If you're buffering for some time I assume you need a 

There are two possible options:
1. Implicitly mode. It can be deleted when time is out, or when 
it has been completely downloaded, or the flow binding is 
de-registered, etc.
2. Explicitly mode. It needs to be explicitly deleted.

B.R.
Yungui

---

From: "Yuri Ismailov" <[email-masked]>
Date: Thu, 18 Jun 2009 10:53:04 +0200

Hi folks,

It looks like that the propsal is to extend mobility support with pure
application function.
Do not think one can discuss this seriously within this group. Can
somebody imagine that video stream buffering may become a router
function, for example? What I can understand is that buffering does not
have to have end-to-end semantics and may be performed by a proxy, but
this is an application proxy, which is application specific, thus
understand application layer protocol.

For this proposal to work, one will have to implement application layer
gateway in HA, because it (HA) has to understand what it buffers. At IP
layer packets may be disordered, for example, and the buffered content
by HA will not make any sense for later use.

Regards
Yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yungui Wang
Sent: Thursday, June 18, 2009 4:59 AM
To: 'Hesham Soliman'; [email-masked]
Subject: [MEXT] "buffer" action for flow binding

Hello

One MN is watching a real-time TV service from internet. For mobile IP
service, a video flow is created on HA. At the time, a video call is
incoming, the MN decides to response the call and pause the TV service.
Due to lack of bandwidth he can't receive and buffer it locally. He may
then ask the HA buffering the TV flow un-interruptted. Thus, new action
"Buffer"
may be
needed for flow binding.

4 Buffer.  This value indicates a request to buffer all packets
      in the flow described by the option.  No BIDs are associated with
      this Action.

Does it make sense?

B.R.
Yungui

---

From: Julien Laganier <[email-masked]>
Date: Thu, 18 Jun 2009 14:06:36 +0200

Another potential usecase for buffering would be as follows:

MN is receiving and/or sending bulk data transfer over TCP. Prior to
handover it requests HA to buffer downlink packets. After Handover it
requests HA to resume transmission of packets. In that way no TCP packets
are lost because sent at the old MN CoA, and TCP transmission rate is less
impacted or not impacted at all by the handover.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jun 2009 08:46:50 -0700 (PDT)

Folks,
  We had a draft on HA buffering, it is at:
http://tools.ietf.org/html/draft-xia-mipshop-ha-buffering-01

Regards,

Behcet

________________________________
From: Julien Laganier <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Thursday, June 18, 2009 7:06:36 AM
Subject: Re: [MEXT] "buffer" action for flow binding

MN is receiving and/or sending bulk data transfer over TCP.. Prior to handover it requests HA to buffer downlink packets. After Handover it requests HA to resume transmission of packets. In that way no TCP packets are lost because sent at the old MN CoA, and TCP transmission rate is less impacted or not impacted at all by the handover.

--julien

Hello

Does it make sense?

B.R.
Yungui

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

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 18 Jun 2009 12:15:32 -0500

I wouldn't advise trying to do too much optimization on behalf
of TCP.  It depends on the length of time to perform the
handover, but longish handovers can run near the RTO and the
data needing buffering during bulk-transfer is limited by the
ACKs already in-flight before handover due to the data segments
being clocked out by ACKs.  For shorter handovers, TCP can
handle the loss detection and recovery efficiently through the
fast retransmission/recovery and SACK procedures.  There is
also an argument some have made that TCP should be re-
initiating slow-start from its initial window after handovers
due to the fact that the path has completely changed and the
state established on the old path (cwnd, ssthresh, RTT, PMTU)
may be invalid.

Just a bit of caution and skepticism that buffering at the HA
will work exactly as intended in all cases ... even in the
best case, the buffering will cause an RTT spike.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>Julien Laganier
>Sent: Thursday, June 18, 2009 8:07 AM
>To: [email-masked]
>Cc: [email-masked]
>requests HA to resume transmission of packets. In that way no TCP
>packets are lost because sent at the old MN CoA, and TCP transmission
>rate is less impacted or not impacted at all by the handover.
>
>--julien
>
>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 18 Jun 2009 22:30:16 +0100

I second this. I am not convinced that buffering at the HA is helpful.
why would one thing that buffering in the HA will reducing buffering
requirements in the MN?
I also second other peoples' comments regarding the feasibility of
buffering application flows on a router.

In general I think this is beyond the scope of Mobile IP and MEXT and
is taking us into APP-area.

George

On Thu, Jun 18, 2009 at 6:15 PM, Eddy, Wesley M.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jun 2009 15:42:25 -0700 (PDT)

Hi Eddy,
  Thank you for your advice.
However, I would like to know if you have any experimental data, research, published papers, material to back it up. Please let us know. I know that TCP behaviour in wireless links has been studied in depth but I for one am not aware of any work on TCP and MIPv6 type of things, especially in this context.

Regards,

Behcet

----- Original Message ----
> From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
> To: Julien Laganier <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Thursday, June 18, 2009 12:15:32 PM
> >On Thu, Jun 18, 2009 at 4:59 AM, Yungui Wang wrote:
> >
> >
> >    Hello
> >

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 18 Jun 2009 20:00:52 -0500

In general, it's enough to say that transports are robust to the temporary network hiccups you throw at them, and this applies not only to TCP, but SCTP, DCCP and other protocols as well.  These all contain their own mechanisms for estimating path properties and responding to changes in the path.  Yes, there may be a small performance dip, but the connections will live on and recover.  Hopefully you aren't handing over too frequently anyways ... and measurement data shows that many/most TCP connections are quite short (only a few segments) since webpages are only a small number of kB in size, on average.  Sometimes the buffering under discussion may be helpful; we can certainly tailor experiments and simulations that show that ... we can also tailor simulations and experiments to show that it's dangerous and can cause performance degradation instead of improvement under many conditions.  IP is assumed to be a best-effort service; no need to make it needlessly clever.

Don't assume that the upper layers are so simple and fragile that they need great amounts of help in order to perform, or you break them.  There are many papers on how link-layer ARQ leading to high jitter and delay spikes injures end-to-end transport performance.  RFC 3366 describes the danger in assuming that high-persistence of the lower layers should be used in delivering TCP segments and RFC 3481 documents a set of TCP extensions and tuning parameters designed for robustness to links with handovers.

There has also been an I-D discussed in TCPM several years ago about TCP-based response to connectivity changes if they are visible to the transport and not masked/hidden by the network layer:
http://tools.ietf.org/html/draft-schuetz-tcpm-tcp-rlci-03
The references in that I-D to [SHUETZ] and [EDDY] can be found on the web and contain simulation results showing performance issues that occur when the network layer tries to hide path changes from the transport.

________________________________________
From: Behcet Sarikaya [[email-masked]]
Sent: Thursday, June 18, 2009 6:42 PM
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: [email-masked]
Subject: Re: [MEXT] "buffer" action for flow binding

Hi Eddy,

Regards,

Behcet

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 18 Jun 2009 22:21:01 +1000

Yes handover is a more likely case.

Hesham

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Jun 2009 08:04:43 -0700 (PDT)

Hi Eddy,
  You are talking about pilc work (RFC 3366, etc.). Admittedly one can show it either way.
  The point here is that not all flows are over TCP. In fact the example given was a video call which will probably be RTP flow. RTP does not control the transmission as much as TCP does. So buffering at a point like HA could be useful, this seems intuitively correct.. 
  Do you have any objection to that?

Regards,

Behcet

----- Original Message ----
> Sent: Thursday, June 18, 2009 8:00:52 PM
> Subject: RE: [MEXT] "buffer" action for flow binding
> 
> In general, it's enough to say that transports are robust to the temporary 
> network hiccups you throw at them, and this applies not only to TCP, but SCTP, 
> DCCP and other protocols as well.  These all contain their own mechanisms for 
> estimating path properties and responding to changes in the path.  Yes, there 
> may be a small performance dip, but the connections will live on and recover.  
> Hopefully you aren't handing over too frequently anyways ... and measurement 
> data shows that many/most TCP connections are quite short (only a few segments) 
> since webpages are only a small number of kB in size, on average.  Sometimes the 
> buffering under discussion may be helpful; we can certainly tailor experiments 
> and simulations that show that ... we can also tailor simulations and 
> experiments to show that it's dangerous and can cause performance degradation 
> instead of improvement under many conditions.  IP is assumed to be a best-effort 
> service; no need to make it needlessly clever.
> 
> Don't assume that the upper layers are so simple and fragile that they need 
> great amounts of help in order to perform, or you break them.  There are many 
> papers on how link-layer ARQ leading to high jitter and delay spikes injures 
> end-to-end transport performance.  RFC 3366 describes the danger in assuming 
> that high-persistence of the lower layers should be used in delivering TCP 
> segments and RFC 3481 documents a set of TCP extensions and tuning parameters 
> designed for robustness to links with handovers.
> 
> There has also been an I-D discussed in TCPM several years ago about TCP-based 
> response to connectivity changes if they are visible to the transport and not 
> masked/hidden by the network layer:
> The references in that I-D to [SHUETZ] and [EDDY] can be found on the web and 
> contain simulation results showing performance issues that occur when the 
> network layer tries to hide path changes from the transport.
> 
> 
> However, I would like to know if you have any experimental data, research, 
> published papers, material to back it up. Please let us know. I know that TCP 
> behaviour in wireless links has been studied in depth but I for one am not aware 
> of any work on TCP and MIPv6 type of things, especially in this context.
> 
> Regards,
> 
> Behcet
> 
> 
> 
> > From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
> > To: Julien Laganier ; "[email-masked]" 
> 
> > Cc: "[email-masked]"

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Fri, 19 Jun 2009 11:57:20 -0500

Yes, even for RTP it's very naive to assume that buffering in the
HA is productive, and even for RTP it can be counterproductive.
If the end host player uses short buffers to bound delay in the
application interactivity, the data you buffer in the HA will
likely be below the playback pointer by the time it arrives, and
simply be discarded.  You'll also be wasting time and bandwidth
transmitting this stale data across a possibly constrained link
only to have to tossed away by the application.  There are
certainly thresholds where HA buffering could be useful to an
A/V codec, but the time limits are quite heavily dependent on
the specific application software and its local configuration
which vary widely in the wild.  The limited potential for good
results combined with the definite possibility of bad results,
and the inherent additional complexity make this a non-starter
in my mind.

>Sent: Friday, June 19, 2009 11:05 AM
>  The point here is that not all flows are over TCP. In fact the example
>given was a video call which will probably be RTP flow. RTP does not
>control the transmission as much as TCP does. So buffering at a point
>like HA could be useful, this seems intuitively correct..
>Behalf Of

---

From: Yungui Wang <[email-masked]>
Date: Mon, 22 Jun 2009 10:03:15 +0800

Hello

Thanks for your clarification. 

My intent is an enhanced HA in which a ALG or backend server may
be 
located as Yuri said could do more things. More conveniently,
DPI-like 
technology (L3~L7) is more and more popular. I don't think it is
very 
difficult to be done. Here, what we need is a simple request from
MN. 
However, I am also not sure if the IP-layer request is
appropriate.
But, as I know, there is a similar example that a server located 
in/side of a router (even side of AN) may buffer the multicast
stream 
(a TV channel or the important frames of a channel) for fast
channel 
switch in the fixed network. While, when a user sends a IP-layer 
request (IGMP) for a new channel, the router (/server) may firstly

push the buffered channel to the user, then do further works.

B.R.
Yungui

> Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon]
> Sent: Saturday, June 20, 2009 12:57 AM
> To: Behcet Sarikaya
> Cc: [email-masked]
> Yes, even for RTP it's very naive to assume that buffering in 
> the HA is productive, and even for RTP it can be
counterproductive.
> If the end host player uses short buffers to bound delay in 
> the application interactivity, the data you buffer in the HA 
> will likely be below the playback pointer by the time it 
> arrives, and simply be discarded.  You'll also be wasting 
> time and bandwidth transmitting this stale data across a 
> possibly constrained link only to have to tossed away by the 
> application.  There are certainly thresholds where HA 
> buffering could be useful to an A/V codec, but the time 
> limits are quite heavily dependent on the specific 
> application software and its local configuration which vary 
> widely in the wild.  The limited potential for good results 
> combined with the definite possibility of bad results, and 
> the inherent additional complexity make this a non-starter in my
mind.
> >  You are talking about pilc work (RFC 3366, etc.). 
> Admittedly one can 
> >show it either way.
> >  The point here is that not all flows are over TCP. In fact
the 
> >example given was a video call which will probably be RTP flow.
RTP 
> >does not control the transmission as much as TCP does. So 
> buffering at 
> >a point like HA could be useful, this seems intuitively
correct..
> <[email-masked]>
> >> In general, it's enough to say that transports are robust to
the
> >temporary
> >> network hiccups you throw at them, and this applies not 
> only to TCP,
> >but SCTP,
> >> DCCP and other protocols as well.  These all contain their
own
> >mechanisms for
> >> estimating path properties and responding to changes in the
path.
> >Yes, there
> >> may be a small performance dip, but the connections will 
> live on and
> >recover.
> >> Hopefully you aren't handing over too frequently anyways ...
and
> >measurement
> >> data shows that many/most TCP connections are quite short 
> (only a few
> >segments)
> >> since webpages are only a small number of kB in size, on
average.
> >Sometimes the
> >> buffering under discussion may be helpful; we can certainly
tailor
> >experiments
> >> experiments to show that it's dangerous and can cause
performance
> >degradation
> >> instead of improvement under many conditions.  IP is 
> assumed to be a
> >best-effort
> >> Don't assume that the upper layers are so simple and fragile
that 
> >> they
> >need
> >> great amounts of help in order to perform, or you break 
> them.  There
> >are many
> >> papers on how link-layer ARQ leading to high jitter and 
> delay spikes
> >injures
> >> end-to-end transport performance.  RFC 3366 describes the
danger in
> >assuming
> >> that high-persistence of the lower layers should be used in 
> >> delivering
> >TCP
> >> segments and RFC 3481 documents a set of TCP extensions and
tuning
> >parameters
> >> There has also been an I-D discussed in TCPM several years 
> ago about
> >TCP-based
> >> response to connectivity changes if they are visible to 
> the transport
> >and not
> >> The references in that I-D to [SHUETZ] and [EDDY] can be 
> found on the
> >web and
> >> contain simulation results showing performance issues that 
> occur when
> >the
> >> However, I would like to know if you have any experimental
data,
> >research,
> >> published papers, material to back it up. Please let us 
> know. I know
> >that TCP
> >> behaviour in wireless links has been studied in depth but 
> I for one 
> >> am
> >not aware
> >> of any work on TCP and MIPv6 type of things, especially in
this
> >context.
> >> > I wouldn't advise trying to do too much optimization on 
> behalf of 
> >> > TCP.  It depends on the length of time to perform the 
> handover, but 
> >> > longish handovers can run near the RTO and the data needing

> >> > buffering during bulk-transfer is limited by the ACKs
already 
> >> > in-flight before handover due to the data segments being
clocked 
> >> > out by ACKs.  For shorter handovers, TCP can handle the
loss 
> >> > detection and recovery efficiently through the fast 
> >> > retransmission/recovery and SACK procedures.  There is also
an 
> >> > argument some have made that TCP should be re- initiating 
> >> > slow-start from its initial window after handovers due 
> to the fact 
> >> > that the path has completely changed and the state 
> established on 
> >> > the old path (cwnd, ssthresh, RTT, PMTU) may be invalid.
> >> >
> >> > Just a bit of caution and skepticism that buffering at 
> the HA will 
> >> > work exactly as intended in all cases ... even in the best
case, 
> >> > the buffering will cause an RTT spike.
> >> >
On
> >> > >MN is receiving and/or sending bulk data transfer over 
> TCP. Prior
> >to
> >> > >handover it requests HA to buffer downlink packets. 
> After Handover
> >it
> >> > >    bandwidth he can't receive and buffer it locally. 
> He may then
> >ask
> >> > >    the HA
> >> > >    buffering the TV flow un-interruptted. Thus, new
action
> >"Buffer"
> >> > >    may be
> >> > >    needed for flow binding.
> >> > >
> >> > >    4 Buffer.  This value indicates a request to buffer
all 
> >> > >packets

---

From: "Yuri Ismailov" <[email-masked]>
Date: Mon, 22 Jun 2009 10:48:59 +0200

Hi all,
I believe we should not mix too different things: (1) where to place functionality, and (2) which protocol to use to support this functionality.
Buffering, as a function may possibly placed in HA, but using of mobility protocol for triggering that function probably not the best choice.

/yuri

-----Original Message-----
From: Yungui Wang [mailto:[email-masked]] 
Sent: Monday, June 22, 2009 4:03 AM
To: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet Sarikaya'; Yuri Ismailov
Cc: [email-masked]
Subject: RE: [MEXT] "buffer" action for flow binding

Hello

My intent is an enhanced HA in which a ALG or backend server may be located as Yuri said could do more things. More conveniently, DPI-like technology (L3~L7) is more and more popular. I don't think it is very difficult to be done. Here, what we need is a simple request from MN. 
However, I am also not sure if the IP-layer request is appropriate.
But, as I know, there is a similar example that a server located in/side of a router (even side of AN) may buffer the multicast stream (a TV channel or the important frames of a channel) for fast channel switch in the fixed network. While, when a user sends a IP-layer request (IGMP) for a new channel, the router (/server) may firstly

B.R.
Yungui

> Of Eddy, Wesley M. (GRC-MS00)[Verizon]
> Yes, even for RTP it's very naive to assume that buffering in the HA 
> is productive, and even for RTP it can be
counterproductive.
> application interactivity, the data you buffer in the HA will likely 
> be below the playback pointer by the time it arrives, and simply be 
> discarded.  You'll also be wasting time and bandwidth transmitting 
> this stale data across a possibly constrained link only to have to 
> tossed away by the application.  There are certainly thresholds where 
> HA buffering could be useful to an A/V codec, but the time limits are 
> quite heavily dependent on the specific application software and its 
> local configuration which vary widely in the wild.  The limited 
> potential for good results combined with the definite possibility of 
> bad results, and the inherent additional complexity make this a 
> non-starter in my
mind.
the 
RTP 
correct..
the
own
path.
and
average.
tailor
performance
that 
danger in
tuning
data,
this

already 
clocked 
loss 
an 
case, 
On
action
all

---

From: Yungui Wang <[email-masked]>
Date: Tue, 23 Jun 2009 08:31:32 +0800

Hello

Well, why is the action 'Discard' allowed?
They both are affecting the flow self, not influencing CoA
selection indeed. 
If 'buffer' disallowed, nor 'Discard' does.
Thanks.

B.R.
Yungui

> From: Yuri Ismailov [mailto:[email-masked]] 
> Sent: Monday, June 22, 2009 4:49 PM
> To: [email-masked]; Eddy, Wesley M. (GRC-MS00)[Verizon]; 
> Behcet Sarikaya
> Cc: [email-masked]
> I believe we should not mix too different things: (1) where 
> to place functionality, and (2) which protocol to use to 
> support this functionality.
> Buffering, as a function may possibly placed in HA, but using 
> of mobility protocol for triggering that function probably 
> not the best choice.
> 
> /yuri
> 
> 
> My intent is an enhanced HA in which a ALG or backend server 
> may be located as Yuri said could do more things. More 
> conveniently, DPI-like technology (L3~L7) is more and more 
> popular. I don't think it is very difficult to be done. Here, 
> what we need is a simple request from MN. 
appropriate.
> But, as I know, there is a similar example that a server 
> located in/side of a router (even side of AN) may buffer the 
> multicast stream (a TV channel or the important frames of a 
> channel) for fast channel switch in the fixed network. While, 
> when a user sends a IP-layer request (IGMP) for a new 
> channel, the router (/server) may firstly
> 
> On Behalf 
the 

> > >> > >        in the flow described by the option.  No BIDs
are
> > >associated

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 23 Jun 2009 13:50:52 +0200

Yungui,

I'm entirely with you regarding 'Discard' action. I would add on top of it other specified actions as well. I do not see how these actions relate to mobility management. As you pointed out they are flow related and in my view should be handled by applications.
Moreover, specifically 'Discard' action, is quite usual firewall function but not in any way mobility support function.

And just one more time, the firewall function may be physically placed in the HA. However, why would one change firewall rules using mobility management protocol? I do not have any answer on that.

I think that the origin of the problem is binary format (really sorry for bringing it up again), where one cannot specify semantics of what can be done with flows, just flow IDs. Thus, it is necessary to have a number of options for delivering of such semantics. But not to forget about the purpose of the semnatics it should be (according to the charter) mobility management related. Using rules language would make things much more easier, just because the semantics is the part of the language description and parsing the language would produce unambiguios, correct, synchronized on both ends binding cashes.

Take again 'Discard' as an example. Semantically, one may come up with quite strange operations, which are sintactically correct: Add new flow binding and 'Discard' the flow. To avoid such things, the logic of mutual exclusiveness of various actions and options has to be introduced.
Parsing the language, on the other hand would remove both semantical and syntactical errors in operations, before producing meaningfull binding caches.

Regards
Yuri

-----Original Message-----
From: Yungui Wang [mailto:[email-masked]] 
Sent: Tuesday, June 23, 2009 2:32 AM
To: Yuri Ismailov; 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'Behcet Sarikaya'
Cc: [email-masked]
Subject: RE: [MEXT] "buffer" action for flow binding

Hello

Well, why is the action 'Discard' allowed?
They both are affecting the flow self, not influencing CoA selection indeed. 
If 'buffer' disallowed, nor 'Discard' does.
Thanks.

B.R.
Yungui

> To: [email-masked]; Eddy, Wesley M. (GRC-MS00)[Verizon]; Behcet 
> Sarikaya
> Cc: [email-masked]
> I believe we should not mix too different things: (1) where to place 
> functionality, and (2) which protocol to use to support this 
> functionality.
> Buffering, as a function may possibly placed in HA, but using of 
> mobility protocol for triggering that function probably not the best 
> choice.
> 
> /yuri
> 
> 
> My intent is an enhanced HA in which a ALG or backend server may be 
> located as Yuri said could do more things. More conveniently, DPI-like 
> technology (L3~L7) is more and more popular. I don't think it is very 
> difficult to be done. Here, what we need is a simple request from MN.
appropriate.
> in/side of a router (even side of AN) may buffer the multicast stream 
> (a TV channel or the important frames of a
> channel) for fast channel switch in the fixed network. While, when a 
> user sends a IP-layer request (IGMP) for a new channel, the router 
> (/server) may firstly
> 
the 

are