Subject: [Mipshop] Minutes of Multiple Link Flows BAR BOF

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Nov 2003 16:32:17 -0800

Folks,

Attached are the minutes of the multiple link flows BAR BOF.

            jak

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 13 Nov 2003 16:44:32 +0100

Hi,

Thank you James for this good minutes of our meeting. It clearly 
clarifies things and help to move forward.

However, I have to raise a point. We (Ryuji, Thierry, Thomas and me) 
began to write a problem statement draft in MIP6 WG 
(draft-montavont-multihoming-pb-statement-00) and I think that it can be 
the starting point of a pb statement document. Following the 
presentation of this draft at the MIP6 meeting, and from some comments 
in the mailing list, we receive valuable feedback for the evolution of 
this draft. Also, the bar bof gives us other ideas to enhance this document.

So I think that a new version of this draft can constitute the pb 
statement currently required to move forward on the multihoming. It is 
not necessary to duplicate the efforts.

Nicolas

James Kempf wrote:

>------------------------------------------------------------------------
>
>Introduction
>------------
>
>This note describes an informal meeting held at IETF 58 on Monday where the general topic of utilizing multiple links was discussed. Wireless last hop links were the primary focus, since market introduction of consumer devices with multiple wireless interfaces is pending, and people can get the same now with laptops that have multiple wireless interface cards.
>
>Single Logical Flow over Separate Physical Links/IP Addresses
>-------------------------------------------------------------
>
>This topic area concerned splitting a single logical flow over multiple IP addresses, presumably to match multiple physical interfaces on the device. This technique had been proposed by SCTP orignally as a way of load balancing, and in other contexts for transport striping to achieve higher throughput. Randy Steward talked about why this was taken out of SCTP. In summary, although the sending host may utilize multiple addresses for the receiving host, and although the the receiving host might have those multiple addresses configured on multiple separate physical interfaces, the traffic between the two might run over the exact same physical path, and consequently utilizing two addresses won't really provide any load balancing as far as the intervening network is concerned. Problems include out of order packets, false retransmissions, problems with congestion control variables, and timeouts. Performing retransmission on one address for congestion detected on the other might have the perverse effect of causing worse congestion. As a result, SCTP now supports multiple links only for purposes of fault tolerance, failing over to a new link if the old one goes down, and not load balancing.
>
>The University of Deleware has been doing research on this topic and has published some papers. Below is a short bibliography:
>
>http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf
>
>Describes the problems with concurrent multilink transfer and proposes some algorithms to fix the problems.
>
>http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf
>
>Shows that retransmit policies which try to utilize multiple paths often result in worse performance.
>
>Moving Flows Between Mobile IP Care of Addresses
>------------------------------------------------
>
>The idea behind this proposal is to allow movement of multiple flows between different Mobile IP care of addresses depending on the characteristics of the wireless links on which those addresses are configured. The proposal seems most interesting near term for the MIP4 WG in order to accommodate multiple interface devices in existing MIP4 deployments, and longer term in the MIP6 WG as well as for mobile networks in NEMO. This technique would not be performing link aggregation since the paths for logical flows would be uniform, not split. From the point of view of the SCTP experience, this seemed as if it would not be a problem since end to end congestion control is being performed on logical flows that traverse one path. It would, however, hide the flow movement from the correspondent node, i.e. the corresponding end point would not be involved in the decision about which care of address to use. This idea has motivated a draft in the MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends installing "filters" at the home agent to perform the redirection. The filters would allow traffic of various types to be redirected to care of addresses whose corresponding physical interfaces had particular bandwidth and latency characteristics, for example, running video over a broadband WLAN interface. In addition, it would help preserve home addresses in MIP4 since the MN would only have a single home address. Clearly, there is a potential end to end issue in not notifying the correspondent node about the flow switching, but since the home agent is essentiall performing a routing function, the situation is not much different than a QoS router that switches a flow to a different interface due to flow state set up by RSVP signaling. There is, of course, the same scaling issue in the home agent as for RSVP, since the home agent must maintain per flow and per care of address state, but the scaling issue is restricted to just the home agent.
>
>If this proposal is accepted, there is an issue about which signaling protocol to use with the home agent to tell it how to move the flows. Mobile IP itself was suggested, QoS signaling protocols such as RSVP and NSIS, SNMP, and COPS. Lately, the trend has been to not add additional functions into Mobile IP, to keep it simple and dedicated strictly to mobility, thus, AAA was separated out of MIP6, so the MIP protocol itself might not be the best choice for the signaling protocol.
>
>Simulations and prototypes in realistic networks would also be of interest, to see if any unanticipated problems crop up.
>
>Two specific problems were discussed besides the general problem. One was the usefulness of multiple care of addresses for mobile networks. NEMO is still studying the issue, and hasn't as yet worked through the problem. The other was using RFC 3401 address privacy for IPv6. In this scenerio, the mobile node has multiple care of addresses assigned to a single interface, and would like to use them for privacy between the mobile node and home agent. 
>
>Next Steps
>----------
>
>There was no concensus in the group about whether the problem was specifically an issue for the MIP groups or whether it required participation from other WGs. Since there are some proposals before the MIP4 & MIP6 WGs currently, the MIP groups are the logical place to start. Thomas Narten suggested coming up with a clear problem statement, and Carsten Borman volunteered to talk with the group at Universitaet Bremen who authored draft-nomad-mobileip-filters-05.txt about authoring a clear problem statement for the MIP care of address case.
>
>
>Terminology
>-----------
>
>After the meeting, Carsten Borman and I discussed how to designate this topic area. The meeting was advertised as "multilink flows" but that doesn't capture the problem since it also implies logical flows over multiple IP addresses, something that the SCTP experience has indicated is problematic from a congestion control standpoint. The term "QoS routing" came up during the meeting but that drags along a lot of baggage. "Flow handoff" seems to capture the topic best, since the intent is to hand off individual flows to care of addresses that have the best characteristics for handling the flows.
>

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Nov 2003 23:34:21 +0100 (CET)

