Subject: [multipathtcp] multipath TCP/HIP

From: Andrei Gurtov <[email-masked]>
Date: Thu, 30 Jul 2009 11:58:34 +0300

Hi,

I agree with Tim Shepard's comment on BOF that it would be nice to see
how multipath TCP efforts fit with HIP/shim6 multihoming. Because
HIP/shim6 can fix many security and middlebox traversal issues for
multipath without a need to modify application API (or even transport
layer). In a BROADNETS paper below, we've sketched such architecture as
well as did some simulations on this approach in ns2. Your comments and
opinions appreciated!

http://www.cs.helsinki.fi/u/gurtov/papers/broadnets09.pdf

Andrei

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 30 Jul 2009 04:51:37 -0700

If interactions with SHIM6 & HIP are worth to be considered, I think the same is true for MIPV6 and its multiple care-of address extensions.

--julien

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of Andrei Gurtov
> Sent: Thursday, July 30, 2009 1:59 AM
> To: Multipath TCP Mailing List
> Cc: Tim Shepard
> Subject: [multipathtcp] multipath TCP/HIP
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkpxYLoACgkQP7jp0uceFkSOQQCfb1dwT+wn1URX3pUYCi8jYdL0
> 6g8AoLPkkgoH/qad3kO9m50K2IBI5QFi
> =Or26
> -----END PGP SIGNATURE-----
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Jul 2009 14:03:22 +0200

On 30 jul 2009, at 10:58, Andrei Gurtov wrote:

> how multipath TCP efforts fit with HIP/shim6 multihoming.

On some level it would make sense to reuse Shim6 as the mechanism to  
negotiate additional addresses when MPTCP runs over IPv6. Obviously  
this isn't so hot for IPv4. However, I don't know if it's possible to  
make a seamless integration between the two-ended MPTCP in the current  
draft and a Shim6MPTCP in such a way that it would seamlessly bond  
IPv4 and IPv6 paths.

Iljitsch

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 30 Jul 2009 16:32:56 +0300

Iljitsch van Beijnum wrote:
> negotiate additional addresses when MPTCP runs over IPv6. Obviously this
> isn't so hot for IPv4. However, I don't know if it's possible to make a
> seamless integration between the two-ended MPTCP in the current draft
> and a Shim6MPTCP in such a way that it would seamlessly bond IPv4 and
> IPv6 paths.

For two-ended multipath TCP it makes more sense to use HIP than shim6.
Then there is no IPv4/IPv6 issues - in fact you could mix such paths
together to receive their aggregate bandwidth.

Andrei

---

From: John Leslie <[email-masked]>
Date: Thu, 30 Jul 2009 10:05:10 -0400

> together to receive their aggregate bandwidth.

   May I suggest you give a brief tutorial on how to do this?

   (HIP would appear to be a work in progress, and I doubt we'd all
make the same guesses where it will end up.)

--
John Leslie <[email-masked]>

---

From: Andrei Gurtov <[email-masked]>
Date: Fri, 31 Jul 2009 12:53:42 +0300

>    May I suggest you give a brief tutorial on how to do this?

With HIP, TCP and applications see only HIT, a hash of public key.
The scheduler sitting between HIP and link interfaces estimates RTT and
loss of each path from a stream of TCP packets/acks and distributes TCP
segments along the paths according to estimated TCP-friendly rate and
trying to avoid packet reordering. So you have multipath implemented
"low" in the stack, below actual TCP layer. The good thing is that
prevents address hijacking, TCP reset, etc attacks since traffic is (as
a rule) secured by IPsec. Applications and network stack don't need
modifications, the scheduler is sitting as a user-level daemon.

If you're looking for a generic HIP tutorial, there is a short intro in
Cisco's IP journal
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/ipj_12-1.pdf

> make the same guesses where it will end up.)

Well, it's in progress of being upgraded from experimental to standard
track, but HIP itself has been around since 1999 and lately in quite
stable form since RFC5201-5207 were published. There are HIP VPN
products that are used in production factory environments.

Andrei

---

From: Sébastien Barré <[email-masked]>
Date: Fri, 31 Jul 2009 14:02:28 +0200

Hi,

While HIP provides better security, it also comes with the cost of 
having that high security.
Also, AFAICT, I think that Shim6 seems easier to deploy than HIP in the 
Internet, since Shim6 uses a particular locator as identifer, rather 
than a non-routable HIT.

Since IPsec is probably not always required, my guess is that it would 
be nice to consider a multipath TCP
able to run on either one of HIP or shim6.

regards,

Sébastien.

Andrei Gurtov a écrit :
> iEYEARECAAYFAkpyvyYACgkQP7jp0uceFkRcyACdHewFPWyqEbWDI4qZ7tQrv//M
> HlIAoOENysE4rhE5OWvkY0iKVu1BmFnw
> =Rzsg

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Bryan Ford <[email-masked]>
Date: Fri, 31 Jul 2009 21:33:09 +0200

Multipath TCP (or multipath <insert-your-transport-here>) needs at  
least the following two components to build on, each of which can be  
defined and implemented separately and orthogonally to each other and  
to the multipath transport protocol itself:

