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:43:11 -0500

> Mmm, I think mostly it'd be just one BU per CN, but I could 
 > be wrong. I
 > also tried to think a little bit about the size of the filter update
 > packets, and I think the chances are they'd be larger than a 
 > RRQ - and

=> I guess that depends on the solution.

 > you might not be able to avoid the RRQ's anyway!  I think 
 > that before we
 > go for a more complex solution instead of the simpler, we 
 > need to do the
 > maths and see that the more complex, less general one really gives a
 > noticeable upside in reasonable scenarios?

=> Sure, I'm not sure what "less general" means though. 

Hesham

 > 
 > 	Henrik
 > 
 > 
 > > 
 > >  > -----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
 > >  > > 
 > >  > > 
 > >  > > 
 > >  > > 
 > >  > > -- 
 > >  > > Mip4 mailing list
 > >  > > [email-masked]
 > >  > > https://www.ietf.org/mailman/listinfo/mip4
 > >  > 
 > 
 > 
 > 	Henrik
 > 
 > -- 
 >   Don't store garlic near other victuals. 
 > 

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

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 20 Nov 2003 00:57:32 -0500

>  > => 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). 
 > 
 > Sure, but I think you could do that with multiple home addresses too.

=> See below.

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

=> I know you can do it with multiple HoAs but I think it's
too "expensive" in terms of signalling over the air, 
especially during a handover. I think one BU/RREQ
is about as much as you can send during handover, that is
if MIP is being used to manage mobility.

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

=> I wouldn't hold my breath about getting companies
to tell us about these sorts of plans, but if it works
then great...

Hesham