I didn't make it to the bar on Monday due to jetlag.

One observation I have on the desire to send different flows over
different paths/CoAs.

Looking at possible multihoming solutions (take draft-nordmark-multi6-noid
as an example one what a solution might look like) the result
is that the stack would have a mapping from an ID (used by transport protocols)
to a set of locators for the peer.

This type of example shows that it might be useful to express sending
different flows over different paths/locators even if mobility isn't used.

Thus I don't think such a scheme, if we are going to define one,
should be tied to mobility specific signalling.

  Erik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2003 00:03:30 +0100

> should be tied to mobility specific signalling.

This is certainly good thinking, but the question is "express to whom"?

When you have a HA, this is a good place to perform this flow handoff 
-- existing trust relationship, same administrative domain, existing 
and stable communication relationship.
The MobileIP protocol is a good way to talk to the HA (and much of the 
signalling actually can be piggybacked).
A more general approach (e.g., the closest willing router shared 
between the paths to the two interfaces) will need an on-path 
signalling protocol like NSIS, which is much more complex to use.

Generality is not always cheap.
(I'm willing to be convinced that it actually is, in this case.)

Oh, and if there is no mobility, it is much easier to involve the CN 
(transport peer) from the outset -- no protocol needed in this 
(obvious) case.

Gruesse, Carsten

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 14 Nov 2003 00:22:43 +0100

>should be tied to mobility specific signalling.
I totally agree with you that if we specify a MIPv6-tied solution for 
"general" multihoming, we may encounter difficulties with non-MNs.
But I think that some points are to be clarified in MIPv6 when the MN is 
multihomed. That is what we are trying to show in 
draft-montavont-pb-statement.

And I'd like to point out another aspect of multihoming, more linked to 
our draft on filtering (draft-montavont-mip6-ha-filtering). Assume that 
you have two interfaces, a WLAN interface and a GPRS interface and you 
currently use the WLAN interface through a reverse tunnel with your home 
agent. Assume that you receive several flows on your pda. One of them is 
a video streaming.

Then you leave the hot spot zone and want to switch your flows on GPRS 
interface. To do so, you send a BU to your HA. In this case, it can be 
very useful to add some filters on what flows you want to be redirected 
and what flows you don't want on your GPRS interface. It seems to me 
that to use the BU in that case is a good solution, because you only 
need to send one message. This does not forbidd the use of other 
mechanisms to manage multihoming in different situations.

Maybe the conclusion of that can be that different problems may lead to 
different solutions. A clear problem statement, from each WG may 
definitly help to clarify the situation.

Nicolas

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Nov 2003 18:12:27 -0800

Carsten,

> signalling protocol like NSIS, which is much more complex to use.

NSIS is certanly more general, but seems like it is the right approach
architecturally. The home agent is essentially a middlebox, and from the
presentations I saw today in the NSIS group, NSIS is a solution primarily
for signaling to middleboxes, not routers like RSVP is.

> (I'm willing to be convinced that it actually is, in this case.)

Not clear what the implementation and deployment cost of NSIS is at this
point.

In terms of dynamic performance, whether the MN sends a binding update or an
NSIS message  to the home agent, does it make such a differenc?

> (transport peer) from the outset -- no protocol needed in this

One could make an argument that it still might be useful to mask multihoming
from the CN.

                jak

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2003 03:18:09 +0100 (CET)

> This is certainly good thinking, but the question is "express to whom"?

To the entity that has the ability to choose locators.
In some multihoming proposals this is a shim layer above IP at the originating
node.

> signalling protocol like NSIS, which is much more complex to use.

Yes, bolting solutions on existing protocols even though the problem is
more general is a common approach; sometimes we pay deerly for this
because 
 - we might end up solving the general case as well
 - the general + specific solutions means that we know have two solutions
   for the same problem
 - the specific solution makes the exising protocol (MIP signalling in this
   case) more complex, less likely to interoperate, etc

> (transport peer) from the outset -- no protocol needed in this 

How can the peer know that I want the video part of the conference over
the WLAN interface and the audio part over GPRS?
One could declare this to be an application specific problem, but it would
still require application specific signalling, right?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2003 03:19:36 +0100 (CET)

> mechanisms to manage multihoming in different situations.

Yes, but this is just as useful even if I don't use MIP.
Developping multiple solutions to the same problem shouldn't be a goal
I think.

  Erik

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2003 03:51:43 +0100

> still require application specific signalling, right?

Yes, and both SIP/SDP(ng) and H.323 allow specifying the IP address of 
the destination for a media stream.  You can even move those during a 
session (if the peer system implements this).
Even FTP had third-party transfers, before these went out of fashion.  
With HTTP, you just use the right interface to make the request.

On the other hand, if you always wanted to involve the CN in these 
handoffs, we wouldn't need MobileIP.

(The interesting deviant case is a non-cooperating CN -- here you 
actually need a friend in the network even if you are not mobile.)

Gruesse, Carsten

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2003 15:05:06 +0100 (CET)

> handoffs, we wouldn't need MobileIP.

You'd still need one (or more) rendez-vous points aka home agents 
to handle initial contact and both ends of communication moving at
the same time.

  Erik