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

[Yungui Wang <w52006 at huawei.com>]

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

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

> > 
> > 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.
> 
> => How does the HA know this information? Any pointers to 
> specs or current
> 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

> 
> Hesham
> 
> > 
> > Therefore, personally support two-direction flow binding.
> > 
> > B.R.
> > Yungui
> >  
> > 
> >> -----Original Message-----
> >> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On
> >> Behalf Of Hesham Soliman
> >> Sent: Thursday, May 28, 2009 6: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
> >> 
> > 
> 
>