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

["Yuri Ismailov" <yuri.ismailov at ericsson.com>]

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

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



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