1. A mechanism to detect the existence and number of paths available  
between two logical endpoints, and to direct traffic over one  
particular path or another.
2. A mechanism to shape (congestion control) the traffic over each  
path in an appropriately multipath-sensitive way.

#2 can be separated cleanly from the semantic part of the transport,  
as discussed in our architecture draft, simply by having the Flow  
Layer (which implements congestion control) provide an interface  
allowing higher layers (in this case the Semantic Layer) to declare a  
certain set of flows to be "bundled" or "linked" for congestion  
control purposes.  It's completely up to the congestion control  
algorithm in the Flow Layer how to interpret that "linkage"  
information, whether via simple 1/n MulTCP, Michio Honda's dynamic  
weight-shifting approach, or the latest partly-coupled algorithm  
presented in TSVAREA.  The Semantic Layer doesn't need to care how the  
Flow Layer handles linked flows; it just indicates to the Flow Layer  
that they are connected.  The Flow Layer doesn't need to care _why_  
flows are linked - they could just as well be linked because the  
_application_ requested it.

#1 can likewise be separated cleanly from the semantic part of the  
transport via a simple interface, and through that interface,  
multipath TCP (or multipath anything) could run atop any of the  
following "multipath-capable delivery services":

(a) Atop a simple mechanism that just uses multiple (IP,port) endpont  
pairs on each host to define multiple paths, as specified in the  
current protocol draft.
(b) Atop a version of HIP modified slightly to expose the existence  
of, and a way to direct traffic over, the multiple paths derived from  
the many-to-one relationship of locators to identifiers in the HIP  
world.
(c) Atop a version of shim6 similarly modified.
(d) Atop an IP routing protocol that has been extended with "native"  
support for discovering and making available multiple paths between  
two IP addresses.  There are many experimental examples of such  
protocols.

In any of these options, the interface between the "multipath-capable  
delivery service", whatever it is, and the main multipath transport,  
can be at least conceptually very simple:

1. The multipath-capable delivery service provides a function the  
upper layer can call to get (an estimate of) the number of paths  
available or currently known (i.e., a simple integer) between two  
endpoints as known to the upper layer .  Change notification or  
periodic re-checking considerations may apply of course.

2. The multipath-capable delivery service, in the function it provides  
to the upper layer to transmit a packet, allows the upper layer to  
specify a "path selector" - a simple integer from 0 to n-1, where n is  
the number of paths returned above - and ensures that the packet gets  
transmitted over that path.

The key idea is that the semantic part of the multipath transport -  
i.e., the TCP stuff that does stream-level sequencing and end-to-end  
acknowledgment and retransmission and all that - needs to know that  
there _are_ multiple paths but doesn't need to know almost anything  
_about_ those paths.  It just needs to know that the paths exist and  
have a way to index them.  There are several reasonable and  
interesting ways of actually figuring out what those paths are, but  
that functionality should be, at least logically, very separate and  
orthogonal to the semantic part of the multipath transport.

In the interest of ensuring that the multipath WG can make progress by  
itself without unnecessary dependence on other experimental protocols,  
I think its charter specify that mechanism (a) above be the first  
"multipath-capable delivery service" to be worked on, but tie-ins with  
HIP, shim6, etc., could come in later stages.  Unless of course the  
debate about changing TCP semantics makes (a) a non-option, which  
personally I think would be a pity; there's a lot of value in having  
multipath TCP usable by unmodified or nearly-unmodified applications  
when it can be determined to be safe to do so.

Bryan

On Jul 31, 2009, at 2:02 PM, Sébastien Barré wrote:
> Also, AFAICT, I think that Shim6 seems easier to deploy than HIP in  
> the Internet, since Shim6 uses a particular locator as identifer,  
> rather than a non-routable HIT.
>
> Since IPsec is probably not always required, my guess is that it  
> would be nice to consider a multipath TCP

---

From: Sébastien Barré <[email-masked]>
Date: Sat, 01 Aug 2009 00:17:15 +0200

Hi Bryan,

I completely agree with you.
Actually I have worked quite a bit with this kind of architecture, which 
I described in details in section 3 of Trilogy deliverable 4 
(http://trilogy-project.org/fileadmin/publications/Deliverables/D4_-_Design_Space_Analysis_for_Reachability.pdf) 
as well as in section 5.2 of Trilogy deliverable 5 
(http://trilogy-project.org/fileadmin/publications/Deliverables/D5_-_Design_Space_Analysis_for_Resource_Control.pdf).
A short update/summary is also present in Trilogy deliverable 7, section 
3.1.2. 
(http://trilogy-project.org/fileadmin/publications/Deliverables/D7_-_Trilogy_Overall_Architecture_Including_Design_Principles.pdf)

In the D4, the path management aspects are described (which corresponds 
more or less to your #1 description), while in the D5, the overall 
architecture and definition of an "MPS" (MultiPath Scheduler) are 
provided (#2 in your description).

I also have already a prototype implementation that runs above Shim6, 
but is sufficiently generic (it actually implements the architecture 
described in D4,D5,D7) to be extended for other technologies.

regards,

Sébastien.

Bryan Ford a écrit :
> the many-to-one relationship of locators to identifiers in the HIP world.