Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

From: <[email-masked]>
Date: Mon, 4 Jul 2011 16:23:30 +0100

Georg

Let me see if i understand your use case correctly (ie why your propose that "use only one path" is binding on the other end)
A "simple device" only has one air interface but wants to use MPTCP to perform break before make handover.
it wants to declare this to the other end, so that the other end (1) only sends data on one path at once, (2) sends MP-ADD-ADDR rather than MP-JOIN (to tell it about other interfaces)

how important is your use case? (I have an open mind) It creates some extra work, for instance in error handling  (MP-PRIO crosses with some other msg) and policy (Yoshifumi's example). 

Other ways of doing the same thing:
Simply don't respond to MP_JOIN; or have some equivalent option in MP-JOIN - think this would be quite hard to get to work cleanly
Have as an option in MP-CAPABLE - this seems cleaner to me. with your proposal the "simple device" needs to send MP-PRIO soon after MP-CAPABLE, but the far end may already have sent MP-JOINs. 

We probably ought to have a brief think how this might impact on the proxy scenario (ie where mptcp proxy handles mobility on behalf of the mobile device)

Best wishes,
phil
-----Original Message-----
From: Hampel, K Georg (K Georg) [mailto:[email-masked]] 
Sent: 30 June 2011 14:42
To: Yoshifumi Nishida
Cc: Eardley,PL,Philip,DES8 R; [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Yoshifumi,

There is no "use only THIS path". Instead, there is "use only ONE path". While this command is binding, it does not specify the path itself. Host_B can select this path from all available paths while honoring the associated use/don't use recommendations sent by Host_A. 

(For a simplified receiver on Host_A it is important to restrict data delivery to one path. Path selection is of lower priority and subject to the same constraints as in full-fledged MPTCP.)

"Use/Don't use" recommendations for non-existent paths should have no effect.

Conflicting interests: 
"Use/Don't use" flags are primarily recommendations which SHOULD be honored (this is the same as for the present MP_PRIO). Host_B may overwrite this SHOULD due to economical reasons, for instance.

If a certain interface on Host_A is not part of any recommended path, Host_B can assume that it is not up or has very poor local link quality. In this case, Host_B SHOULD not use the associated paths for technical reasons. 

We COULD replace SHOULD with MUST in this latter case. However, if a certain interface is completely inaccessible for extended time, Host_A can simply tear down the associated paths.

Georg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Thursday, June 30, 2011 6:04 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Georg,

In this proposal, if we specify a non-existing sub-connection and set
"use only this path", what will happen?
Also, I'm still wondering how to solve binding loop where both ends
have conflicted policies. (sorry i couldn't parse your previous
e-mail.)

Thanks,
--
Yoshifumi Nishida
[email-masked]

2011/6/29 Hampel, K Georg (K Georg) <[email-masked]>:
> Hi all,
>
>
>
> I'm proposing to revise the MP_PRIO option as outlined below. The revised
> version tries to accommodate the issues discussed recently.
>
>
>
> Please comment.
>
> Regards,
>
> Georg
>
>
>
> ========================================
>
> MP_PRIO sent by Host_A to Host_B contains the following fields:
>
>
>
> Path = (ADDR-ID-A, ADDR-ID-B), where
>
> ADDR-ID-A: one of Host_A's addresses; value 255 = all;
>
> ADDR-ID-B: one of Host_B's addresses; value 255 = all;
>
> B-flag: (use/don't use) path contained in this option
>
> S-flag: (use only one path/use any number of paths)
>
>
>
>
>
> Operation:
>
> - Host_A can refer to unavailable paths via available paths due to the
> explicit use of address-ids. This also permits sending an MP_PRIO option
> redundantly on multiple paths.
>
>
>
> - Host_A can refer to a specific interface, e.g. IP_A, by selecting all
> paths that terminate at this interface, i.e. path = (IP_A, all).
>
>
>
> - Through consecutive MP_PRIO messages, Host_A can specify (and update) the
> subset of paths it wants Host_B to consider for data transmission.
>
>
>
> - Host_B is not bound to use this subset of paths for data transmission.
> However, if a certain interface of Host_A is not contained in any of the
> paths of this subset, Host_B should consider this interface unavailable and
> not use any of the corresponding paths for data transmission.
>
>
>
> - The S-flag setting "use only one path" is binding. This path can be
> selected by Host_B subject to the same constraints as mentioned in the prior
> bullet. When an MP_PRIO option arrives, path-re-selection should always
> occur AFTER the B-flag- and path-fields of the MP_PRIO option have been
> evaluated, since they may change the subset of recommended paths.
>
>
>
> - If multiple MP_PRIO options are contained in one TCP options header, they
> should be evaluated in the order they appear in the header.
>
>
>
> - There is no explicit confirmation of MP_PRIO. Host_A can implicitly derive
> MP_PRIO's delivery from acks and/or packets arriving from Host B.
>
>
>
>
>
> Use cases/examples:
>
>
>
> 1. Set [IP_A, IP_B] as backup path:
>
> MP_PRIO: path = [IP_A, IP_B], B =(don't use), S =(use any number)
>
>
>
> 2. IP_A has become unavailable:
>
> MP_PRIO: path = [IP_A, all], B =(don't use), S =(use any number)
>
>
>
> 3. IP_A is available again:
>
> MP_PRIO: path=[IP_A, all], B =(use), S =(use any number)
>
>
>
> 4. Use only one path, doesn't matter which one:
>
> MP_PRIO: path=[all, all], B =(use), S =(use only one path)
>
>
>
> 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']:
>
> Add 2 MP_PRIOs into header:
>
> MP_PRIO: path = [IP_A, IP_B], B =(use), S =(either setting)
>
> MP_PRIO: path = [IP_A', IP_B'], B =(use), S =(use only one path)
>
>
>
>
>
> 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']:
>
> Add 2 MP_PRIOs into header:
>
> MP_PRIO: [IP_A, IP_B], B = (don't use), S = (either setting)
>
> MP_PRIO: [IP_A', IP_B'], B = (use), S = (use only one path)
>
>
>
>
>
> 7. Switch one path from interface IP_A to IP_A':
>
> Add 2 MP_PRIOs into header:
>
> MP_PRIO: [IP_A, all], B = (don't use), S = (either setting)
>
> MP_PRIO: [IP_A', all], B = (use), S = (use only one path)
>
>
>
>
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

---

From: "Ford, Alan" <[email-masked]>
Date: Mon, 4 Jul 2011 16:34:33 +0100

Hi Georg, all,

Looking at your proposal here, I see three key things being proposed
(correct me if I've missed anything):

1.       Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs.

2.       "Use only this path" flag.

3.       Above option is binding.

Point 1 - whilst, yes, this does identify a path, it may not be unique
since there are possibilities of multiple paths between the same
addresses but using different ports. This complicates matters, unless
you are happy that the option affects all paths using that address pair
(I probably would be happy with that, if we included this).

However, I cannot think of any scenario where Host-A, which knows all
about its own availability of addresses, would ever need to change the
priority on a path - from another path - that does not affect all paths
using that particular local address (ADDR-ID-A). The current proposal is
just to include local Address ID (i.e. ADDR-ID-A) if signalling from a
different subflow, and affecting all paths that match that criterion.
Is there any case where we need it to behave differently?

Point 2 - This is achievable per-address with Host-A sending a set of
MP_PRIO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to
high priority. Plus it can set high priority on a live path. This would
seem to be sufficient for every case I can think of.

Point 3 - I do not like this. It is not simply a case of saying "this
message is binding", you cannot do that on a unidirectional signalling
protocol. What if Host-B cannot (for some reason) adhere to that
request? If its local policy explicitly forbids using that costly
interface unless no other paths are available? We would need an error
message if it cannot be adhered to (or, as you say, Host-A could detect
that Host-B is still sending data). Then what? You drop the subflow?
(That's probably what you would have to do.) So you are back to where we
are now - there is no way of enforcing Host-B's behaviour. Given that, I
see no point in specifying a message to be binding when that cannot be
enforced.

To give another example... let's say that this was binding, and the path
then goes down. What does Host-B do in this case? Does it shift onto
other paths, or wait for Host-A to send a new MP_PRIO updating its
preferences? That is surely inefficient, especially if Host-A cannot
detect the path has gone down as fast as Host-B. This is exactly the
kind of case where Host-B should use its initiative and start using
backup paths. In the spec today, MP_PRIO is a request to the other host
that is expected to be adhered to unless there is a good reason not to -
essentially, this is exactly the same as what this behaviour would end
up as, once you start working through all the error cases. So I see no
reason to open this can of worms!

The short summary of my points above is that I am unconvinced as to the
benefit (or in the case of Point 3, feasibility) of making any of these
changes. I'm not against either 1 or 2 per se, I'm just keen to see the
use cases more clearly defined. I haven't seen any yet that cannot be
done with existing messages (with ADDR-ID added to MP_PRIO, anyway).

Regards,

Alan

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hampel, K Georg (K
Georg)
Sent: 30 June 2011 01:52
To: Hampel, K Georg (K Georg); [email-masked];
[email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the
Applicability of Multipath TCP to Wireless Access Networks

Hi all,

I'm proposing to revise the MP_PRIO option as outlined below. The
revised version tries to accommodate the issues discussed recently.

Please comment.

Regards,

Georg

 

Operation:

- Through consecutive MP_PRIO messages, Host_A can specify (and update)
the subset of paths it wants Host_B to consider for data transmission.

- Host_B is not bound to use this subset of paths for data transmission.
However, if a certain interface of Host_A is not contained in any of the
paths of this subset, Host_B should consider this interface unavailable
and not use any of the corresponding paths for data transmission. 

- The S-flag setting "use only one path" is binding. This path can be
selected by Host_B subject to the same constraints as mentioned in the
prior bullet. When an MP_PRIO option arrives, path-re-selection should
always occur AFTER the B-flag- and path-fields of the MP_PRIO option
have been evaluated, since they may change the subset of recommended
paths.

- If multiple MP_PRIO options are contained in one TCP options header,
they should be evaluated in the order they appear in the header.

- There is no explicit confirmation of MP_PRIO. Host_A can implicitly
derive MP_PRIO's delivery from acks and/or packets arriving from Host B.

Use cases/examples:

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 5 Jul 2011 09:58:09 -0500

Phil, all,

I suggest we separate the following 3 scenarios:
1) A simplified MPTCP implementation that can only handle path-selective operation
2) A host has only one air interface to talk to multiple networks
3) Operation with transparent proxy

These 3 points are independent from each other, e.g. a host may have multiple air interfaces but use a simplified MPTCP implementation, vv, etc. Let's see how to solve each of these points independently and then we can look at potential commonalities or conflicts among the solutions.

To 1)
Since the simplified MPTCP implementation can receive data only on one path (except short handover windows), it has to tell the remote sender to please send the data on only one path. This is why we need the "use only one path" flag and why it should be binding. This "only-one-path" requirement is independent from the specific path to be selected.

To 2)
Use case: A host with only one air interface moves forth and back between 2 networks while sustaining two subflows, one to each network. After every handover, the host needs to tell its peer that the new interface is up and the old one down. In case the old link breaks suddenly, the present MP_PRIO cannot be used to mark the old interface as "down" since the option has to be sent from this very interface, i.e. along the path that's "down". Therefore, I propose to add path-endpoint ADDR-IDs into MP_PRIO. This allows sending MP_PRIO on one path while referring to another.
In case the host anticipates the break of the old link, it can inform the peer on the OLD link about the imminent switch, i.e. BEFORE it occurs. This significantly reduces the effective downtime. For this purpose, the host must send MP_PRIO on the OLD path while referring to the NEW path. This, again, can be done by adding ADDR-IDs into MP_PRIO.

To 3)
The transparent MPTCP proxy must preemptively forward its own IP address to the MPTCP-capable host, and tell it to use ONLY THIS address for future MP_JOINs. The MPTCP host has NO clue that it's talking to a proxy. The message should NOT IMPLY subflow generation. I propose to simply add two 1-bit flags to the ADD_ADDR option. One means: JOIN RIGHT AWAY. The other means: USE ONLY THIS ADDRESS FOR FUTURE SUBFLOWS.

Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 04, 2011 11:24 AM
To: Hampel, K Georg (K Georg); [email-masked]
Cc: [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Georg

Best wishes,
phil
-----Original Message-----
From: Hampel, K Georg (K Georg) [mailto:[email-masked]] 
Sent: 30 June 2011 14:42
To: Yoshifumi Nishida
Cc: Eardley,PL,Philip,DES8 R; [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Yoshifumi,

Conflicting interests: 

Georg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Thursday, June 30, 2011 6:04 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Georg,

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 5 Jul 2011 13:02:54 -0500

Hi Alan, all,

You are bringing up multiple points. I have inserted comments (marked with [GH]). Thanks.

Regards,
Georg

________________________________
From: Ford, Alan [mailto:[email-masked]]
Sent: Monday, July 04, 2011 11:35 AM
To: Hampel, K Georg (K Georg); [email-masked]; [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Georg, all,

Looking at your proposal here, I see three key things being proposed (correct me if I've missed anything):

Point 1 - whilst, yes, this does identify a path, it may not be unique since there are possibilities of multiple paths between the same addresses but using different ports. This complicates matters, unless you are happy that the option affects all paths using that address pair (I probably would be happy with that, if we included this).

[GH]  This, indeed, would be quite confusing. I propose to interpret ADDR-ID as an END-POINT-ID, i.e. referring to a pair of (address, port). This would also comply with the ADD_ADDR option, which either provides BOTH, i.e. address AND port, or implicitly refers to a port in case the port is not included in the option.

However, I cannot think of any scenario where Host-A, which knows all about its own availability of addresses, would ever need to change the priority on a path - from another path - that does not affect all paths using that particular local address (ADDR-ID-A). The current proposal is just to include local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow, and affecting all paths that match that criterion.  Is there any case where we need it to behave differently?

[GH] I think there are 2 issues here:
The first one is: Why should a host EVER have preferences with respect to certain paths rather than solely certain local interfaces? If there are such reasons they automatically create the potential for conflicts and require a conflict resolution policy. The currently version of MP_PRIO seems to confirm that such reasons exist (use cases?) and the conflict resolution policy is: "Consider what I want but do what you like". Most interestingly, MP_PRIO does NOT support a straightforward method for a host to phrase preferences for a certain interface, which is a rather relevant feature (!!!). The solution I proposed allows doing that.
The second issue: Are there any reasons to announce path-/interface-preferences via other paths/interfaces? Cross references are either used pre-emptively, i.e. if the desired path/interface is not yet available, or retroactively, i.e. if the undesirable-flagged path/interface is not available any more. As always, it is easier to construct a use case that applies to interfaces rather than paths.
Here is a path-related use case though: Host A sustains IP_A1 and IP_A2 and host B sustains IP_B1 and IP_B2, where IP_A1, IP_B1 belong to one network (e.g. 3G) and IP_A2, IP_B2 to another (e.g. WLAN). The hosts sustain 4 subflows (all permutations) but only use (IP_A1, IP_B1) as active path. Host A (supporting only one radio) has to do a BBM handover to IP_A2 and it wishes to use (IP_A2, IP_B2) from the new interface. How can host A inform host B via the OLD interface (i.e. IP_A1), i.e. prior to BBM, that it should switch to (IP_A2, IP_B2)?

Point 2 - This is achievable per-address with Host-A sending a set of MP_PRIO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high priority. Plus it can set high priority on a live path. This would seem to be sufficient for every case I can think of.

[GH]  This flag has a DIFFERENT intention. "USE ONLY ONE PATH" means: "I cannot handle traffic from more than one path at a time (except path re-selection windows)". This flag is very important and it is independent of what path/interface is finally selected. It needs to be supported even if the sender has NO preference for any interface or path at all!

Point 3 - I do not like this. It is not simply a case of saying "this message is binding", you cannot do that on a unidirectional signalling protocol. What if Host-B cannot (for some reason) adhere to that request? If its local policy explicitly forbids using that costly interface unless no other paths are available? We would need an error message if it cannot be adhered to (or, as you say, Host-A could detect that Host-B is still sending data). Then what? You drop the subflow? (That's probably what you would have to do.) So you are back to where we are now - there is no way of enforcing Host-B's behaviour. Given that, I see no point in specifying a message to be binding when that cannot be enforced.

[GH] Again, this flag does not apply to any specific path or interface. Further, I really don't care if "binding" translates to MUST or SHOULD. I think it is more important to properly explain in the RFC what the consequences are in case host B does NOT comply with this flag sent by host A. It means: The performance will most likely go down the pipe and the host risks loosing connectivity all together.

To give another example... let's say that this was binding, and the path then goes down. What does Host-B do in this case? Does it shift onto other paths, or wait for Host-A to send a new MP_PRIO updating its preferences? That is surely inefficient, especially if Host-A cannot detect the path has gone down as fast as Host-B. This is exactly the kind of case where Host-B should use its initiative and start using backup paths. In the spec today, MP_PRIO is a request to the other host that is expected to be adhered to unless there is a good reason not to - essentially, this is exactly the same as what this behaviour would end up as, once you start working through all the error cases. So I see no reason to open this can of worms!

[GH] If the currently used path goes down, host B can simply pick another one. Again, "USE ONLY ONE PATH" does not refer to a specific path.

The short summary of my points above is that I am unconvinced as to the benefit (or in the case of Point 3, feasibility) of making any of these changes. I'm not against either 1 or 2 per se, I'm just keen to see the use cases more clearly defined. I haven't seen any yet that cannot be done with existing messages (with ADDR-ID added to MP_PRIO, anyway).

[GH] I have a counter question: Why does MP_PRIO allow specifying preferences for paths rather than interfaces given that the latter is more relevant than the former?

Regards,
Alan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: 30 June 2011 01:52
To: Hampel, K Georg (K Georg); [email-masked]; [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi all,

I'm proposing to revise the MP_PRIO option as outlined below. The revised version tries to accommodate the issues discussed recently.

Please comment.

Regards,

Georg

Operation:

- Host_A can refer to unavailable paths via available paths due to the explicit use of address-ids. This also permits sending an MP_PRIO option redundantly on multiple paths.

- Host_A can refer to a specific interface, e.g. IP_A, by selecting all paths that terminate at this interface, i.e. path = (IP_A, all).

- Through consecutive MP_PRIO messages, Host_A can specify (and update) the subset of paths it wants Host_B to consider for data transmission.

- Host_B is not bound to use this subset of paths for data transmission. However, if a certain interface of Host_A is not contained in any of the paths of this subset, Host_B should consider this interface unavailable and not use any of the corresponding paths for data transmission.

- The S-flag setting "use only one path" is binding. This path can be selected by Host_B subject to the same constraints as mentioned in the prior bullet. When an MP_PRIO option arrives, path-re-selection should always occur AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated, since they may change the subset of recommended paths.

- If multiple MP_PRIO options are contained in one TCP options header, they should be evaluated in the order they appear in the header.

- There is no explicit confirmation of MP_PRIO. Host_A can implicitly derive MP_PRIO's delivery from acks and/or packets arriving from Host B.

Use cases/examples:

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 6 Jul 2011 11:00:44 +0100

Georg, all,

Thanks - comments inline... Things make sense now. I would be interested
in hearing wider comments, however, on the usefulness or not of the 'S'
flag ("use only one path at a time").

Regards,

Alan

Sent: 05 July 2011 19:03
To: Ford, Alan; [email-masked]; [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the
Applicability of Multipath TCP to Wireless Access Networks

Hi Alan, all,

You are bringing up multiple points. I have inserted comments (marked
with [GH]). Thanks.

Regards,

Georg

Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the

Hi Georg, all,

[GH]  This, indeed, would be quite confusing. I propose to interpret
ADDR-ID as an END-POINT-ID, i.e. referring to a pair of (address, port).
This would also comply with the ADD_ADDR option, which either provides
BOTH, i.e. address AND port, or implicitly refers to a port in case the
port is not included in the option. 

[AF] OK, so architecturally this makes a certain amount of sense: if no
port was specified in ADD_ADDR, then the ADDR-ID is for (addr, *), but
if a port is specified, it's for (addr, port). For MP_JOIN, it would
always be (addr, port). But...

The first one is: Why should a host EVER have preferences with respect
to certain paths rather than solely certain local interfaces? 

[AF] Indeed, this is my issue with mapping ADDR-ID to (addr, port) - I
cannot see any cases for it.

If there are such reasons they automatically create the potential for
conflicts and require a conflict resolution policy. The currently
version of MP_PRIO seems to confirm that such reasons exist (use cases?)
and the conflict resolution policy is: "Consider what I want but do what
you like". 

[AF] MP_PRIO does not currently consider that issue. The conflict
resolution is for the scenario where each endpoint has a different
preferred path for a single direction of traffic.

Most interestingly, MP_PRIO does NOT support a straightforward method
for a host to phrase preferences for a certain interface, which is a
rather relevant feature (!!!). The solution I proposed allows doing
that.

[AF] If ADDR-ID refers to a single source address (which is my
preference), then MP_PRIO with ADDR-ID will work here.

The second issue: Are there any reasons to announce
path-/interface-preferences via other paths/interfaces? Cross references
are either used pre-emptively, i.e. if the desired path/interface is not
yet available, or retroactively, i.e. if the undesirable-flagged
path/interface is not available any more. As always, it is easier to
construct a use case that applies to interfaces rather than paths.

Here is a path-related use case though: Host A sustains IP_A1 and IP_A2
and host B sustains IP_B1 and IP_B2, where IP_A1, IP_B1 belong to one
network (e.g. 3G) and IP_A2, IP_B2 to another (e.g. WLAN). The hosts
sustain 4 subflows (all permutations) but only use (IP_A1, IP_B1) as
active path. Host A (supporting only one radio) has to do a BBM handover
to IP_A2 and it wishes to use (IP_A2, IP_B2) from the new interface. How
can host A inform host B via the OLD interface (i.e. IP_A1), i.e. prior
to BBM, that it should switch to (IP_A2, IP_B2)?

[AF] We are in agreement here, I am now convinced of the benefit - as
I've said earlier, we'll ADDR-ID to MP_PRIO - it solves this issue.

[GH]  This flag has a DIFFERENT intention. "USE ONLY ONE PATH" means: "I
cannot handle traffic from more than one path at a time (except path
re-selection windows)". This flag is very important and it is
independent of what path/interface is finally selected. It needs to be
supported even if the sender has NO preference for any interface or path
at all!

[AF] Ah! Now I fully understand what you are getting at. Although, this
is more "mobile" TCP rather than "multipath" TCP. Defining error
handling such as in the examples I give below, however, is still very
relevant...

[GH] Again, this flag does not apply to any specific path or interface.
Further, I really don't care if "binding" translates to MUST or SHOULD.
I think it is more important to properly explain in the RFC what the
consequences are in case host B does NOT comply with this flag sent by
host A. It means: The performance will most likely go down the pipe and
the host risks loosing connectivity all together.

[AF] Understood.

[GH] If the currently used path goes down, host B can simply pick
another one. Again, "USE ONLY ONE PATH" does not refer to a specific
path.

[AF] So, you would envisage two paths: Path-A has high prio (B=0),
Path-B has backup prio (B=1). The 'S'  flag is also set to 1. This means
the sender can only choose one path at a time. If a sender thinks Path-A
has gone down, it will switch to Path-B. Note, of course, that the
receiving host may still have Path-A up so there may be continuity
problems, but I can see the specific use cases you are requiring this
for, now.

[GH] I have a counter question: Why does MP_PRIO allow specifying
preferences for paths rather than interfaces given that the latter is
more relevant than the former?

[AF] Because, when we originally designed it, we did not think it was
needed to send it from any other path, and therefore it should apply
only to the path on which it was sent (that being the logical
information you could infer from the signal). Per-path reduced any error
conditions we need to cope with (such as conflicting prio flags in
MP_JOINs).

Regards,

Alan

Hi all,

Please comment.

Regards,

Georg

 

Operation:

 

Use cases/examples:

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 6 Jul 2011 12:29:09 -0500

Alan, all,

It may make sense to insert the "USE_ONLY_ONE_PATH_AT_A_TIME" - flag into MP_CAPABLE rather than MP_PRIO.

"Being of low complexity" won't change during the lifetime of the connection. MP_PRIO, in contrast, signals changes to dynamic properties (i.e. path/interface preferences).

Regards,

Georg

Sent: Wednesday, July 06, 2011 6:01 AM

Georg, all,

Thanks - comments inline... Things make sense now. I would be interested in hearing wider comments, however, on the usefulness or not of the 'S' flag ("use only one path at a time").

Regards,
Alan

Hi Alan, all,

Regards,
Georg

Hi Georg, all,

[AF] OK, so architecturally this makes a certain amount of sense: if no port was specified in ADD_ADDR, then the ADDR-ID is for (addr, *), but if a port is specified, it's for (addr, port). For MP_JOIN, it would always be (addr, port). But...

[GH] I think there are 2 issues here:
The first one is: Why should a host EVER have preferences with respect to certain paths rather than solely certain local interfaces?

[AF] Indeed, this is my issue with mapping ADDR-ID to (addr, port) - I cannot see any cases for it.

If there are such reasons they automatically create the potential for conflicts and require a conflict resolution policy. The currently version of MP_PRIO seems to confirm that such reasons exist (use cases?) and the conflict resolution policy is: "Consider what I want but do what you like".

[AF] MP_PRIO does not currently consider that issue. The conflict resolution is for the scenario where each endpoint has a different preferred path for a single direction of traffic.

Most interestingly, MP_PRIO does NOT support a straightforward method for a host to phrase preferences for a certain interface, which is a rather relevant feature (!!!). The solution I proposed allows doing that.

[AF] If ADDR-ID refers to a single source address (which is my preference), then MP_PRIO with ADDR-ID will work here.

[AF] We are in agreement here, I am now convinced of the benefit - as I've said earlier, we'll ADDR-ID to MP_PRIO - it solves this issue.

[AF] Ah! Now I fully understand what you are getting at. Although, this is more "mobile" TCP rather than "multipath" TCP. Defining error handling such as in the examples I give below, however, is still very relevant...

[AF] Understood.

[AF] So, you would envisage two paths: Path-A has high prio (B=0), Path-B has backup prio (B=1). The 'S'  flag is also set to 1. This means the sender can only choose one path at a time. If a sender thinks Path-A has gone down, it will switch to Path-B. Note, of course, that the receiving host may still have Path-A up so there may be continuity problems, but I can see the specific use cases you are requiring this for, now.

[AF] Because, when we originally designed it, we did not think it was needed to send it from any other path, and therefore it should apply only to the path on which it was sent (that being the logical information you could infer from the signal). Per-path reduced any error conditions we need to cope with (such as conflicting prio flags in MP_JOINs).

Regards,
Alan

Hi all,

Please comment.

Regards,

Georg

Operation:

Use cases/examples:

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 14:24:13 +0100

Thanks Georg, I found this very helpful

On 1), this sounds like you have in mind defining an MPTCP-lite protocol. I don't think this is part of our charter, so we shouldn't worry about it. 

On 2), we seem to have emerging consensus to add ADDR-ID to MP-PRIO. There is an open issue whether this is {IP address} or {IP address, port} - the former seems to be favoured (if i read the various emails right)

On the flag, "Use only one path" - the use case is one where MPTCP is being used to do mobility (break before make) with a device that only supports one interface. I'm not sure we yet have consensus whether this is important enough to add. May be easier to resolve face to face.

If the flag is added, there are a couple of issues,
- is it an indicative hint to the other end (~MAY), or a very strong hint (~SHOULD)(*) that the other end only uses one interface?  (*)(i don't think Georg is proposing MUST)
- is the flag in MP-PRIO or MP-CAPABLE? (this affects possible error cases we should think about, and how to fall-back if the MAY/SHOULD is ignored) (personally the latter seems more logical)

Phil/

-----Original Message-----
From: Hampel, K Georg (K Georg) [mailto:[email-masked]] 
Sent: 05 July 2011 15:58
To: Eardley,PL,Philip,DES8 R; [email-masked]
Cc: [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Phil, all,

To 1)

To 2)

To 3)

Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 04, 2011 11:24 AM
To: Hampel, K Georg (K Georg); [email-masked]
Cc: [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Georg

Best wishes,
phil
-----Original Message-----
From: Hampel, K Georg (K Georg) [mailto:[email-masked]] 
Sent: 30 June 2011 14:42
To: Yoshifumi Nishida
Cc: Eardley,PL,Philip,DES8 R; [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Yoshifumi,

Conflicting interests: 

Georg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Thursday, June 30, 2011 6:04 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Georg,

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 7 Jul 2011 09:28:44 -0500

Hi Phil, 

Thanks for your response. Recent ML discussions have helped clarifying some of the issues you are bringing up.

To your points:

To 1) Do we want a MPTCP-lite protocol? No! Instead, we propose a highly simplified host realization, which supports a slightly reduced feature set but complies with the present protocol and is interoperable with a full-fledged MPTCP peer. Since the simplified host realization can be implemented outside the kernel (!) it permits much easier roll-out of MPTCP.

To 2) Add ADDR-ID to MP-PRIO: We propose to insert into MP_PRIO an EXPLICIT reference to either an interface or a path. Indeed, there seems to be principal agreement that such EXPLICIT references make sense. We solely need to resolve the details. I presently see a potential problem in combining an explicit INTERFACE reference with an implicit PATH reference. 
  
USE_ONLY_ONE_PATH: This name is misleading. In verbose form, it means: "Please send data on only one path at a time." This flag is independent of any preferences for a particular path which may not even exist or which may be subject to change over time. The USE_ONLY_ONE_PATH flag allows a host to restrict operation to path-selective mode in order to save buffer space and processing overhead. It would make sense to include this flag into MP_CAPABLE and communicate interface or path preferences via MP_PRIO. 

Thanks.
Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 07, 2011 9:24 AM
To: Hampel, K Georg (K Georg); [email-masked]
Cc: [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Phil/

-----Original Message-----
From: Hampel, K Georg (K Georg) [mailto:[email-masked]] 
Sent: 05 July 2011 15:58
To: Eardley,PL,Philip,DES8 R; [email-masked]
Cc: [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Phil, all,

To 1)

To 2)

To 3)

Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 04, 2011 11:24 AM
To: Hampel, K Georg (K Georg); [email-masked]
Cc: [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Georg

Best wishes,
phil
-----Original Message-----
From: Hampel, K Georg (K Georg) [mailto:[email-masked]] 
Sent: 30 June 2011 14:42
To: Yoshifumi Nishida
Cc: Eardley,PL,Philip,DES8 R; [email-masked]; Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Yoshifumi,

Conflicting interests: 

Georg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Thursday, June 30, 2011 6:04 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Hi Georg,

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 7 Jul 2011 09:49:38 -0500

Olivier, all,

There may be cases where omitting DSS-options in bulk transfers is considered desirable to enhance bandwidth efficiency.

I therefore suggest adding a flag into MP_CAPABLE which indicates if mapping updates are to be sent reliably or if the sender can apply bandwidth optimization.

Regards,

Georg 

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Wednesday, June 29, 2011 3:34 AM
To: Ford, Alan
Cc: Hampel, K Georg (K Georg); [email-masked]; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Alan,

> 3.7: This idea is sensible, but I would be reluctant to mandate it.  I
> think some text like this may be sufficient: "An implementation SHOULD
> send DSS options that cover multiple segments multiple times, to reduce
> the need for unnecessary buffering at the receiver.  It is RECOMMENDED
> that a sender repeats the DSS option until a DATA ACK for some data
> covered by this mapping is received."

I would suggest to wait until we get more experience with the MPTCP
implementations and their behaviour in the real Internet before
discussing optimisations like this one. A reasonable solution based on
our understanding of the operations of MPTCP today is to put a DSS
option inside each segment. I would suggest to put text that recommends
experiments with lower frequency transmission of the DSS option but
would wait for the results of these experiments before mandating
anything in the spec. There are subtle interactions between DSS and the
TCP segment offload capable itnerfaces that need to be analysed before
mandating anything on this

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be