Re: [MEXT] the future of the MEXT working group

[Hesham Soliman <[e-mail]>]

Hi Jari, All,

Some comments inline.

>    And a follow-up on the charter. I'm describing a couple of different
>    takes on what the new charter could be. Comments and alternative
>    proposals are welcome. This is what the current charter says about
>    DMM:
>    
>    
>  The working group will also work on
>      operational considerations on
>        setting up Mobile IPv6 networks so that traffic is distributed
>        in an optimal way, for instance by using existing protocol
>      mechanisms
>        to select the closest home agents for new clients.
>      
>        Oct 2011 - Submit I-D 'Operational considerations for
>      distributed use of Mobile IPv6' for publication as Informational.
>    
>
>    
>    Which is admittedly a bit short, but is also very concrete and
>    achievable, if we work on it. I got another proposal from Hui Deng
>    that extended this a bit, including going beyond mere operational
>    considerations.

=> I think that's clear, with the exception of some possible aesthetic
improvements.

>    
>    
>In the past decade a fair number of mobility
>      protocols have been standardized. Although the protocols differ in
>      terms of functions and associated message format, we can identify
>      a few key common features:
>      presence of a centralized mobility anchor providing global
>      reachability and an always-on experience
>      extensions to optimize handover performance while users roam
>      across wireless cells
>      extensions to enable the use of heterogeneous wireless interfaces
>      for multi-mode terminals (e.g. cellular phones)
>      The presence of the centralized mobility anchor allows a mobile
>      device to be reachable when it is not connected to its home
>      domain. The anchor, among other tasks, ensures forwarding of
>      packets destined to or sent from the mobile device. As such, most
>      of the deployed architectures today have a small number of
>      centralized anchors managing the traffic of millions of mobile
>      subscribers.


=> This really sounds like a lot of ambiguity, can't we just say that
[flow mobility], [HMIPv6] and [FMIPv6] were introduced to optimise
mobility? This paragraph can be written in two sentences.


>      
>      To optimize handovers for mobile users, the base protocols have
>      been extended to efficiently handle packet forwarding between the
>      previous and new points of attachment. These extensions are
>      necessary when applications impose stringent requirements in terms
>      of delay. 

=> I don't think this style is needed for a charter. The last sentence is
incorrect anyway. TCP suffers from mobility disruptions.

>Notions of localization and distribution of local agents
>      have been introduced to reduce signalling overhead. Unfortunately
>      today we witness difficulties in getting such protocols deployed,
>      often leading to sub-optimal choices.

=> What is the point of this part? Seems like it has no effect on the work
unless we have a consensus on why it is difficult to introduce those
protocols. Bear in mind that IPv6 is still not widely used and MIPv4 was
hardly used outside one mobile network in the US. Isn't the real reason
for not deploying IP mobility that the 3G networks were designed to not
need IP mobility? If so, then one can't come to a conclusion that those
protocols like FMIP, HMIP, flow mobility..etc are too difficult to deploy
because they were not seriously tried and that's because they were not
seriously needed. I.e. in the 3G architecture, nothing is "broken" without
them. 

>Moreover, all the
>      availability of multi-mode devices and the possibility to use
>      several network interfaces simultaneously have motivated the
>      development of more new protocol extensions.
>      
>      Mobile users are, more than ever, consuming Internet content, and
>      impose new requirements on mobile core networks for data traffic
>      delivery. When this traffic demand exceeds available capacity,
>      service providers need to implement new strategies such as
>      selective traffic offload (e.g. 3GPP work items LIPA/SIPTO)
>      through alternative access networks (e.g. WLAN). Moreover, the
>      localization of content providers closer to the Mobile/Fixed
>      Internet Service Providers network requires taking into account
>      local Content Delivery Networks (CDNs) while providing mobility
>      services.  
>      
>      As long as demand exceeds capacity, both offloading and CDN
>      techniques could benefit from the development of more flat mobile
>      architectures (i.e., fewer levels of routing hierarchy introduced
>      into the data path by the mobility management system). This view
>      is reinforced by the shift in users¹ traffic behaviour, aimed at
>      increasing direct communications among peers in the same
>      geographical area. The development of truly flat mobile
>      architectures would result in anchoring the traffic closer to
>      point of attachment of the user and overcoming the suboptimal
>      routing issues of a centralized mobility scheme.
>      
>      While deploying today¹s mobile networks, service providers face
>      new challenges. More often than not, mobile devices remain
>      attached to the same point of attachment, in which case specific
>      IP mobility management support is not required for applications
>      that launch and complete while connected to the same point of
>      attachment. However, the mobility support has been designed to be
>      always on and to maintain the context for each mobile subscriber
>      as long as they are connected to the network. This can result in a
>      waste of resources and ever-increasing costs for the service
>      provider. Infrequent mobility and intelligence of many
>      applications suggest that mobility can be provided dynamically,
>      thus simplifying the context maintained in the different nodes of
>      the mobile network.

