Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.txt

From: [email-masked]
Date: Mon, 11 Jul 2011 08:53:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF.

	Title           : TCP Extensions for Multipath Operation with Multiple Addresses
	Author(s)       : Alan Ford
                          Costin Raiciu
                          Mark Handley
                          Olivier Bonaventure
	Filename        : draft-ietf-mptcp-multiaddressed-04.txt
	Pages           : 59
	Date            : 2011-07-11

   TCP/IP communication is currently restricted to a single path per
   connection, yet multiple paths often exist between peers.  The
   simultaneous use of these multiple paths for a TCP/IP session would
   improve resource usage within the network, and thus improve user
   experience through higher throughput and improved resilience to
   network failure.

   Multipath TCP provides the ability to simultaneously use multiple
   paths between peers.  This document presents a set of extensions to
   traditional TCP to support multipath operation.  The protocol offers
   the same type of service to applications as TCP (i.e. reliable
   bytestream), and provides the components necessary to establish and
   use multiple TCP flows across potentially disjoint paths.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-04.txt

---

From: "Ford, Alan" <[email-masked]>
Date: Mon, 11 Jul 2011 17:03:39 +0100

Hi all,

We've updated this version of the draft to take into account the review
comments we have had since the last IETF (thanks especially to Stein and
Andrew for those). A few minor technical tweaks have been made, and
language generally improved (plus, Section 2 seemed to cause several
readers confusion so we've tried a different approach for the overview).

Notably, following on from the interesting discussions about mobility
(thanks Georg), we have added Address ID to the MP_PRIO option for
signalling from other paths, and clarified the behaviour of this option.

What we have not yet added is the idea of a "use only one path" flag. It
would make sense to exchange this in the MP_CAPABLE exchange, in the
same way as the checksum flag is (with the logic that if either or both
host requests the use of only one path, only one path should be used).
But this is a reasonably significant change to MPTCP's functionality
(even if it is only one bit) and so I think it would be worth a little
more discussion before it is added to the draft. I will not be in
Quebec, but I hope that some useful discussions can be had around this
and more.

Regards,
Alan

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of [email-masked]
> Sent: 11 July 2011 16:53
> To: [email-masked]
> Cc: [email-masked]
> Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-
> 04.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Multipath TCP Working
> Group of the IETF.
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 11 Jul 2011 20:23:09 -0500

Hi Alan, all,

I have read through parts of the updated WG draft "draft-ietf-mptcp-multiaddressed-04.txt". The modification to MP_PRIO is well appreciated. I think it sufficiently covers the need for an explicit reference to the sender's local interfaces. Also, the clarifications to BBM are helpful.

I am stumbling over another (and older) issue in the draft, where I need clarification. This may also resolve the "use only one path"-flag issue:  

The end of section 3.5 states:

"When a connection is in fallback mode, only one subflow can send data
   at a time.  Otherwise, the receiver would not know how to reorder the
   data.  However, subflows can be opened and closed as necessary, as
   long as a single one is active at any point."

Assume a host is in fallback mode, opens up a new subflow and switches from the old subflow to the new subflow. Here are the questions:

Q1: Before the host switches, it must send a DSS on the OLD subflow to create a new mapping (the mapping is new since there was not mapping in fallback mode). The first packets sent on the NEW subflow also have to carry DSSs for the same reason. Correct?

Q2: I assume that "..as long as a single one is active at any point" still allows retransmissions to occur on the same subflow even if the "active" subflow has changed between initial transmission and retransmission. Correct?

Q3: Does the peer have to send data ACKs in response to DSS carrying packets?

Q4: After the host has switched to the NEW subflow and received ACKs (or data ACKs) to all packets on the OLD subflow, host and peer can forget the DSN mapping again since they are in fallback mode. This also permits middleboxes to alter payload again. Correct?

Q4: When the host is in fallback mode, the peer must also be in fallback mode. Does the peer have to follow the host's subflow switch or can it keep transmitting on the old subflow?

Q5: If my suggestions of Q1 to Q3 are correct, a host should be able to enforce "use only one path at a time" by simply resorting to fallback mode. That still keeps all options open for path-selective operation. Correct?

Thanks,

Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ford, Alan
Sent: Monday, July 11, 2011 12:04 PM
To: [email-masked]
Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.txt

Hi all,

Regards,
Alan

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 21 Jul 2011 14:36:36 +0100

Hi Georg,

Sorry for the delay in replying. I think you've found an area that is
yet to be properly fleshed out. Some thoughts/comments inline...

> From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-
> lucent.com]
> Sent: 12 July 2011 02:23
> To: Ford, Alan; [email-masked]
> Subject: RE: [multipathtcp] I-D
Action:draft-ietf-mptcp-multiaddressed-
> 04.txt
> 
> Hi Alan, all,
> 
> I have read through parts of the updated WG draft "draft-ietf-mptcp-
> multiaddressed-04.txt". The modification to MP_PRIO is well
> appreciated. I think it sufficiently covers the need for an explicit
> reference to the sender's local interfaces. Also, the clarifications
to
> BBM are helpful.
> 
> I am stumbling over another (and older) issue in the draft, where I
> need clarification. This may also resolve the "use only one path"-flag
> issue:
> 
> Assume a host is in fallback mode, opens up a new subflow and switches
> from the old subflow to the new subflow. Here are the questions:
> 
> Q1: Before the host switches, it must send a DSS on the OLD subflow to
> create a new mapping (the mapping is new since there was not mapping
in
> fallback mode). The first packets sent on the NEW subflow also have to
> carry DSSs for the same reason. Correct?

