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

From: Hesham Soliman <[email-masked]>
Date: Thu, 28 May 2009 20:06:55 +1000

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 28 May 2009 07:36:00 -0700 (PDT)

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, 

Here are my reasons:

Hesham

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Yuri Ismailov" <[email-masked]>
Date: Thu, 28 May 2009 15:19:24 +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
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: [email-masked] [mailto:[email-masked]] 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 28 May 2009 08:53:28 -0700 (PDT)

Absolutely.

Network control has been a way of life in mobility starting with RFC 3543 which was first written in 2001.

When it comes to flows, there will be no network control?

Give me break!

Regards,

Behcet

----- Original Message ----
From: Yuri Ismailov <[email-masked]>
To: Hesham Soliman <[email-masked]>; mext <[email-masked]>
Sent: Thursday, May 28, 2009 8:19:24 AM
Subject: Re: [MEXT] Important considerations for directionality of flow bindings

Hesham,

Yuri

-----Original Message-----

Hi all, 

Here are my reasons:

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 29 May 2009 15:08:47 +1000

> 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
> However, one does not exclude another.

=> Sure.

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

> initiating new BU, where MN is not supposed to send any traffic before

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

> 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

---

From: Yungui Wang <[email-masked]>
Date: Sun, 31 May 2009 12:17:14 +0800

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

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.

Therefore, personally support two-direction flow binding.

B.R.
Yungui

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hesham Soliman
> Sent: Thursday, May 28, 2009 6:07 PM
> To: mext

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 31 May 2009 15:03:13 +1000

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

> 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

---

From: Yungui Wang <[email-masked]>
Date: Sun, 31 May 2009 15:09:17 +0800

> difficult to solve or write a draft for example.

After the requirement is accepted, I'd like to do those works if needed.

> deployments would be useful.

How HA knows this information is out of scope of MIP.
For your information, the polcies information could be PCC rules 
downloaded from PCRF which is defined in 3GPP TS23.203 
and TS23.402, etc. 
For example, network-initiated dynamic PCC pushed to 
PDN-GW (HA) for traffic flow aggregate may lead to above 
case - flow handover happens.

B.R.
Yungui

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 31 May 2009 18:21:37 +1000

> After the requirement is accepted, I'd like to do those works if needed.

=> Part of accepting requirements is to understand what makes sense. This is
a normal discussion for a requirements process. It's not like we're placing
requirements on something new that we've never worked with before, this is a
well-established technology and is well understood.

> How HA knows this information is out of scope of MIP.

=> Huh? If you want the HA to do something in MIP you need to show an
implementer how to do it.

> downloaded from PCRF which is defined in 3GPP TS23.203

=> I've already said many times that this is not about policies.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Sun, 31 May 2009 17:52:29 +0800

Hello

> well-established technology and is well understood.

I think, what I decide to buy a watch is that I want to check time, 
not the watch is hard/easily made.

However, I am attemping to solve your implementation issues 
1/2/3 respectively mentioned before.
1. during MCoA registeration, 'access technology type' mobility 
option which could be re-used from PMIP or re-defined is binding 
to each BID for flow binding.  Then, HA can locally translate 
"forward port 80 traffic on a wifi link"(a policy) into "forward port 
80 traffic using CoA 3ffe::1" (a rule).
2. HA just tracks BID (tieing to ATT) here, not CoA. Then, your 
issue2 doesn't exist.
3. MN, of course, should be able to initiate flow handover due to 
link/interface down or something else. I don't think it is an issue.

> => I've already said many times that this is not about policies.

In context of discussion, I thought you asked information is 'policies or
link 
overload indication, etc' of my previous mail. Maybe I misunderstood you. 
May I know what's the information which you stated in your question 'How 
does the HA know this information'?

B.R.
Yungui

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 31 May 2009 20:21:22 +1000

> 80 traffic using CoA 3ffe::1" (a rule).

=> But I already mentioned that option in my email and showed why it's not
enough due to changes in radio and due to the fact that "port 80" tells you
nothing about the application running on that port other than it's using
HTTP.

> 2. HA just tracks BID (tieing to ATT) here, not CoA. Then, your
=> Yes it does exist see above and my earlier email.

> link/interface down or something else. I don't think it is an issue.

=> Then it's completely redundant for the HA to send such rules. Again see
my email. 

> does the HA know this information'?

=> The HA knows nothing about the app running on any port, knows nothing
about changes in the link, nothing about user preferences, nothing about
interface failure....etc. That's the information.

Hesham