=> So reading this last paragraph tells me that Mobile IPv6 is actually
not needed (regardless of whether one agrees with that or not). So why
would any work item take place in MEXT? The overheads described are not
quantified or proven to be substantial for an operator. What are the
overheads? Storing a binding? If the mobile node doesn't move, there is no
signalling so what's the cost?
  
>      
>      The proposed charter will address two complementary aspects of
>      mobility management procedures: the distribution of mobility
>      anchors to achieve a more flat design and the dynamic
>      activation/deactivation of mobility protocol support as an enabler
>      to distributed mobility management.

=> But this sounds like introducing more complexity while maintaining the
same overheads? MEaning, if you're still keeping anchors, then you still
have the overheads you complain about, but then you add complexity by
trying to over-optimise the turning on and off of mobility management.
Sounds like extra work for no benefit.

>The former has the goal of
>      positioning mobility anchors (HA, LMA) closer to the user;

=> Yes but that was only one of the complaints about the current mobility
management. The other was overheads of anchors. So having the anchor
closer doesn't solve that problem.

>      ideally, these mobility anchors could be collocated with the first
>      hop router. The latter, facilitated by the distribution of
>      mobility anchors, aims at identifying when mobility must be
>      activated and identifying sessions that do not impose mobility
>      management -- thus reducing the amount of state information to be
>      maintained in the various mobility anchors of the mobile network.
>      The key idea is that dynamic mobility management relaxes some
>      constraints while also repositioning mobility anchors; it avoids
>      the establishment of non optimal tunnels between two anchors
>      topologically distant.
>      
>      Considering the above, the working group will:
>      
>      Define the problem statement and associated requirements for
>      distributed mobility management. This work aims at defining the
>      problem space and identifies the key functional requirements.
>      
>      Produce a gap analysis mapping the above requirements against
>      existing solutions.
>      
>      Give best practices for the deployment of existing mobility
>      protocols in a distributed mobility management and describe
>      limitations of each such approach.
>      
>      Describe extensions, if needed, to current mobility protocols for
>      their application in distributed mobility architectures
> 
>
>    
>    Comments?

=> Yes a few comments:
- As a stylistic matter, the text should just say what it needs done
quickly and concisely.
- Substantively, the text lists two key problems: 1) being able to
allocate anchors close to the MN so that content caches can be allocated
based on the MN's location and 2) Anchors introduce overheads.
Seems to me that 2) makes 1) irrelevant because if you remove the anchors
then you no longer need to worry about efficient allocation.

1) is something that someone who read the protocol and is a good systems
engineer can fix by making sure that the anchors are allocated and
advertised correctly to the MN (using HMIP as an example here). I can see
that people might want to have different mechanisms for allocating anchors
but then just say that clearly and describe why.

I think if the work item is:
- Develop best practices and mechanisms to efficiently allocate mobility
anchors to mobile nodes in a manner that is optimised for the mobile
node's geo-location.

Then that's clear and fine as an item, but I think the long version above
goes around in circles and I don't see a clear consequential problem to be
solved other than the bullet above.

Hesham



>    
>    Jari
>    
>  
>
>_______________________________________________
>MEXT mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mext