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

[Hesham Soliman <hesham at elevatemobile.com>]

> 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
> need any standardization. In other words, I'm superior of my HA.
> This situation is not unthinkable,

=> Oh I completely agree with you that it's a not unthinkable and can/should
be possible right now with MIP. I actually think this scenario proves my
point. I have three questions for you though:

1. Do you really think you can make your HA know everything I mentioned on
my email even if it's just for your own MNs (presumably you'll have more
than one MN, you're a researcher :) ) ? I mean, even if it's just for your
own household, we're still talking about potentially a dozen MNs. Will you
define all apps in the HA that any of your MNs might use and all the
requirements for those apps? Let's say one of your children installs a new
app on their PC, do they then have to call you at work and tell you about
this app and all it's properties? I'm intentionally being simplistic to
highlight the issues here. Let's say you (Yuri) are ok with doing all that,
how many people do you think can do that?

2. What did doing everything in step 1 actually do for you? I mean, what's
the benefit here? You already administer all your MNs and you could run the
same policies on all of them.

3. Having the HA under your own administration doesn't mean you will know
what's happening at the other end. My help desk incident involved me picking
up the phone and calling someone. I think we want things to be done
automatically. 


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

=> Sure.

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

=> But the MN knows those conditions at least as well as the HA. So what
benefits can the HA add? I'm still talking about your deployment scenario
above. 
Not to mention that the HA can be completely bypassed with RO.

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

=> So what's the point of having the HA send those rules in the first place
if ultimately the MN chooses to do what it sees fit? I still don't see the
benefits here. Can you list some of the benefits that you see for sending
rules (not policies) from the HA to the MN?

> 
> BTW, what is the numerical representation of "rough consensus"? I assume
> is when majority is for, is it so?

=> Of course it involves majority but I don't know what numbers the chairs
have in mind. Best to ask them if it's 70, 80 90 ...etc

Hesham

> 
> Yuri
> 
> 
> 
> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] 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
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext