Subject: [Mip6] RE: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF

From: Soliman Hesham <[email-masked]>
Date: Mon, 17 Nov 2003 23:53:21 -0500

Hi Pete, 

 > So maybe what we need is an efficient way to handle multi-homed hosts
 > (hosts with multiple home addresses) in MIP6.  This could be 
 > something
 > like aggregation of BUs or other sorts of tricks.

=> That used to be in the draft for the HA BUs but was removed
because it was difficult to achieve from a security
point of view. I'm not sure that this is cleaner than
just adding the flow movement extensions. Also another 
use of those extensions (that I didn't want to bring up
yet) is for optimising the handover smoothing for different
flows (buffer to eliminate packet loss Vs forward to eliminate
delays). 

 > In MIP4, there may be less of an impact from multiple home addresses
 > due to the absence of route optimization.  However, IPv4 
 > addresses are
 > more precious than IPv6 addresses.  That last fact seems to me to be
 > the only reason why we would think about putting filters into a
 > registration request.  

=> In MIPv4 I agree.

   It seems much simpler for the application
 > (using SIP or whatever) to advertise a particular home address to the
 > CN.  You could still handle mobility independently for each session,
 > using Mobile IP along with the extra level of indirection supplied by
 > the separate IP addresses.  There is no need to build mobility into
 > the application protocol.

=> There is definitely no need to build mobility into the 
application protocol, I didn't suggest that. Having SIP
advertise an address does not fix the problem when you 
want to move that connection from one interface to another
as I explained in a previous email. The only way to do that
today is to terminate the connection and restart it. I
don't imagine that we'd want to do that.

 > 
 > There may be a few unsolved issues with HAs allocating multiple
 > addresses, but I think it could be handled easily with the use of
 > multiple NAIs.  I wrote a draft called the "Mobile IP Session
 > Identifier Extension" some years back, but you could do the 
 > same thing
 > with some sort of NAI-mangling naming convention
 > ([email-masked], [email-masked], etc...).

=> I remember that, it was presented in Adelaide I think.
I thought it was worth pursuing back then. Anyway, now we're
discussing solution space, I just wanted to highlight the problem.

At the moment it's probably a bit premature to decide that
one solution is _the_ one (hence I'm being the devil's 
advocate either way you go :) ). If this topic is important
to the WGs perhaps we should do a proper investigation.

Hesham

 > 
 > -Pete
 > 
 > Soliman Hesham writes:
 >  > Hi Henrik, 
 >  > 
 >  > It's certainly _a_ solution. And definitely a simple one. 
 >  > But I would view this as being very expensive for MIPv6. Assuming
 >  > 2 HoAs, in the worst case scenario the MN could end up sending two
 >  > BUs to the HA and two to each CN that knows about both
 >  > HoAs. I think this is too expensive, especially if MIP
 >  > is being used to manage mobility proper. 
 >  > For MIPv4 it's not as expensive, but sending two different
 >  > RREQs upon movement can still be expensive from the 
 >  > edge of a cell, given the sizes of those messages. 
 >  > 
 >  > Hesham
 >  > 
 >  >  > -----Original Message-----
 >  >  > From: Henrik Levkowetz [mailto:[email-masked]]
 >  >  > Sent: Monday, November 17, 2003 7:59 AM
 >  >  > To: Soliman Hesham
 >  >  > Cc: [email-masked]; [email-masked]
 >  >  > Subject: Re: [Mip4] tying flow movement to MIP RE: [Mipshop] 
 >  >  > Minutes of
 >  >  > Multiple Lin k Flows BAR BOF
 >  >  > 
 >  >  > 
 >  >  > Hi Hesham,
 >  >  > 
 >  >  >     That's a pretty good summary.  My own thinking on this, 
 >  >  > after a bit
 >  >  > of discussion in Minneapolis, is that the MIP solution 
 > which is the
 >  >  > least MIP-specific would be to have separate individual MIP 
 >  >  > sessions for
 >  >  > each flow (or group of flows) we wanted to move 
 >  >  > independently of other
 >  >  > flows. This takes care of the ability to treat flows 
 >  >  > individually, and
 >  >  > it does so by providing separate Home IP-addresses for 
 > those flows to
 >  >  > pass through.
 >  >  > 
 >  >  > I also note that the flow groups, and their 
 > IP-addresses, needs to be
 >  >  > established before individual user applications start up and 
 >  >  > bind to the
 >  >  > individual HoAs - we have no way to signal most application 
 >  >  > to re-bind
 >  >  > to a new IP-address.
 >  >  > 
 >  >  > The cost of this solution is in having to do re-registration 
 >  >  > of multiple
 >  >  > sessions when you move, but such a cost is already implicit 
 >  >  > in the fact
 >  >  > that with multiple connections through different 
 > connection media you
 >  >  > have to be able to handle each media individually, 
 > whether it is by
 >  >  > separate sessions or by filter adaptations.  But I 
 > believe completely
 >  >  > separate sessions will adapt better to any other 
 >  >  > non-movement-specific
 >  >  > solution to multihoming that may appear.
 >  >  > 
 >  >  > 	Henrik
 >  >  > 
 >  >  > Monday 17 November 2003, Hesham wrote:
 >  >  > > Hi, 
 >  >  > > 
 >  >  > > Just wanted to drop a note on adding flow movement
 >  >  > > capabilities to MIP. 
 >  >  > > 
 >  >  > > I completely agree that adding new functions to
 >  >  > > MIP just because "it's there" does not make any sense, 
 >  >  > > and that where a problem applies to both fixed and mobile
 >  >  > > hosts we should avoid fixing it in a mobility protocol. 
 >  >  > > However, when it comes to flow movement, it is not 
 > immediately
 >  >  > > obvious to me that it is outside the scope of MIP. 
 >  >  > > I'll try to break the problem down in an attempt to realise
 >  >  > > where each component belongs. 
 >  >  > > 
 >  >  > > The basic problem is that a node needs to decide what 
 >  >  > > src address should be used by a particular connection.
 >  >  > > Forgetting about MIP for a minute, this is obvious when
 >  >  > > a host is trying to initiate communication with another host.
 >  >  > > Src address selection can be augmented with various policies
 >  >  > > (user-based or otherwise) to allow the host to pick the 
 >  >  > > right src address. However, this is a bit more complex when
 >  >  > > a host is not the initiator of communication. This leads
 >  >  > > to sub-problem (1)
 >  >  > >   (1) Informing the initiator of communication of the right
 >  >  > >       dst address for the host on the other end.
 >  >  > > 
 >  >  > > This information can be communicated implicitly or 
 > explicitly. 
 >  >  > > One possible example for implicitly informing the other end
 >  >  > > is through using different domain names (e.g. 
 > audio.example.com
 >  >  > > returns a different address from video.example.com). On the 
 >  >  > > other hand, explicit notification of the address can be done
 >  >  > > by using a protocol to negotiate a connection setup (e.g. SIP
 >  >  > > does this today). 
 >  >  > > 
 >  >  > > Not withstanding the example solutions above, sub-problem
 >  >  > > (1) is independent of any mobility and applies to any 
 >  >  > > multi-addressed host. 
 >  >  > > 
 >  >  > > Once a connection is established, the right addresses are 
 >  >  > > chosen by both ends, end of story. 
 >  >  > > 
 >  >  > > Now, the other aspect of the problem is this: Once a 
 > connection
 >  >  > > is established, using a particular src and 
 > destination address
 >  >  > > pair, how can either host modify this information? In other
 >  >  > > words, if WLAN coverage suddenly appeared to my laptop, how
 >  >  > > do I inform the host on the other end to move one of our 
 >  >  > > connections to WLAN, while leaving the other on the cellular 
 >  >  > > interface? In a few words, I want to change the dst 
 > address for
 >  >  > > a particular connection without breaking that connection.
 >  >  > > This requires a protocol to signal that to the other end. 
 >  >  > > To me, this problem seems to fall into the IP 
 > mobility category
 >  >  > > of problems, although it is addressing a finer granularity
 >  >  > > of mobility. 
 >  >  > > Note that SIP also has signalling support for 
 > session transfer, 
 >  >  > > but: A) it was not intended for this purpose and B) it is 
 >  >  > > not widely implemented and C) it is slower than an 
 > "optimised" MIP
 >  >  > > (BTW neither A nor B discredits using SIP for this purpose). 
 >  >  > > 
 >  >  > > So sub-problem (2):
 >  >  > >   (2) How to move a flow from one address to another. 
 >  >  > > 
 >  >  > > MIP efficiently solves this problem for a host, but it 
 >  >  > > does not provide further granularity (i.e. connection
 >  >  > > or flow). 
 >  >  > > 
 >  >  > > Personally, I think sub-problem (2) is a mobility
 >  >  > > problem, by the definition of IP mobility. I believe
 >  >  > > that MIP solves two problems: maintaining current connections
 >  >  > > while moving, and reachability. 
 >  >  > > "Moving" in the context of IP mobility effectively means 
 >  >  > > changing IP address, independently of whether that change
 >  >  > > affects all flows or only one or two. 
 >  >  > > 
 >  >  > > My 2 cents! 
 >  >  > > 
 >  >  > > Hesham
 > 

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

---

From: Pete McCann <[email-masked]>
Date: Wed, 19 Nov 2003 11:12:06 -0600

Hi, Hesham,

 > flows (buffer to eliminate packet loss Vs forward to eliminate

Sure, but I think you could do that with multiple home addresses too.

 > don't imagine that we'd want to do that.

No, you wouldn't need to do that, assuming each application was using
its own home address.  Each application flow could be moved completely
independently, based on application needs and interface availability.
You just send a registration request binding the home address to the
right CoA.

 > to the WGs perhaps we should do a proper investigation.

Agreed - I guess we need to understand where this requirement is
coming from.  Also, we need to understand whether commercial
production mobiles will want to include the necessary APIs for people
to build these kinds of adaptive applications, or whether this is all
just an academic exercise.

-Pete