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

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 2 Aug 2011 13:07:18 -0500

All,

While there was positive response in the WG meeting to add a transparent-proxy indicator flag to ADD_ADDR, the present design of this MPTCP option doesn't provide any space for this feature. I'm seeing 3 ways to accommodate this flag:
-          Add an additional byte to the option. Problem: Option is already long especially for IPv6 addresses.
-          Overload the subtype field. Problem: This would essentially create a new MPTCP option.
-          Use the IP version field (the IP version can be derived from the IP address length). Problem: Potential conflict for future IP versions (unlikely).

As mentioned earlier, the ADD_ADDR option may also convey the request for MP_JOIN. This request is independent of transparent-proxy indication and needs to be carried by a separate flag.

Georg

________________________________
From: Ford, Alan [mailto:[email-masked]]
Sent: Tuesday, June 21, 2011 5:50 AM
To: Hampel, K Georg (K Georg); [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

Hello Georg, Thierry,

Thanks for writing this - it covers an important and interesting topic. I've had a chance to read it, now, and have some comments.

3.3: It is definitely intentional that you can use MPTCP with no changes to send data resiliently on many paths. I'll expand the text in the protocol draft slightly to discuss processing the same mappings on different subflows.

3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid concern and one that we discuss considerably in the API draft.  It is an issue where users are best placed to drive the development of solutions.

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."

"Path Availability" - this is where I get confused as to what the goal of this is. Can you give an example scenario where this would be useful?
Throughout the rest of this document, I struggle to see what difference there is between path (or interface) availability, and address availability.  We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of availability of an address (interface) on a host.  What is (UN)AVAIL_ADDR giving over and above this? Why separate the creation of the mapping and the signalling of the availability?

Some points on 4.4:

Yes, MP_PRIO is not binding, although the expectation is that a host should have a good reason for ignoring it (such as if the path appears dead to the host, or it costs too much money) - I can't see that we can change that.  If an end host was desperate to stop receiving traffic on an interface, it could drop the subflow.

If I understand your comment correctly, you'd like to be able to switch a single path to B=0 and all the others to B=1 in one go, and this is the purpose of MP_SELECT?  I guess we could adapt MP_PRIO to achieve this, by having another value that means "use me and me alone".  Although I think I need more convincing that it adds value!

In 4.4.2, you talk about BBM in the scenario of a radio knowing that it is going to take down its interface to attach to a new network.  You can do this already cleanly - just FIN the old path (without a DATA FIN) and bring up the new one.  What is your proposal adding?

5.1 is an interesting problem and one that Mark led some discussion of at the last IETF.  As with the discussion about AVAIL_ADDR, I don't see the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting idea that I need to think about some more!

Regards,
Alan

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

All,

We have uploaded a new I-D.

Title: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

Authors: Georg Hampel, Thierry Klein

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireless-networks/

Abstract:

This document analyses the applicability of Multipath TCP to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits as well as technical and functional obstacles encountered in the current version of the protocol.  Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks.

IMPORTANT COMMENTS: Apart from a variety of recommendations for research, the I-D proposes the following signaling and policy enhancements:

MP_SELECT option:

The host sends this option to enforce path-selective operation on its peer.  The option is generally sent on the subflow to be used for data transmission. It may enclose an address id in case it is sent on another subflow, e.g. in break-before-make scenarios before the designated path becomes available. The option permits low-complexity MPTCP receiver solutions (Section 4.4) as well as dynamic overhead shedding for heavily loaded servers (Section 4.5).

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an address id.  The enclosed address-id permits sending the option from an available interface to refer to an unavailable interface. The option permits the peer to swiftly adjust data transmission when the host's interface availability changes. There are multiple use cases for this option (Section 3.6, Section 4.4 and Section 4.5).

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5).

ADD_ADDR option:

The present version of this option should be modified: The option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit the address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below).

JOIN_ADDR option:

The host sends this option to request subflow creation (via MP_JOIN) to an address referred to via the enclosed address id. Currently, the functionality of this option is melted into the ADD_ADDR option.

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received for a packet contained in the bulk (Section 3.7).

Please take the details from the corresponding sections of the document. Comments are welcome. Thank you.

Regards,
Georg Hampel