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 08:19:00 -0500

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
 > > 
 > > 
 > > 
 > > 
 > > -- 
 > > Mip4 mailing list
 > > [email-masked]
 > > https://www.ietf.org/mailman/listinfo/mip4
 > 

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 17 Nov 2003 17:40:00 +0100

> edge of a cell, given the sizes of those messages. 

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

	Henrik

	Henrik

-- 
  Don't store garlic near other victuals.

---

From: Pete McCann <[email-masked]>
Date: Mon, 17 Nov 2003 10:43:54 -0600

Hi, Hesham,

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.

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

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Nov 2003 14:57:20 -0800

Pete,

> the application protocol.

Agree with IPv4 addresses being scare as the main issue for doing flow
handoff at the home agent in MIPv4, but not sure about whether the RREQ is
the right place for filters. Seems like it is a generic middlebox problem
and should be approached using the same tools as for other middleboxes.

> with some sort of NAI-mangling naming convention

Why would multiple NAIs be necessary if all the CoA to HoA mappings were
handled by one HA, as would be the case if the same service provider was
providing service on all CoAs? I agree that they would be necessary if the
the CoAs were provided by multiple service providers, but the flow handover
issue is just the tip of the iceberg in that case, IMHO.

            jak

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 18 Nov 2003 01:01:24 +0100

Hi James,

> and should be approached using the same tools as for other middleboxes.

I'm not at all sure that the reasoning about IPv4 address scarcity
holds water.  MIPv4 works with both HoAs and CoAs being private, behind
NATs (even if we don't like'em... :)  

> issue is just the tip of the iceberg in that case, IMHO.

I don't think we can assume neither that the same service provder is
providing service on all CoAs, nor that there is only one HA. If public
WLAN hotspots vs. cellular vs. corporate WLAN is a typical scenario, 
I'd say it's actually quite unlikely.

	Henrik

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 18 Nov 2003 14:55:49 +0900

Hi,

> I'd say it's actually quite unlikely.

I agree with that, the benefit of multihoming would be moot if we assume
a single HA or single ISP (= single point of failures). Such assumptions
does not hold in face of the multihoming scenarios, as identified in
draft-montavont-mobileip-multihoming-pb-statement.

Thierry.

---

From: Sebastian Thalanany <[email-masked]>
Date: Tue, 18 Nov 2003 07:48:22 -0600

Hello Thierry,
                    For supporting multilink flows we cannot assume only 
one HA. From a service provision perspective, geographic redundancy is 
preferred to avoid single point failure impacts on service delivery. I 
agree with your observations.

Regards,
    Sebastian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Nov 2003 12:32:54 +0100

Henrik Levkowetz wrote:
>> 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.

Also note when calling it "expensive" that this BU happens only once per
"cell", it does not add up to the effective usable app-level
communication.  One BU or two BU's is almost the same.  It does not grow
exponentially.  It grows only with the number of interfaces or of home
addresses one has on a machine.  Number of interfaces is clear: no more
than 3-4 interfaces on a _mobile_ device which is implicitely small.
Number of home addresses per devices is also clear: no more than the
number of apps that mobile machine runs simultaneously, also small.

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

Again here note remarks from practice where sizes of upstream packets
accepted my some widely deployed/adopted/used wireless envs is
relatively large with respect to the size of either one RReq or one BU
(which are relatively small).

Then, if sizes of IP packets are indeed too large, then there is IP
fragmentation or IP PMTU discovery as good reusable tools too.

Alex
GBU

---

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

Hi

 > NATs (even if we don't like'em... :)  

Yes, but we may need to solve this problem for public IPv4 addresses,
depending on the deployment scenarios.

 > I'd say it's actually quite unlikely.

I wasn't thinking of multiple service providers, I was just trying to
find a cheap and easy way to support multiple sessions even on a
single HA.  The problem with a single NAI is that it becomes
impossible to distinguish a retransmission from a request for a new
session (IP home address).  So we need something like a session ID, or
a convention for multiple sessions within the NAI namespace.

Such a technique would also allow each flow to be homed on a different
home agent, as you point out, which might be needed for additional
flexibility.  However, all the subsequent posts about HA redundancy,
etc, have gotten way off topic and are missing my point entirely.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 20 Nov 2003 17:14:04 +0100

On Wednesday, 19 Nov 2003, Pete wrote:

[...]
> depending on the deployment scenarios.

True.

[...]
> a convention for multiple sessions within the NAI namespace.

Agreed.

> etc, have gotten way off topic and are missing my point entirely.

Yup. 

	Henrik