Re: [MEXT] Important considerations for directionality of flow bindings

[Hesham Soliman <hesham at elevatemobile.com>]

On 31/05/09 2:17 PM, "Yungui Wang" <w52006 at huawei.com> wrote:

> Hello
> 
> In my understanding, Chairman has initiated the discussion
> whether the requirement is included in the charter, not how about
> technical implementation. Below argumentation you mentioned
> seems using current implementation (e.g. CoA not tie to access
> tech) to reject the pending requirement. I don't think it is exactly
> senseful. That's, only if the requirement is supported, below
> implementation issues 1/2/3 can be further considered. (It may
> be not difficult to be solved, I think.)

=> Yes we're discussing the feasibility of such requirement. I.e., what is
the implication of such requirement. If you think it's not difficult to
solve then I would encourage you to provide arguments for why it's not
difficult to solve or write a draft for example.

> 
> However, the requirement may be useful for flow handover, e.g.
> MN/HA has binding two flows to two BID (CoA) respectively.
> Based on policies or link overload indication, etc, HA may initiate
> flow binding to handoff one of MN's flows from one CoA to another.

=> How does the HA know this information? Any pointers to specs or current
deployments would be useful.

Hesham

> 
> Therefore, personally support two-direction flow binding.
> 
> B.R.
> Yungui
>  
> 
>> -----Original Message-----
>> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On
>> Behalf Of Hesham Soliman
>> Sent: Thursday, May 28, 2009 6: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
>> MEXT at ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>> 
>