Internet DRAFT - draft-li-tsvwg-tcp-service-migration
draft-li-tsvwg-tcp-service-migration
Internet Engineering Task Force C. Li
Internet-Draft UCLA
Intended status: Informational B. Li
Expires: May 9, 2013 C. Peng
W. Zhang
Huawei
S. Lu
UCLA
November 5, 2012
A TCP Service Migration Protocol for Single User multiple Devices
draft-li-tsvwg-tcp-service-migration-00
Abstract
This document describes a new transport protocol TSMP, which seeks to
support data transfer for the emerging usage paradigm of "single
user, multiple device" in a TCP compatible manner. Through its novel
proxy-based design, TSMP is able to retain the current client and
server protocol operations of the legacy TCP protocol and TCP-based
applications while placing new functions at the proxy.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 9, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Li, et al. Expires May 9, 2013 [Page 1]
Internet-Draft TCP Service Migration for SUMD November 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Single User Multiple Devices . . . . . . . . . . . . . . . . . 4
3.1. An Example Scenario . . . . . . . . . . . . . . . . . . . . 4
3.2. System Requirements . . . . . . . . . . . . . . . . . . . . 5
4. TCP Service Migration Protocol . . . . . . . . . . . . . . . . 5
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Proxy-based Solution . . . . . . . . . . . . . . . . . . . 6
4.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
4.3. TCP Migration . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Transient Pause Phase . . . . . . . . . . . . . . . . . 7
4.3.2. Resumption Phase . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Li, et al. Expires May 9, 2013 [Page 2]
Internet-Draft TCP Service Migration for SUMD November 2012
1. Introduction
In this document, we design protocol solutions to an emerging usage
scenario of "single user, multiple devices." In recent years, it has
become increasingly popular that a user owns multiple devices with
networking capabilities. In an example scenario, a user has a laptop
in the office, a desktop at home, while carrying an iPhone or iPad
wherever (s)he goes. This emerging single-user, multi-device setting
opens new venue for networking protocol design and operations.
TCP has been the dominant transport protocol for most Internet
applications, and many popular applications such as web-based video
streaming, and Instant messaging (e.g., MSN) are based on its
operation. In the single-user, multiple-device context, there are
two main design challenges. First, the protocol operations should
support TCP-based data transfer among multiple devices of the same
user. TCP sessions should seamlessly migrate among the devices owned
by the same user. For example, a user uses instant messaging or
video streaming on his laptop when he is in his office. When he
walks out for lunch, he proceeds the ongoing messaging or video
session via his iPhone or iPad. Second, users can continue to run
the legacy TCP and applications with minimal changes at both sides of
the client and the server while supporting the notion of single-user,
multiple-device during data communication. This will enable reuse of
most existing Internet applications. Existing protocols can achieve
one of these two goals, but not both.
In this document, we describe a novel solution, called TCP Service
Migration Protocol (TSMP), which supports "single-user, multi-device"
TCP communications. The TCP connection is associated with the user
and can seamlessly migrate among devices belonging to the same user.
A key innovation in TSMP is the proxy bridging the client and the
server in the current client-server communication model. The proxy
offers two critical services of naming and TCP control/data plane
functions. By carefully designing the proxy, TSMP is able to reuse
existing TCP and TCP-based applications at both the client and the
server without changes.
2. Terminology
This document uses the following terms to refer to the entities or
functions that are required in service migration protocol. Readers
are expected to be familiar with RFC 3753 "Mobility Related
Terminology" [RFC3753].
Li, et al. Expires May 9, 2013 [Page 3]
Internet-Draft TCP Service Migration for SUMD November 2012
Instant Messaging (IM): A form of real-time, direct, text-based
chatting communication between two or more people.
TCP Service Migration Protocol (TSMP): A protocol that can be used
to migrate an ongoing TCP service from one device to another.
Both devices belong to the same owner.
TCP Service Migration Protocol Server (TSMPS): A system that
maintains a global namespace, and performs namespace management
and namespace resolution.
TCP Service Migration Protocol Proxy (TSMPP): A system that is
interposed between the server and the client to support TSMP via
coordinating control signaling and forwarding data.
TCP Service Migration Protocol Application (TSMPA): An application
that is installed on each TSMP-enabled device.
Migration From Request (MFR): A control message that is used to
issue the request of service migration by the originator device.
Migration To Request (MTR): A control message that is used to inform
the target device regarding the request of service migration.
3. Single User Multiple Devices
This section illustrates an example scenario of single-user, multi-
device, the requirements for our design, and the applications to
which our protocol can be applied.
3.1. An Example Scenario
Bob has three networking devices: PC at home, Laptop in the office,
and Smartphone that he uses while roaming. He chats with his friend,
Alice, over an IM application using his smartphone while he is on his
way back home. Meanwhile, Alice wants to share video clips with Bob
using HTTP streaming from her web server running on her PC. After
arriving at home, Bob switches both the IM session and the HTTP
progressive downloading of the remaining videos to his home PC
because of its larger screen size and network bandwidth. Bob then
chats with Alice and watches the latter part of the video on his PC.
Moreover, the service migration among Bob's devices is transparent to
Alice.
Li, et al. Expires May 9, 2013 [Page 4]
Internet-Draft TCP Service Migration for SUMD November 2012
3.2. System Requirements
In the above scenario, we need to address the following two issues.
o How to keep the intended connection open during migration and
prevent the end that is not involved from perceiving the
migration?
o How to transfer TCP connection states from one device to another
and make the overhead incur as little impact as possible on the
connection?
The system needs to consider both control and data planes to support
service migration. The control plane is used to coordinate the
operation of service migration, including triggering the migration
process, discovering the device to which the service is migrated, and
informing the new device to accept the migration. During service
migration, the data plane should be able to cache the transient
packets that have been sent by the sender but have not been
acknowledged, and make these packets as few as possible to reduce
potential overhead. Once the migration is completed, it sends all
cached packets to the new receiver and resumes the original TCP
connection. Another important task is to avoid retransmission
timeout to retain the same value of Congestion_Threshold. Service
migration may happen from one device with low bandwidth to another
with high bandwidth or from the latter to the former. In the former
case, we need to make the Congestion_Threshold value as large as
possible so that the sender's Congestion_Window grows quickly with
the slow-start algorithm, to reach the appropriate size associated
with the larger bandwidth setting. If the Congestion_Threshold value
becomes too small, the size of Congestion_Window would increase very
slowly because it increases linearly with the additive increase/
multiplicative decrease mechanism once exceeding the threshold.
However, the Congestion_Threshold cannot increase without data
transmission; therefore, a feasible option is to retain the same
value of Congestion_Threshold. As for the latter case, the
Congestion_Window can shrink quickly to the appropriate size due to
the multiplicative decrease mechanism.
4. TCP Service Migration Protocol
In this section, we first present the protocol architecture, and then
describe our proxy-based solution to TCP migration.
Li, et al. Expires May 9, 2013 [Page 5]
Internet-Draft TCP Service Migration for SUMD November 2012
4.1. Architecture
We employed a proxy-based solution to achieving TCP service
migration. As shown in Figure 1, the TSMP architecture is composed
of three main components: TSMP Proxy (TSMPP), TSMP Server (TSMPS),
and TSMP Application (TSMPA). TSMPP is interposed between the client
and the server to relay packets from either side to the other and
mediate the sub-connections of each TCP connection. To avoid
modification of the existing systems and applications, it
collaborates with TSMPS and TSMPA to support the service migration
process. TSMPA provides users an interface to make use of the TSMP
service. It offers a channel for TSMPP to interact with the TCP-
based applications at devices. TSMPS provides the service of DNS-
like name resolution and enables the proxy to locate devices.
+------------------------+ +------------------------------+
| TSMP Server | | TSMP-enable Device |
| +--------------------+ | | +--------------------------+ |
| | Resolution | | | | TSMP Application | |
| | Service Module | | | | +----------------------+ | |
| +----------+---------+ | +---+-+-| TSMP Service Module | | |
+------------+-----------+ | | | +-----------+----------+ | |
| +------------+ | +-------------+------------+ |
+------------+--+-----------+ | | |
| TSMP +----+--+-+ +------+| | +-------------+------------+ |
| Proxy | Control | | Data ++----+-| TCP-based Applications | |
| | Plane | | Plane|| | +--------------------------+ |
| +---------+ +------+| | |
+---------------------------+ +------------------------------+
Figure 1: TSMP Architecture.
4.2. Proxy-based Solution
TSMPP consists of both the control plane and the data plane. The
former coordinates the service migration process. The latter
forwards packets between two ends, and emulates as a TCP sender to
set up a new sub-connection to the new receiver upon TCP migration
request.
4.2.1. Control Plane
The control plane coordinates the operation of service migration
using two control messages: Migration From Request (MFR) and
Migration To Request (MTR). MFR is always sent by TSMPA to request
Li, et al. Expires May 9, 2013 [Page 6]
Internet-Draft TCP Service Migration for SUMD November 2012
TSMPP to migrate a TCP connection from the device where it resides to
another device. It includes both the identity of the intended device
and the information of the migrated connection so that TSMPP can
resolve the device's IP address by querying TSMPS and identify the
connection. The other control message, MTR, is used by TSMPP to let
TSMPA invoke its local application and set up a connection to TSMPP.
TSMPP then hooks up this new sub-connection to the old sub-connection
of the other end, thus recovering the migrated TCP connection.
4.2.2. Data Plane
TSMPP bridges between the two ends for each TCP connection by
forwarding packets from one end to the other. Each connection is
divided into two sub-connections that are glued by a mapping table in
TSMPP. The mapping entry of a connection contains two-tuple of each
end: IP address and port number. When TSMPP receives packets from
one end's sub-connection, it replaces the source and destination
information with the TSMPP address and the other end's address,
respectively, and then forwards them to the other sub-connection.
4.3. TCP Migration
When TSMPP receives a MFR request, it starts the migration process of
the requested TCP connection. The main concept is that, it
temporarily halts the TCP flow until the connection between the new
device and TSMPP is established, and then resumes it. The process
hence consists of two phases: transient pause phase and resumption
phase. The pause phase freezes the sending process, caches all
outstanding packets that have not be forwarded by TSMPP, and keeps
the value of Congestion_Threshold unchanged to prevent unnecessary
congestion control invocations at the sender. The goal of the former
two actions is to minimize transient loss and keep the connection
open, whereas the last action seeks to decrease the overhead of
increasing Congestion_Window to the appropriate size of the new sub-
connection after the migration completes. In the resumption phase,
TSMPP emulates a TCP end to set up a connection to the new device,
flushes the cached packets to it, and then recovers the sending
process. After the connection is resumed, TSMPP continues the
forwarding process and the old sub-connection is halted.
4.3.1. Transient Pause Phase
This phase is launched once MFR is received by TSMPP. It does not
end until the migration is complete. It is mainly composed of three
tasks: advertising the size of the receiver's window to be zero,
stopping forwarding data packets but caching all of them, and
responding to the zero-window probing.
Li, et al. Expires May 9, 2013 [Page 7]
Internet-Draft TCP Service Migration for SUMD November 2012
In the TCP flow control mechanism, the receiver can advertise its
window with the size zero to stop the sender from sending data.
The sender does not resume sending until the advertised window is
larger than zero. We leverage this feature to stop the sending
process by resetting the window size of the TCP headers to be zero in
the ACK packets that are forwarded once this phase begins. TSMPP
keeps on forwarding the ACK packets that acknowledge the data packets
it has forwarded to the old receiver before this phase. The sender
thus halts its sending process, and does the zero-window probing by
sending at least one octet of new data periodically. Its purpose is
to attempt recovery and ensure that re-opening of the window can be
reliably reported. During the migration period, TSMPP should
generate and send an ACK packet, which shows the next expected
sequence number and zero window size, in response to each probe
segment. Therefore, the TCP sender would allow the connection to
stay open and temporarily freeze the sending process without
shrinking the value of Congestion_Threshold. We can use the maximum
sequence number of the cached packets plus one to be the expected
sequence number.
Another task for this phase is to cache the transient packets that
have not been forwarded. TSMPP starts to cache data packets and
stops forwarding them once this phase begins. These cached data
packets have been sent out by the sender so that the retransmission
timeout would be triggered if they were not acknowledged.
Accordingly, TSMPP needs to generate and send their ACK packets to
the sender in advance on behalf of the new receiver. These ACKs
should also contain the same information of the expected sequence
number and the window size. TSMPP needs to ensure that it caches the
data segments with all the sequence numbers between the expected
sequence number and the acknowledge number of the last ACK packet
that the old receiver sends. There may be a case that the old
receiver does not acknowledge all its received packets before tearing
down its connection. However, these packets would not be cached by
TSMPP because they have been forwarded. Intuitively, TSMPP can just
send ACKs to trigger retransmission at the sender and cache them, but
the side effect is that Congestion_Threshold will be reduced. We may
enable TSMPP to cache a certain amount of packets to handle this case
no matter whether it is in the migration state or not. If there are
still missing packets, relying on the retransmission would not be
avoided. We can estimate the cache size based on half of the RTT
between the sender and the receiver.
4.3.2. Resumption Phase
When the new device requests for a new connection due to its TSMPA's
invocation, the resumption phase begins. TSMPP emulates a TCP end to
Li, et al. Expires May 9, 2013 [Page 8]
Internet-Draft TCP Service Migration for SUMD November 2012
conduct three-way handshaking with the device, and starts to send its
cached packets to it. As a TCP sender, TSMPP maintains some
connection states: Congestion_Window, and Congestion_Threshold, etc.
It uses the slow-start algorithm when the sending process is
initialized or the connection times out, and employs the AIMD
algorithm after Congestion_Window reaches Congestion_Threshold.
TSMPP does not forward their ACK packets to the sender. After all
cached packets are acknowledged, TSMPP resumes the sender's sending
process by forwarding the new receiver's last ACK it receives. The
transmission is thus recovered due to the last ACK with a non-zero
receive window. TSMPP then returns to the normal forwarding phase,
and discards the emulated TCP states. An issue we need to address is
that the initial sequence number that is chosen at random may result
in different sequence number systems between the old sub-connection
and the new sub-connection. For this reason, TSMPP should add the
mapping information of their sequence numbers into the mapping entry
of this connection, and modify each packet's sequence number before
forwarding it.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
The security aspects of the proxy-based applications also apply to
this memo. TBC.
7. Informative References
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
June 2004, <RFC 3753>.
Authors' Addresses
Chi-Yu Li
UCLA
4681 Boelter Hall
Los Angeles, CA 90095
USA
Phone: +1 323 528 1039
Email: lichiyu@cs.ucla.edu
Li, et al. Expires May 9, 2013 [Page 9]
Internet-Draft TCP Service Migration for SUMD November 2012
Bojie Li
Huawei
Shenzhen,
P.R.C.
Phone: +86 755 2878 0808
Email: libojie@huawei.com
Chenghui Peng
Huawei
Shenzhen,
P.R.C.
Phone: +86 755 2878 0808
Email: pengchenghui@huawei.com
Wei Zhang
Huawei
Shenzhen,
P.R.C.
Phone: +86 755 2878 0808
Email: wendy.zhangwei@huawei.com
Songwu Lu
UCLA
4731C Boelter Hall
Los Angeles, CA 90095
USA
Phone: +1 310 794 9289
Email: slu@cs.ucla.edu
Li, et al. Expires May 9, 2013 [Page 10]
