Subject: [tcpm] WG status update

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 9 Nov 2010 18:54:50 -0600

Hi, for those of you who aren't in Beijing, here's a snapshot of the TCPM WG status.

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Wed, 10 Nov 2010 08:54:17 +0100

Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] a 
> Hi, for those of you who aren't in Beijing, here's a snapshot of the TCPM WG status.

Hi,

I have posted a 00 draft that might be of interest for your working 
group. I don't see any mention in your snapshot.
http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt

I will not be in Beijing to present it but i hope to be in Prague to do so.
I would appreciate the working group can look at it and let me know if 
it could be of any interest and how i shall pursue my contribution.

I have done a Linux kernel implementation of the draft and be ready for 
a demo in Prague.

Best Regards,
Bruno.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 10 Nov 2010 12:35:04 -0000

http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02
Status: polled for interest on 6/16/10
        one positive response; no negative - too weak for adoption

I have been under the impression, that Lars specifically approached the
authors to update and resubmit a new revision of the draft, before this
can move forward.

For the record, I share the opinion of Anumita (adopt this as WG item,
updated with the most recent studies on stability / ICCRG input).

Ditto for draft-rhee-tcpm-cubic

Richard Scheffenegger

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 10 Nov 2010 12:51:01 -0000

Hi Bruno,

After a casual look, it appears to me that a lightweight implementation of MP-TCP can have the same benefits, but does not require the opaque exchange of IPv4 addresses...

Your use case - that the old L3 address is already no longer available at the time of the rehash - may need to be looked at in MPTCP though (iirc, they do a graceful session setup first (thus can work with NAT mostly), and move data transport only after the successful establishment of the 2nd L3 connectivity, and only then tear down the original L3 connectivity).

Perhaps the effort would be better placed on making sure that such light-weight MPTCP implementations remain feasible, instead of defining an alternate method that is addressing only this one aspect, but incompatible with MPTCP otherwise?

Richard Scheffenegger

> -----Original Message-----
> From: Bruno Mongazon-Cazavet 
> [mailto:[email-masked]] 
> Sent: Mittwoch, 10. November 2010 08:54
> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Cc: [email-masked]
> Subject: Re: [tcpm] WG status update
> 
> 
>   Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC 
> AEROSPACE CORP] a écrit :
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 11 Nov 2010 09:45:09 +0800

Hi,

I may be confused, but I thought Murari said that an updater was pending. If there isn't, this can of course be adopted now.

And as an individual contributor, I'd like to see that, as well as Cubic.

Lars

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 11 Nov 2010 01:48:33 +0000

There is one equation that has an error baring that there isn't much of an update. I'll make that edit today or tomorrow and submit. But that edit shouldn't really block this from being adopted in my opinion as it is well understood and discussed earlier. Since I never got a chance to resubmit the ID to TCPM till now I hadn't formally made that change. 

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Wednesday, November 10, 2010 5:45 PM
To: Richard Scheffenegger; Murari Sridharan
Cc: [email-masked]
Subject: Re: [tcpm] WG status update

Hi,

Lars

On 2010-11-10, at 20:35, Scheffenegger, Richard wrote:

> I have been under the impression, that Lars specifically approached 
> the authors to update and resubmit a new revision of the draft, before 
> this can move forward.
>

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Mon, 15 Nov 2010 11:27:24 +0100

Dear Richard;

Thank you for looking at TCP-Rehash.
Please see my comments inline.

Regards,
Bruno Mongazon

> After a casual look, it appears to me that a lightweight implementation of MP-TCP can have the same benefits, but does not require the opaque exchange of IPv4 addresses...

Yes an idea would be to have TCP-Rehash == lightweigth MPTCP
There are a few design diffferences that need to be looked at.