The intention was for the first packet on a subflow in fallback mode to
carry the DSS, and nothing else.

So every new subflow would need a DSS option at the start, but I don't
think there is any need to send one on the old subflow.

> Q2: I assume that "..as long as a single one is active at any point"
> still allows retransmissions to occur on the same subflow even if the
> "active" subflow has changed between initial transmission and
> retransmission. Correct?

Hmm. Haven't thought of that particular corner case yet.

I believe when we wrote that text we had meant "active" in terms of "not
been closed" but I can't see any harm in what you are suggesting.

So yes, that sounds ok.

> Q3: Does the peer have to send data ACKs in response to DSS carrying

Not in the case of fallback.

> Q4: After the host has switched to the NEW subflow and received ACKs
> (or data ACKs) to all packets on the OLD subflow, host and peer can
> forget the DSN mapping again since they are in fallback mode. This
also
> permits middleboxes to alter payload again. Correct?

Hmm. I'm not sure this will work (and this may be a flaw with the
subflow changing in fallback too).

The DSS will map the first octet of the subflow to a given data sequence
number for an infinite length.

BUT: if a new subflow is started to take over, but the DSN given does
not match what the receiver thinks the end DSN of the former subflow was
(if a middlebox inserted or removed data), then what does the receiver
do?

This would appear to be a problem. Not sure how we can resolve this.

> Q4: When the host is in fallback mode, the peer must also be in
> fallback mode. Does the peer have to follow the host's subflow switch
> or can it keep transmitting on the old subflow?

Only a single subflow should be in bidirectional use at any one time.

> Q5: If my suggestions of Q1 to Q3 are correct, a host should be able
to
> enforce "use only one path at a time" by simply resorting to fallback
> mode. That still keeps all options open for path-selective operation.
> Correct?

I see you argument here and it's an interesting one.

Unfortunately fallback mode as it stands appears to have one or two
issues with the concept of switching subflows. I don't think it can work
as it stands. We either need to redefine fallback mode so that it can
only use one subflow forever (which I think is closer to the original
intention), or find some way of switching subflows without needing to
send the DSN - which I think would be difficult to do reliably.

Worth thinking about some more - it would be good to work out if it is
possible or not to achieve this switching capability.

Regards,
Alan

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 21 Jul 2011 15:06:41 -0500

Hi Alan,

Thanks for the response.

I also don't see a way of doing a reliable switch of subflows in fallback mode. It almost seems counterintuitive: How should you switch subflows without (uncorrupted) DSS which were introduced for the purpose of switching subflows. 

Georg

-----Original Message-----
From: Ford, Alan [mailto:[email-masked]] 
Sent: Thursday, July 21, 2011 9:37 AM
To: Hampel, K Georg (K Georg); [email-masked]
Subject: RE: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.txt

Hi Georg,

to
in

So yes, that sounds ok.

also

to

Regards,
Alan

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 24 Jul 2011 02:50:58 -0700

> This would appear to be a problem. Not sure how we can resolve this.

How about sending Data ACK from the receiver during 3 way handshake to
indicate the correct DSS Map for the previous connection?

--
Yoshifumi Nishida
[email-masked]

---

From: Alan Ford <[email-masked]>
Date: Sun, 24 Jul 2011 23:26:05 +0100

> indicate the correct DSS Map for the previous connection?

So in those circumstances, what would the sender do if the Data ACK did not
match the length of data it had thought it had sent? The point of fallback
is to allow middleboxes to mess with data and MPTCP keeps out of the way.

We send a mapping for fallback in order to unambiguously state from which
point in the data stream MPTCP is giving up.

If a single subflow is open, that is fine. The philosophical question is, if
we want to support multiple subflows, what does that mean?

All problems with data sequence numbers would disappear if it was safe to
open another subflow once the other one was FINned (NB that permits
retransmissions). No data sequence numbers would be exchanged; the receiver
would continue the data delivery to the application from where it was left
off.

Is that viable? There would be error cases with new subflows opened before
old ones are FINned - then what? And, are there security implications?

I am not sure that this is a solid solution. Hmm.

Regards,
Alan

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Sun, 24 Jul 2011 20:38:34 -0500

Alan, Yoshifumi,

I have two questions with respect to your comments on fallback mode:

1)       What should a MPTCP sender do in fallback mode, when it receives a FIN on the only subflow? I guess the most logical thing would be to behave like TCP: send ACK but no FIN until there are no more data to send. With this policy, FIN could not be used to migrate to another subflow. This means that MPTCP would have to change the standard TCP policy.

