Internet DRAFT - draft-sarolahti-irtf-catcp
draft-sarolahti-irtf-catcp
Network Working Group P. Sarolahti
Internet-Draft J. Ott
Intended status: Experimental Aalto University
Expires: September 6, 2012 C. Perkins
University of Glasgow
March 5, 2012
TCP Segment Caching
draft-sarolahti-irtf-catcp-00.txt
Abstract
This document describes Content- and Cache-Aware TCP (CATCP) that
allows caching of TCP segments to be re-used between different
connections transmitting same data. When there is redundant data to
multiple receivers, this can lead to significant load reductions and
performance improvements.
Status of this Memo
This Internet-Draft is submitted 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 September 6, 2012.
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
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
Sarolahti, et al. Expires September 6, 2012 [Page 1]
Internet-Draft CA-TCP March 2012
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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. New TCP Options . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. CA-TCP Enabled Option . . . . . . . . . . . . . . . . . . 5
4.2. Content Label Option . . . . . . . . . . . . . . . . . . . 6
4.3. Content Request Option . . . . . . . . . . . . . . . . . . 7
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.2. Receiver Behavior . . . . . . . . . . . . . . . . . . . . 11
5.3. Controller Behavior . . . . . . . . . . . . . . . . . . . 11
5.4. Segment Cache Behavior . . . . . . . . . . . . . . . . . . 13
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Correctness of Data . . . . . . . . . . . . . . . . . . . 14
6.2. Consistent Segmentation . . . . . . . . . . . . . . . . . 14
6.3. Interaction with middleboxes . . . . . . . . . . . . . . . 14
6.4. Other Issues . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Sarolahti, et al. Expires September 6, 2012 [Page 2]
Internet-Draft CA-TCP March 2012
1. Introduction
Many current Internet applications are content-oriented, where the
main application primitive is to locate and fetch a named content
resource. The most common example is the world-wide web, that uses
URLs to identify a particular content resource. Other content-
oriented applications are the various peer-to-peer file sharing
systems, or the traditional FTP. To enhance the efficiency of
content delivery, popular content is replicated to multiple servers,
and cached by intermediate on-path caches. Usually these caches are
application-specific, commonly focused on the web traffic.
This document describes a TCP extension called Content- and Cache-
Aware TCP (CA-TCP), that identifies the content in TCP payload in a
new TCP option [RFC0793]. This information can be used my new types
of intermediate network caches, to enable generic TCP segment caching
independent of the upper layer application protocol. These network
caches can transmit the cached TCP segments on behalf of the original
TCP sender to any number of receivers. All acknowledgments flow to
the original sender, and it can keep track of the progress of
transmission. The extension requires modifications only at the TCP
sender, and works with any normal TCP receiver. If the network path
contains intermediate network caches that support CA-TCP, the
communication performance of transmitting same data to multiple
receivers can be significantly improved. If there are no such caches
on the path, the communication behavior is identical to normal TCP.
Interoperating with the network caches, CA-TCP can reduce the load at
the TCP senders, and reduce the overall congestion in the network.
Through short-term caching between multiple simultaneous receivers of
the same data, CA-TCP can also be used to enable a form of "pseudo-
multicast": a cache can replicate the data sent by the TCP sender to
multiple receivers. This can be useful with, for example, with TCP-
based live video streaming.
There are also open issues to be solved with CA-TCP. A verification
mechanism is needed for the content that can be cached, to protect
against false injected TCP segments at the caches. The cached
content needs to be consistently segmented among different receivers
to make use of the cached data. These and some other issues are
discussed in more detail in Section 6.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Sarolahti, et al. Expires September 6, 2012 [Page 3]
Internet-Draft CA-TCP March 2012
This document is an Experimental specification, but uses the
normative language as described above. In other words,
implementation of this document is optional, but if a host implements
CA-TCP, the normative instructions of this document MUST be followed.
In addition we use the following terms:
o Segment cache: A CATCP-aware cache that can store TCP segments
based on the TCP options in the packets.
3. Protocol Overview
With CA-TCP the applications can identify data they are transmitting
using a content label that is indicated to the TCP implementation by
an API extension. This content label is transmitted with TCP
segments using a new Content Label Option, that enables TCP segment-
level caching at segment caches that support CA-TCP.
In addition to the TCP sender and receiver, the CA-TCP framework
consists of a Controller, which is a middlebox that intercepts the
data segments and acknowledgments and determines the next data
expected to be transmitted, and segment caches that maintain packet
level caches of labeled content. These caches are then used to share
the cached content between TCP connections, with the segment caches
intercepting CA-TCP acknowledgments, labeled using a new content
request TCP option, and transmitting data from their cache in
response. This helps reduce the load at the TCP sender, and in the
upstream path. The receiver may be modified to add content request
options to acknowledgments, or they may be added by a middlebox near
the edge of the network known as the controlling node.
TCP acknowledgments are delivered to the original sender as normal,
allowing it to keep track of the transmission progress and update its
transmission window accordingly. When transmitting a segment on
behalf of the sender, the segment cache updates the content request
TCP option to inform the sender and upstream segment caches that it
has sent data, preventing them from injecting the same data again.
A CA-TCP connection starts in the usual way, with an end-to-end
three-way handshake. Once the connection is established, data
transfer can proceed as normal, with unlabeled content, or the sender
can add a content label to identify the payload as being a particular
content item.
For example, when fetching an HTTP resource, the client would
initiate the connection and send the HTTP GET request as unlabeled
content in the usual way. The server would accept the connection and
Sarolahti, et al. Expires September 6, 2012 [Page 4]
Internet-Draft CA-TCP March 2012
send the headers of the response as unlabeled content, then it may
assign a content label for the response data, differentiating between
variants (e.g., encodings) of the content as negotiated with the
client. The content label can be changed in the middle of a
connection, if the object under transmission changes. Data that
should not be cached is not given a content label.
4. New TCP Options
Because CA-TCP is an experimental mechanism, the new options use the
experimental TCP options according to the guidelines given in
[I-D.ietf-tcpm-experimental-options]. Therefore no IANA allocation
for new TCP option types is needed at this time.
4.1. CA-TCP Enabled Option
The CA-TCP Enabled TCP Option is shown in Figure 1. The option is
sent in the beginning of connection, together with the SYN and SYN-
ACK segments, to indicate that CA-TCP is supported.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Kind | Length = 6 | Magic Number = 0x20120229 |
+---------------+---------------+-------------------------------+
| ...Magic Number |
+---------------+---------------+
Figure 1: CA-TCP Enabled Option
The option fields are as follows:
o Kind: set to 253 in TCP SYN segment, and 254 in TCP SYN-ACK
segment. These are the experimental TCP option codes, available
without IANA allocation. Note that TCP receivers are not required
to be aware of CA-TCP, but a CA-TCP segment cache SHOULD add this
option to TCP SYN-ACK segment, if it was not there already.
o Length and Magic Number are set as indicated above. The use of
Magic Number is described in [I-D.ietf-tcpm-experimental-options],
and we use hexadecimal value 0x20120229 for CA-TCP.
Sarolahti, et al. Expires September 6, 2012 [Page 5]
Internet-Draft CA-TCP March 2012
4.2. Content Label Option
The Content Label Option (Figure 2) is attached to TCP segments
containing data that can be cached by the segment caches. This
option SHOULD NOT be used, if a TCP sender has not received a valid
CA-TCP Enabled Option in a SYN-ACK, as this likely indicates that
there are no segment caches on the path, and the Content Label Option
would be useless.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Kind = 253 | Length = 16 | Magic Code | Reserved |
+---------------+---------------+---------------+---------------+
| |
| Content Label (8 bytes) |
| |
+---------------------------------------------------------------+
| Offset |
+---------------------------------------------------------------+
Figure 2: Content Label Option
The option fields are as follows:
o Kind and Length: as indicated in the picture.
o Magic Code: This is the last 8 bits of the Magic Number in the CA-
TCP Enabled Option, i.e., 0x29. Using a full 32-bit Magic Number
is not desirable for Content Label Option because of the size
constraints in TCP Options. An 8-bit "magic code" allows
simultaneous operation of multiple experimental options sharing
the same option kind numbers. If the length and the magic code
are not correct, the Content Label Option MUST NOT be processed by
the CA-TCP segment caches.
o Reserved: SHOULD be set to 0 for now, reserved for future use.
o Content Label: Identifies the application layer content.
Application chooses a content label that is unique by high
probability, and communicates that to the TCP implementation
through the API. This label is only used as a caching identifier
(together with the content offset), and the TCP implementation is
indifferent about the contents of this field. The application
MUST NOT use the same content label if the application payload has
changed from the earlier use of the content label.
Sarolahti, et al. Expires September 6, 2012 [Page 6]
Internet-Draft CA-TCP March 2012
o Offset: Indicates the relative distance of the TCP payload to the
start of the content object in bytes. When a TCP sender starts to
send cachable data under a new content label, the offset is
initialized to 0 (unless the sender starts transmission from the
middle of content). For subsequent segments the offset value is
increased by the same amount as the TCP sequence number is
increased. This information is used to identify the cached
segments, in addition to the content label. Relative offsets are
needed, because TCP connections start at random sequence numbers
that cannot be used for caching.
4.3. Content Request Option
The Content Request Option (Figure 3) is carried together with TCP
acknowledgments. A CA-TCP segment cache uses it to indicate the
highest sequence number sent, and to indicate whether it has sent
data in response to the acknowledgment, to prevent upstream nodes
sending excess data in response to single acknowledgments.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+-------+-------+
| Kind = 254 | Length = 20 | Magic Code | CS | Rsvd |
+---------------+---------------+---------------+-------+-------+
| |
| Content Label (8 bytes) |
| |
+---------------------------------------------------------------+
| Next Offset |
+---------------------------------------------------------------+
| TCP Sequence |
+---------------------------------------------------------------+
Figure 3: Content Request Option
The option fields are as follows:
o Kind and Length: as indicated in the picture.
o Magic Code: This is the last 8 bits of the Magic Number in the CA-
TCP Enabled Option, i.e., 0x29. If the length and the magic code
are not correct, a segment cache MUST NOT process this option.
o CS (CanSend): Number of TCP segments that can be sent in response
to this TCP acknowledgment. With this field a CA-TCP segment
cache can control the number of data segments transmitted in
response to the acknowledgment. Even though the field length
Sarolahti, et al. Expires September 6, 2012 [Page 7]
Internet-Draft CA-TCP March 2012
allows larger values, the value of CS SHOULD NOT be larger than 2,
i.e., at most two outgoing segments are allowed for an incoming
acknowledgment. The management of CS field is described in more
detail in Section Section 5.3.1.
o Rsvd (Reserved): SHOULD be set to 0 for now, reserved for future
use.
o Content Label: Identifies the content expected to be transit for
this connection. When receiving this acknowledgment, a CA-TCP
segment cache uses this field, together with the 'Next Offset'
field to check if it has data in its cache it can transmit in
response to the acknowledgment.
o Next Offset: Indicates, relative to the beginning of the content,
what data is expected to be transmitted next. A segment cache or
TCP sender uses this field, together with the 'Content Label'
field to determine what data is to be transmitted next. When a
segment cache transmits data, it increases the Next Offset field
before forwarding the TCP acknowledgment, to prevent multiple
transmissions of the same data.
o TCP Sequence: Tells the next TCP sequence number that should be
used by a segment cache for sending a data segment in response to
this acknowledgment. This information is needed by a segment
cache to build a valid TCP header for outgoing data segment.
Segment caches cannot be assumed to maintain a full TCP flow state
of ongoing connections. The other header fields can be
constructed based on the acknowledgment, as outlined in Section
Section 5.4.
5. Operation
In the following we specify the operation of CA-TCP Sender, CA-TCP
Controller that intercepts the normal TCP acknowledgments, and
Segment Cache, that stores the TCP segments that arrive with a
Content Label option. The TCP receiver follows normal TCP operation.
5.1. Sender Behavior
A TCP sender starts connection with normal TCP SYN handshake. If the
sender is going to use CA-TCP during the connection, it MUST add CA-
TCP Enabled Option (with Kind number 253) to the SYN segment. If a
TCP implementation with CA-TCP support does not know at connection
establishment time whether it is going to use CA-TCP, a safe action
is to add the CA-TCP Enabled option to all new connections. However,
a TCP sender MAY leave the option out, in which case it MUST NOT use
Sarolahti, et al. Expires September 6, 2012 [Page 8]
Internet-Draft CA-TCP March 2012
CA-TCP during the remainder of the connection.
The TCP sender checks if incoming SYN-ACK segment carries a CA-TCP
Enabled option (with Kind number 254). If this option is not
included, the TCP sender MUST NOT use CA-TCP during the remainder of
the connection.
5.1.1. Outgoing Data
Any time during the connection a TCP sender may or may not attach the
content label to the outgoing data segments. A TCP sender can also
change the content label during the connection, if the content item
under transmission changes. For example, in a persistent HTTP
connection, the HTTP headers would be sent without a content label,
and a static, cachable HTTP body would be transmitted with the
content label option., and for multiple HTTP responses in the same
connection, the different body elements would use different content
label.
The content label is chosen by the sending application, and the TCP
implementation is indifferent about its content. The receiving TCP
implementation will ignore the Content Label option, and receiving
application will not therefore know about its existence. The content
label should be chosen such that the likelihood of a label collision
at segment caches is as small as possible, for example using a digest
composed from the content itself.
When application sets new content label, the first byte of the
indicated content MUST start a new TCP segment. The TCP sender adds
a Content Label Option to this segment and subsequent segments until
the transmission of the content is complete. The value of Offset
field is set to 0 in the first segment, and the subsequent segments
set this value to the distance of the first byte of payload to the
start of data. The sender also stores the the TCP sequence number of
the first byte of content for further processing in an internal
variable (SND.Content-Start). This field can be seen as a content-
internal sequence numbering that is independent of the randomly
initialized value of the TCP sequence number.
If the labeled content changes in any way, for example, if any single
bit changes, or the length of the content changes, the application
MUST use a different content label than earlier.
TCP sender SHOULD try to maintain consistent segmentation for payload
with content label, to improve the efficiency of the caching of the
content. This is may not always be possible, but failing to do so is
not fatal. Inconsistent segment boundaries just result in not being
able to use the possibly earlier cached data.
Sarolahti, et al. Expires September 6, 2012 [Page 9]
Internet-Draft CA-TCP March 2012
5.1.2. Processing Acknowledgments
If an incoming acknowledgment arrives without the Content Request
Option, it is processed normally.
If an acknowledgment contains the Content Request Option, the sender
updates its local state in the following way: if the sum of 'Next
Offset' field and SND.Content-Start points to sequence that is later
than the value of SND.NXT in TCP sender's local state, the value of
SND.NXT is set to the sum of 'Next Offset' and SND.Content-Start.
This avoids resending data that has already been sent by a segment
cache in the network.
It is possible that with a fast segment cache SND.NXT grows faster
than the sending TCP application can write to the socket send buffer.
This is considered a feature of CA-TCP. The applications are
expected to explicitly enable CA-TCP, and to use content labels
consistently for the exactly same data. If this principle is
followed, this behavior does not cause problems.
SND.UNA in TCP's local state is managed normally, based on the
incoming TCP acknowledgments. TCP's retransmission algorithms
operate normally, based on incoming duplicate acknowledgments and
retransmission timer. Retransmitted segments MAY contain the Content
Label Option, if the content in question was assigned with a label.
TCP congestion control operates according to the normal rules
[RFC5681]. However, when an incoming acknowledgment arrives, the TCP
sender consults the 'CanSend (CS)' field, before increasing the
congestion window. The sender's congestion window MUST NOT be
increased more than the value of CS, multiplied by the SND.MSS. When
data is delivered from segment cache, it is common that the CS value
in incoming acknowledgment is 0. In this case the TCP sender does
not increase the congestion window at all (even by a fraction, if in
congestion avoidance). Note that this makes the TCP sender behavior
more conservative than in the normal case.
When data is delivered from the segment caches, it is possible that
TCP sender receives acknowledgments for data it has not yet sent.
Such data SHOULD be discarded from the socket send buffer without
transmitting it. Sampling the round-trip time and updating the RTO
estimate is impossible in such cases. Otherwise the RTO estimate is
maintained in a normal way [RFC6298]. The RTO timer SHOULD be reset
based on the currently estimated value on each new acknowledgment
that advances the window, to avoid spurious retransmission timeouts
on long periods of cached data.
Sarolahti, et al. Expires September 6, 2012 [Page 10]
Internet-Draft CA-TCP March 2012
5.2. Receiver Behavior
TCP Receiver operates in normal way, and does not need to be aware of
CA-TCP, or be able to parse the options. The receiver ignores the
options with their content, and delivers the data to the application
normally. A receiver can operate as a CA-TCP Controller, adding the
Content Request options to outgoing acknowledgments.
5.3. Controller Behavior
CA-TCP Controller is a node that processes normal TCP acknowledgments
and adds Content Request option to them, if needed. The Controller
can be co-located at a segment cache, or a TCP receiver can act as a
controller. Because segment caches operate based on the Content
Request options, an ideal location for the controller is close to the
receiver, because the segment caches downstream from controller
cannot be used for caching. In order to process the acknowledgments
appropriately, the controller needs to maintain some per-flow state,
as described below.
Controller maintains some flow-specific data for each flow with
potentially cachable data, in a structure we call "flow table". The
flow table contains the following data for each active flow.
o Source and Destination IP address and port -- for identifying a
flow.
o Content.Label -- Content label currently in transit in a flow.
This can be 0, if no labeled content is currently in transit.
o Content.Offset -- The TCP sequence number at the start of the
currently transmitted content object.
o Content.Next -- The next untransmitted content byte in the flow,
relative to the beginning of the content.
o Congestion control state -- see Section 5.3.1 for discussion on
congestion control at the Controller.
When a TCP SYN segment with CA-TCP Enabled option arrives at the
controller, it creates a new entry in the flow table using the source
and destination IP address and TCP port, and initializes the other
parameters for the flow. Storing the flow table entry is optional:
controller may choose to ignore the option, for example because of
resource constraints or a policy. In this case the TCP connection
continues to operate normally, without segment caching.
When a TCP SYN-ACK segment arrives at the controller (or is sent by a
Sarolahti, et al. Expires September 6, 2012 [Page 11]
Internet-Draft CA-TCP March 2012
receiver that also acts as a controller), and the controller has the
corresponding flow state for the flow, it SHOULD add CA-TCP Enabled
option to the segment before passing it forward, with option kind set
to 254, as described in Section 4.1.
When a TCP data segment with Content Label option arrives at the
controller, and it has the corresponding flow state initialized, the
controller stores the currently transmitted content label to the
appropriate flow table entry if it is different from earlier stored
content label. The controller also stores (or verifies) the TCP
sequence number at the start of the content to the flow table
('Content.Offset'). 'Content.Offset' is calculated by subtracting
the Offset field at the Content Label option ('Option.Offset') from
the TCP sequence number in the current segment. This information is
needed to build correct Content Request options for TCP
acknowledgments for the same TCP flow. If Option.Offset + TCP.Length
(the length of TCP segment payload) is higher than 'Content.Next' in
the local flow table, the controller sets Content.Next to
Option.Offset + TCP.Length. Note that for a correctly working
connection, the difference between offset and TCP sequence number
should not change during the transmission of the content. However,
it is possible that TCP sender starts transmission of content from a
different offset than 0.
When a TCP data segment without Content Label arrives, and the flow
is found in the flow table, the controller erases the current label
from the table, if one was stored. If labeled content was previously
in transit, but a segment without content label option is received,
that tells the transmission of labeled content is finished (for
example, transmission of HTTP body is over, and data for new HTTP
request arrives).
When a TCP acknowledgment arrives that does NOT yet have a Content
Request option, but corresponds to a flow that is stored to flow
table, the controlling node reviews from the flow table if there
currently is labeled content in transmission. In positive case, it
adds a Content Request Option to the segment containing the current
content label. The controller also copies the 'Content.Next' value
from the local flow state to the 'Next Offset' field of the TCP
Option, and sets the 'TCP Sequence' field in the option as
Content.Offset + Content.Next. Now the contents of the option refer
to the next content offset and TCP sequence that can be transmitted
either by the sender caches, or by the TCP sender. The Controller
also sets the CS (CanSend) field using the congestion control
algorithm described below. After this the Controller forwards the
acknowledgment.
When a TCP acknowledgment arrives with Content Request option, the
Sarolahti, et al. Expires September 6, 2012 [Page 12]
Internet-Draft CA-TCP March 2012
Controller just ignores the segment and forwards the acknowledgment.
In this case there is another controller on the downstream path that
already manages the TCP flow.
5.3.1. Congestion Control
The Controller MUST take care of congestion control for the flows
that are in maintained at the flow table. A simplified congestion
control algorithm is considered sufficient, because the original TCP
sender is responsible of retransmitting data and ultimately maintains
the normal sender-side congestion control algorithm.
For example, the following algorithm is sufficient.
o The controller maintains a congestion window for each flow that
indicates how many segments are allowed to be in transit. The
congestion window is initialized to 3.
o When an incoming acknowledgment advances the window, the
congestion window is increased according to congestion avoidance
algorithm.
o When three consecutive duplicate acknowledgments arrive at the
controller, the congestion window is halved.
The controller then compares the current congestion window (cwnd) to
the number of outstanding unacknowledged TCP segments for the flow
(FlightSize), and sets the CanSend field in outgoing Content Request
option to cwnd - FlightSize. If the difference is more than 2, the
CanSend field SHOULD NOT have larger value than 2, to limit bursts.
The controller does not manage retransmission timer or take RTT
samples. If a retransmission timeout is required, the TCP sender
takes care of the needed retransmissions.
5.4. Segment Cache Behavior
The segment cache intercepts arriving TCP segments with Content
Request option, and transmits segment(s) from cache, if the requested
segments can be found, based on content label and Next Offset fields
in the option.
If a segment cache has a segment in storage that starts from the
sequence number indicated by the Next Offset field AND that has the
same content label, AND if the CS field is larger than 0, the segment
cache can transmit the cached segment towards the receiver that sent
the acknowledgment. The TCP header is built based on the incoming
acknowledgment, and the TCP sequence number is copied from the
Sarolahti, et al. Expires September 6, 2012 [Page 13]
Internet-Draft CA-TCP March 2012
Content Request option. The ACK flag is not set in the segment, and
the advertised window is set to a small value (exact value TBD),
because the segment cache does not know the state of the buffer at
the TCP end host.
After this the CS value in Content Request option is decremented by
one, and the Next Offset and the TCP sequence are incremented by the
length of the cached data segment payload. If the CS value is still
larger than 0, the segment cache can send another segment based on
the same procedure, if the segment is in cache, again decrementing
the option fields appropriately.
After the segment cache is done with processing the Content Request
option, it forwards the segment towards TCP sender.
6. Open Issues
6.1. Correctness of Data
Using content labels will give a malicious data source a tool to
inject data under a false content label unless some measures are
taken to verify the validity of the content at the receiver. Many
applications have such verification mechanisms built in, but at the
moment there are no valid common transport layer mechanism to check
the correctness of labeled content. A sending application must also
use the content labels consistently: if any part of the content is
changed, the label must be changed.
6.2. Consistent Segmentation
The potential benefit of caching depends on having consistent
segmentation of data. If the segment boundaries vary between
connections, the efficiency and cache hit rate suffers.
6.3. Interaction with middleboxes
Network address translation is not expected to affect the behavior of
CA-TCP, and its behavior is tested with some NAT implementations.
However, some middleboxes may perform in-window checks that filter
out acknowledgments that appear to arrive out of window, as may
easily happen with CA-TCP, as acknowledgments may arrive for data
that was not sent by the original sender. Some middleboxes may alter
segment boundaries, leading to similar problems as discussed above
for consistent segmentation.
Sarolahti, et al. Expires September 6, 2012 [Page 14]
Internet-Draft CA-TCP March 2012
6.4. Other Issues
The control loop between a cache and receiver may be significantly
faster than the loop between the TCP end hosts. Sender can interrupt
the transmission of data at any time by sending a segment without a
content label. However, during the time the segment is in transit, a
cache may have transmitted new data if there are cache hits.
Currently we believe this is not a critical problem for labeled
content.
CA-TCP requires a good portion of TCP option space for labeled data.
There are also other enhancements that are hungry for TCP option
space, such as Multipath TCP [I-D.ietf-mptcp-multiaddressed], and the
option space limitation of 40 bytes prevents the different
enhancements to be used together. One solution to this problem would
be to come up with enhancements to extend the available option space,
such as discussed in [I-D.eddy-tcp-loo].
If the communication path changes during a TCP connection, the
traffic may bypass the original controller. This is not a fatal
problem, but just causes the rest of the TCP connection be
transmitted between the sender and the receiver.
7. Security Considerations
The main security issue is related to the correctness of data, as
discussed in Section 6.1. Good solutions for this problem are
currently being investigated.
8. Acknowledgments
This work has been partially funded by the PURSUIT EU project.
9. References
9.1. Normative References
[I-D.ietf-tcpm-experimental-options]
Touch, J., "Shared Use of Experimental TCP Options",
draft-ietf-tcpm-experimental-options-00 (work in
progress), January 2012.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
Sarolahti, et al. Expires September 6, 2012 [Page 15]
Internet-Draft CA-TCP March 2012
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
June 2011.
9.2. Informative References
[I-D.eddy-tcp-loo]
Eddy, W. and A. Langley, "Extending the Space Available
for TCP Options", draft-eddy-tcp-loo-04 (work in
progress), July 2008.
[I-D.ietf-mptcp-multiaddressed]
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", draft-ietf-mptcp-multiaddressed-06 (work in
progress), January 2012.
Authors' Addresses
Pasi Sarolahti
Aalto University
Department of Communications and Networking
P.O. Box 13000
FI-00076 Aalto
Finland
Email: pasi.sarolahti@iki.fi
Joerg Ott
Aalto University
Department of Communications and Networking
P.O. Box 13000
FI-00076 Aalto
Finland
Email: jo@netlab.hut.fi
Sarolahti, et al. Expires September 6, 2012 [Page 16]
Internet-Draft CA-TCP March 2012
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
Email: csp@csperkins.org
Sarolahti, et al. Expires September 6, 2012 [Page 17]
