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

From: "Yuri Ismailov" <[email-masked]>
Date: Fri, 29 May 2009 09:35:09 +0200

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. 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

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 30 May 2009 16:14:34 +1000

It's sad that this is the only thing you can understand from my email.
Tragic actually....

> 
> 
> On 29/05/09 12:36 AM, "Behcet Sarikaya" <[email-masked]> wrote:
> 
>> 
>> Hi Hesham,
>>   To your long message, I have a very short reply: You're saying two things:
>> - you don't want to change your draft,
>> - you admit that you forgot to raise the issue below when monami6 discussed
>> the charter and clearly decided to include HA to MN direction.
>> 
>> Cheers,
>> 
>> Behcet
>> 
>> 
>> 
>> ----- Original Message ----
>> From: Hesham Soliman <[email-masked]>
>> To: mext <[email-masked]>
>> Sent: Thursday, May 28, 2009 5:06:55 AM
>> 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
>> 
>> 
>> 
>> 
>> 

------ End of Forwarded Message