2)       A general question: Should subflow migration be permitted when the hosts have no certainty if payload has been rewritten or not? How bad are payload-rewriting middleboxes? Assume there is an ALG middle box which checks if the payload contains English text and then translates it to German. Would it make any sense to migrate the session in this case? May be this example is too far-fetched. But it illustrates the problem of bounding the term "payload rewriting".

Regards,

Georg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Ford
Sent: Sunday, July 24, 2011 6:26 PM
To: Yoshifumi Nishida
Cc: [email-masked]
Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.txt

On 24 July 2011 10:50, Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>> wrote:

So in those circumstances, what would the sender do if the Data ACK did not match the length of data it had thought it had sent? The point of fallback is to allow middleboxes to mess with data and MPTCP keeps out of the way.

We send a mapping for fallback in order to unambiguously state from which point in the data stream MPTCP is giving up.

If a single subflow is open, that is fine. The philosophical question is, if we want to support multiple subflows, what does that mean?

All problems with data sequence numbers would disappear if it was safe to open another subflow once the other one was FINned (NB that permits retransmissions). No data sequence numbers would be exchanged; the receiver would continue the data delivery to the application from where it was left off.

Is that viable? There would be error cases with new subflows opened before old ones are FINned - then what? And, are there security implications?

Regards,
Alan

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 25 Jul 2011 01:14:46 -0700

Hi Alan,

> is to allow middleboxes to mess with data and MPTCP keeps out of the way.

I might miss some points, but I guess the sender would have 2 choices here.

1: reset the subflow
2: recreate Data seq mapping based on Data ACK
(we'll also need to presume the receiver ignores all packets from the
old connection
  after it sends Data ACK)

1 is simple and more secure, but might not be very efficient.
2 is ugly, but we already allowed middleboxes to mess with data. I
believe this also means
   we allowed Data seq mapping to be messed.  So, some adjustments
will be required anyway
   if we want to continue the session.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Alan Ford <[email-masked]>
Date: Tue, 26 Jul 2011 22:40:38 +0100

Hi Georg, all,

I think it's fair to say we don't know all the corner cases where fallback
will be used and what will happen on the wire. We've made the best,
comprehensive design we can given the constraints at this stage.

To take your extreme example, the fallback should mean that the subflow
falls back as soon as data has been altered, so that the German translation
carries on - but there is an issue of what happens to the data on the
non-translated subflow: quite easily data could get corrupted here; it is
difficult to see how we could work around this.

To jump back to your point 1, however: we have already determined we need an
MPTCP state machine over and above the TCP state machine to cope with
subflows closing without the MPTCP connection being DATA_FINned. It would
seem feasible that this could also exist in fallback mode, where the MPTCP
state machine operates simply as a timeout, allowing a new subflow to be
created after the closure of an old one without the whole MPTCP connection
state being lost, and thus the data transfer continuing. I feel, however,
that more experimental deployment experience is required before we can say
for sure that this is valid behaviour.

Regards,
Alan

On 25 July 2011 02:38, Hampel, K Georg (K Georg) <
[email-masked]> wrote:

>  Alan, Yoshifumi,****
>
> ** **
>
> I have two questions with respect to your comments on fallback mode:****
>
> ** **
>
> **1)       **What should a MPTCP sender do in fallback mode, when it
> receives a FIN on the only subflow? I guess the most logical thing would be
> to behave like TCP: send ACK but no FIN until there are no more data to
> send. With this policy, FIN could not be used to migrate to another subflow.
> This means that MPTCP would have to change the standard TCP policy.****
>
> ** **
>
> **2)       **A general question: Should subflow migration be permitted
> when the hosts have no certainty if payload has been rewritten or not? How
> bad are payload-rewriting middleboxes? Assume there is an ALG middle box
> which checks if the payload contains English text and then translates it to
> German. Would it make any sense to migrate the session in this case? May be
> this example is too far-fetched. But it illustrates the problem of bounding
> the term “payload rewriting”.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Georg****
>
> ** **
>
> ** **
>  ------------------------------
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Alan Ford
> *Sent:* Sunday, July 24, 2011 6:26 PM
> *To:* Yoshifumi Nishida
> *Cc:* [email-masked]
> *Subject:* Re: [multipathtcp] I-D
> Action:draft-ietf-mptcp-multiaddressed-04.txt****
>
> ** **
>
> ** **
>
> On 24 July 2011 10:50, Yoshifumi Nishida <[email-masked]> wrote:**
> **
>
> 2011/7/21 Ford, Alan <[email-masked]>:****
>
>
> > This would appear to be a problem. Not sure how we can resolve this.****
>
> indicate the correct DSS Map for the previous connection?****
>
> ** **
>
> is to allow middleboxes to mess with data and MPTCP keeps out of the way.*
> ***
>
> ** **
>
> point in the data stream MPTCP is giving up.****
>
> ** **
>
> If a single subflow is open, that is fine. The philosophical question is,
> if we want to support multiple subflows, what does that mean?****
>
> ** **
>
> off.****
> ** **
> old ones are FINned - then what? And, are there security implications?****
>
> ** **
>
> I am not sure that this is a solid solution. Hmm.****
>
> ** **
>
> Regards,****
>
> Alan****
>
> ** **
>