> Your use case - that the old L3 address is already no longer available at the time of the rehash - may need to be looked at in MPTCP though (iirc, they do a graceful session setup first (thus can w…

Right but... there is no real constraint on old address availability, 
thus the old address might still be available.
A key difference between TCP-Rehash and MPTCP is the session setup. With 
TCP-Rehash there is no setup, it is a straight move. If it fails, the 
connection is broken, this would happen anyway if L3 address changes and 
there is no "move" mechanism. Doing so is just opportunistic but 
deterministic. MPTCP is more complex since a new connection is setup 
before the old connection is being "moved".
 From design perspective, would it be that complex for MPTCP to handle 
rehash design ?

NAT is a different story (orthogonal i would say) and issue.

> Perhaps the effort would be better placed on making sure that such light-weight MPTCP implementations remain feasible, instead of defining an alternate method that is addressing only this one aspec…

To be honest i have both TCP-Rehash and MPTCP linux kernel source 
code... my intention is not to define an alternate method ! Rather i 
posted the TCP-Rehash draft with the intention to provide some 
additional work on the topic. Convergence and collaboration is of course 
to be considered. I think my work, although it was not disclosed, 
started sometimes ago, almost at early MPTCP.

Please let me know, if from the design point of view, the WG would 
consider the opportunity to have a lightweight MPTCP that would look 
like TCP-Rehash.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Nov 2010 14:54:29 +0200

Hi,

On 2010-11-15, at 12:27, Bruno Mongazon-Cazavet wrote:
> Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash.

given that the IETF is already working on MPTCP, it's a bit difficult to see why we should work on another extension to TCP that does some of what MPTCP does, but not all of it, and in a way that is not interoperable with it.

It's not like MPTCP will significantly increase the footprint of the network stack.

Lars

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Mon, 15 Nov 2010 15:03:41 +0100

> It's not like MPTCP will significantly increase the footprint of the network stack.

Sorry but yes it does.

The numbers are currently the following:

MP-TCP patch on 2.6.28 => 16270 Line Of Code
TCP-Rehash on 2.6.34 => 2357 Line Of Code

Percentages are currently the following (net/ipv4 sub-directory C files 
only, not counting the core nor header files):

MP-TCP on 2.6.28 => (16270 / 82925) * 100 ~= 20 %
TCP-Rehash on 2.6.34 => (2357 / 80977) * 100 ~= 3%

Giving the fact that the MP-TCP code i use does not provide yet "coupled 
congestion control" there are a few chance the trend can change.

So numbers do actually tell something logical: TCP-Rehash is designed 
with minimal functionality, MP-TCP provides more functionality.

I just wonder if MP-TCP can benefit from a behavior that would only cost 
a little (if ever, need to be checked) and provide a minimal behavior 
that can sometimes be sufficient.

I am free to discuss this and other's opinions are welcome.

Bruno.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Nov 2010 17:19:21 +0200

> TCP-Rehash on 2.6.34 => (2357 / 80977) * 100 ~= 3%

I don't believe that the MPTCP developers at the moment have made an attempt at minimizing their diff, so those numbers aren't very conclusive. I also don't think that the binary size of the final kernel will be much affected. But that line of argumentation isn't very fruitful to continue anyway. 

Does TCP-Rehash provide interesting functionality? Sure. Does it provide anything that MPTCP doesn't provide? No. If we weren't already doing MPTCP, then TCP-Rehash might have been interesting. But since we are doing MPTCP, I simply don't see the point of specifying a subset of it in a way that is incompatible.

Lars

---

From: <[email-masked]>
Date: Mon, 15 Nov 2010 15:39:43 +0000

> I don't believe that the MPTCP developers at the moment have made an attempt at minimizing their diff,

by running all the statements;on;the;same;line;separated;by;semi-colons;to;get;linecount;down?

> Does TCP-Rehash provide interesting functionality? Sure. Does it provide anything that MPTCP doesn't provide? No.

And it's fewer lines. A better question would be 'Is TCP-rehash missing anything important/necessary?'

> If we weren't already doing MPTCP, then TCP-Rehash might have been interesting.

That's not a good justification for not examining TCP-rehash.

I've seen other groups settle on a single solution very early, and then stick doggedly to that single solution and ignore other approaches. Fine for point solutions, but when there's a very large potential impact on the installed base, more due diligence on other approaches is called for imo.

> But since we are doing MPTCP, I simply don't see the point of specifying a
> subset of it in a way that is incompatible.

Lars, are you speaking as an individual contributor or as Area director here?

thanks

L.

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 16 Nov 2010 11:21:27 +0200

Bruno,

I've read your draft too and I agree with Richard, it seems to support a subset of what MPTCP does, only focusing on connection mobility. 
On top of that MPTCP allows connections to use multiple paths in parallel (providing reordering, congestion control, etc). 

Re-hash's aim seems to be increasing robustness for mobile client applications. I personally think multipath TCP is a better solution than re-hash because it can probe multiple paths in parallel and literally get the best service at any time. In contrast, re-hash allows connections to use a single address (e.g. 3g/wifi) at any time; this will give significantly worse performance when devices are truly mobile and link properties change quickly e.g. people driving or walking (this is a handwaving argument, we have not run any tests to prove this).

More importantly, I'd like to point out that this type of connection mobility is already implemented in mobile devices as far as I understand: the stack forcibly terminates all connections when their interface goes down and a new one is available, and the applications  reopen connections which will use the new interface. The apps have already been changed to support this. The apps that haven't been changed already probably don't care about this type of robustness that much. With this in mind, I reluctantly admit that MPTCP itself will bring little improvement to apps robustness; re-hash will bring none.

As a clarifying note to richard's comment earlier: MPTCP does support break-before-make mobility, as long as the new subflow is opened while both endpoints have state about the connection (i.e. the original subflow has not reach max timeouts). In practice, this means that if a client is mobile, loses its address and gains a new one in a reasonable amount of time, it will be able to add a subflow to the existing connection, hence supporting break-before-make mobilty.  As rehash, MPTCP does not support simultaneous mobility.

Cheers,
Costin

On 15 Nov 2010, at 12:27, Bruno Mongazon-Cazavet wrote:

> Right but... there is no real constraint on old address availability, thus the old address might still be available.
> A key difference between TCP-Rehash and MPTCP is the session setup. With TCP-Rehash there is no setup, it is a straight move. If it fails, the connection is broken, this would happen anyway if L3 address changes and there is no "move" mechanism. Doing so is just opportunistic but deterministic. MPTCP is more complex since a new connection is setup before the old connection is being "moved".
> From design perspective, would it be that complex for MPTCP to handle rehash design ?
> 
> To be honest i have both TCP-Rehash and MPTCP linux kernel source code... my intention is not to define an alternate method ! Rather i posted the TCP-Rehash draft with the intention to provide some additional work on the topic. Convergence and collaboration is of course to be considered. I think my work, although it was not disclosed, started sometimes ago, almost at early MPTCP.
>

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 16 Nov 2010 12:26:29 +0100

Costin,

Thanks for having read the draft.
I did not want to go into MPTCP vs Rehash considerations (and that's the 
reason i posted in TCPM wg) but it seems ineluctable.
So let's go deeper and please see inline.

I would also be interested to have additional opinions from wg members.

Regards,
Bruno

> I've read your draft too and I agree with Richard, it seems to support a subset of what MPTCP does, only focusing on connection mobility.

[bm] Yes. But connection mobility in the wide sense, including mobility 
and load-balancing.

> On top of that MPTCP allows connections to use multiple paths in parallel (providing reordering, congestion control, etc).

[bm] Yes. MPTCP relies on the "path" and "parallelism" concepts. 
TCP-Rehash excludes these concepts from the beginning of design. In 
particular, TCP-Rehash has not been designed according to a rule which 
states that a TCP connection can get benefits in using multiple paths in 
parallel. Moreover i would say that TCP-Rehash has been designed with 
exactly the reverse opinion in mind (philosophy): We don't know if and 
how we can take advantage using parallelism, so just provide a simple 
and lightweight mechanism to allow each TCP connection to be migrated on 
both ends agreement.

> Re-hash's aim seems to be increasing robustness for mobile client applications. I personally think multipath TCP is a better solution than re-hash because it can probe multiple paths in parallel an…

[bm] Right, MPTCP provide more functionnalities. However there is a cost 
(probing, TCP options overhead on all data). TCP-Rehash only aims to 
provide the minimal capability at the minimal cost. I personally think 
that providing alternatives is always a good option. As far as 
performance are concerned we probably need a closed look. I would not 
bet TCP-Rehash is not suited fro "truly mobile", since connection rehash 
involves only sending a TCP option in a outgoing packet.

> More importantly, I'd like to point out that this type of connection mobility is already implemented in mobile devices as far as I understand: the stack forcibly terminates all connections when their interface goes down and a new one is available, and the applications  reopen connections which will use the new interface. The apps have already been changed to support this.

[bm] TCP-Rehash is exactly done to avoid this by bringing the capability 
at transport level to the benefit of all applications. There are still a 
bunch of applications that do not implement such behavior, why should they ?

>   The apps that haven't been changed already probably don't care about this type of robustness that much. With this in mind, I reluctantly admit that MPTCP itself will bring little improvement to apps robustness; re-hash will bring none.

[bm] I disagree. Applications do care about robustness. Most of them 
need to handle socket() errors and in most case they fall into 
unavailability or interruption. With either MPTCP or TCP-Rehash they 
could keep the same code but just do not execute it because the 
transport has been improved. So MPTCP could bring minimal to high 
improvement and TCP-Rehash only minimal (but essential?) improvement.

> As a clarifying note to richard's comment earlier: MPTCP does support break-before-make mobility, as long as the new subflow is opened while both endpoints have state about the connection (i.e. the…

[bm] TCP-Rehash can be synced with address management in different and 
open manners. What could trigger an individual connection rehash is 
outside the scope of my draft. Trigger can be the address change of a 
single interface or additional interface(s) addition. There is no 
restriction although there might be strategies of common sense. For 
example i tried rehash in the following situations:

-pure handoff
-offloading some connections when multiple interfaces are available

Both rely on the same TCP enhancements (rehash) but the music is played 
in a different way. Just a matter of the director. In all cases, you 
cannot say Rehash does not support simultaneous mobility.

Regards,
Bruno.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 Nov 2010 13:48:12 +0200

> Lars, are you speaking as an individual contributor or as Area director here?

Individual. (Thanks for reminding me to make this clear.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Nov 2010 15:39:20 -0800

On 11/15/2010 4:54 AM, Lars Eggert wrote:
> given that the IETF is already working on MPTCP, it's a bit
> difficult to see why we should work on another extension to TCP that
> does some of what MPTCP does, but not all of it, and in a way that is
> not interoperable with it.

I had argued that MPTCP was trying to solve two separate issues (perhaps 
three):

1) use of more than one *path* between two endpoints at the same time

2) use of multiple endpoint IP addresses between two pairs at the same time

(3) shifting the addresses in #2 dynamically, i.e., not so much 
concurrent use as a sequence of uses

My concern, FWIW, remains that inferring #1 from #2 is just wrong. 
Beyond that concern, however, I didn't like the idea of bundling two 
separately useful features in a single system, since I didn't see the 
two as necessarily related anyway.

TCP-Rehash - good or bad, I don't know (I haven't looked in detail, but 
see below) - at least admits that there's utility to #3 independent of 
#1 and #2.

So I don't see this as related to MPTCP at all.

That said, I have other concerns, e.g., as to TCP-Rehash replicating 
work that has already been done in HIP, SHIM6, or just over tunnels in 
general.

FWIW, I'm also concerned about the fact that TCP *defines* its 
connections in terms of endpoint addresses, so the *semantics* needs to 
be updated if there's a corresponding redefinition of how the connection 
is now dissociated from those addresses.

But, again, this is not at all related to MPTCP to me.

Joe

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Wed, 17 Nov 2010 09:33:59 +0100

Hey Joe ;-)

Please see inline

> see below) - at least admits that there's utility to #3 independent of

[bm] correct.

> So I don't see this as related to MPTCP at all.

[bm] In fact, it is not.

> work that has already been done in HIP, SHIM6, or just over tunnels in

[bm] i tried to make it different from HIP and SHIM6.
It is not like HIP because TCP-Rehash does not deal at all with 
"Identity" but only end-point addresses.
It is not like SHIM6 nor tunnel approaches because TCP-Rehash is not an 
intermediate or inner layer.
It is more like MIT's TCP-Migrate or kind of approaches.

> is now dissociated from those addresses.

[bm] TCP-Rehash does not introduce new semantics. It is based on 
endpoint addresses and ports as regular TCP.
There is no dissociation and this is a major constraint of its design.