[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Important considerations for directionality of flow bindings
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 <hesham at elevatemobile.com>
To: mext <mext at ietf.org>
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
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext