| Internet-Draft | TCP FWA | September 2023 |
| Thejeswara, et al. | Expires 6 March 2024 | [Page] |
This document describes TCP Fast Window Advance (FWA) flag in TCP Header to avoid the Head of Line Blocking in TCP long alive connections and in TCP long fat networks. FWA flag shall be set by the sender to force the TCP receiver to change its expected sequence number. This allows the application sender to send fresh application session data to receiver on the existing TCP connection without blocking on the earlier session. The FWA flag will solve long standing Head of Line (HOL) blocking problem in TCP for certain TCP applications.¶
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 https://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 6 March 2024.¶
Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Transmission Control Protocol (TCP) is described in [RFC9293] provides the robust and reliable transport layer protocol. TCP recovers data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted by sender. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates and error detection is performed by using checksum. Any loss of segments or error segments requires at retransmission by TCP sender.¶
TCP receiver uses the ACK field to acknowledge the sequence numbers it has received and can optionally use the SACK option to report the sequence numbers received in out of order.¶
Certain applications such as 3GPP VoLTE/VoNR(Voice over LTE/Voice over NR) have SIP session timers over TCP connections to wait for response from server. Once SIP Session timeout occurs, application treats that session as failure and continues with next session. At this point, TCP is unaware of session failure and it continues to retransmit unacknowledged segments of previous SIP session, and IMS application on receiver side receives the stale SIP session and replies to session.¶
Once the SIP session is treated as failed, the IMS application generate the new SIP session, the new SIP session will have different session tokens from previous session, so the IMS application will reject any further responses to old SIP session from the receiver. SIP receiver sends the response to old sessions, as a result IMS/SIP sender either terminates the current session or has to ignore the old SIP response messages¶
As a result, in intermit network conditions new SIP session data is either buffered or failed with TCP HOL blocking. As in [IMS] architecture TCP data buffering can occur at multiple intermediaries in the end-to-end network topology of IMS Network.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
We repeat here some of the definitions from [RFC5681] to aid the reader.¶
SENDER MAXIMUM SEGMENT SIZE (SMSS): The SMSS is the size of the largest segment that the sender can transmit. This value can be based on the maximum transmission unit of the network, the path MTU discovery [RFC1191], [RFC4821] algorithm, RMSS (see next item), or other factors. The size does not include the TCP/IP headers and options.¶
RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the largest segment the receiver is willing to accept. This is the value specified in the MSS option sent by the receiver during connection startup. Or, if the MSS option is not used, it is 536 bytes [RFC1122]. The size does not include the TCP/IP headers and options.¶
RECEIVER WINDOW (rwnd): The most recently advertised receiver window.¶
CONGESTION WINDOW (cwnd): A TCP state variable that limits the amount of data a TCP can send. At any given time, a TCP MUST NOT send data with a sequence number higher than the sum of the highest acknowledged sequence number and the minimum of cwnd and rwnd.¶
Head of Line Blocking (HOL) : A protocol state TCP can not process the received data, until the missing segment is received.¶
In IMS based applications, SIP Signalling [RFC3261] is performed using TCP protocol.When user triggers a voice call, SIP INVITE is sent to peer and IMS Stack waits for 1xx response. SIP INVITE packet size is in multiple of TCP Maximum Segment size (MSS) and required TCP level segmentation based on the negotiated SMSS with TCP peer RMSS during 3-way handshake.This has been observed from field test that sometimes complete TCP segments carrying SIP INVITE has not reached TCP peer and TCP peer is still waiting for remaining data to pass SIP INVITE message to SIP decoder. SIP Decoder needs complete SIP Payload to process the SIP transaction. Due to intermit network conditions, these remaining TCP segments are permanently lost and/or unordered. These received TCP segments received at IMS receiver after the Sender IMS Session/transaction timeout.¶
SIP Call originator [IMS] has shorter call setup timer duration (example: 6 seconds, Call setup timer is configurable by cellular network operator) in comparison to overall TCP retransmission attempts time out(example : 60 seconds) to conclude call attempt as failure. In such cases, call originator has concluded call attempt as failure based on call setup timer and new SIP/IMS call transaction is made for retry of session. At this stage, TCP peer/receiver is still waiting for remaining part of previous SIP INVITE(SIP session packets). This leads to session failure or delay for all further sessions until TCP connection is reset and re-connected or pending data is received and acknowledged by the receiver.¶
SIP Over Cellular Networks (IMS), [IMS] recommends IPSec [RFC4301] to apply for integrity and authentication protection. In order to configure the inbound and outbound security association [RFC4301], client and server negotiates specific ports during IMS Registration procedure as described in [IMS] and [RFC3329]. Since both client and Server are operating with fixed ports, IMS user doesn't have option to re-establish TCP connection with different ports to attain the service continuity. currently for IMS user to recover is to perform IMS De-registration and Re Register with new fixed IPSec Ports But this procedure delays IMS session and user is unreachable during re-registration period.¶
The existing methods addresses this problem by changing congestion window (cwnd) of the sender based on congestion control algorithms example : [RFC9438]. A paper on HOL [OPTHOL] addresses the HOL blocking by using Forward Error Correction (FEC). But congestion control algorithms and FEC cannot solve the issue of HOL blocking, until the transmitted segments are acknowledged by the TCP receiver or recovered by using FEC. The delayed acknowledgment is causes multiple session failures when packet loss probability is high and further application transaction fails due to delay in application session response.¶
TCP application can use TCP User Timeout Option (UTO) [RFC5482] to terminate s the session after timeout for unacknowledged data. But this option is not useful for IMS as it impacts session continuity as the IMS user needs to re-establish the IMS session after session closure.¶
This paper proposes to extend TCP flags by utilizing one bit among the four reserved bits. This new control bit is termed as Fast Window Advance (FWA) as shown in below figure¶
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |F|A|C|E|U|A|P|R|S|F| |
| Offset|Rvd|W|E|W|C|R|C|S|S|Y|I| Window |
| | |A| |R|E|G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Options ] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
: Data :
: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that one tick mark represents one bit position.
where control bit¶
FWA : 1 bit¶
Fast Window Update¶
When application has closed its session as failure and application wants TCP layer of both sender and receiver to flush any previous data even if application data is not acknowledged by the receiver.¶
application can configure setting FWA flag through socket option interface.¶
TCP control block in the sender and receiver will store the Sequence Number Variables related to the TCP connection such as¶
SND.NXT - send next (sequence number to be used to send next data)¶
RCV.NXT - receive next (expected sequence number at the receiver)¶
This document adds one such variable (SND.FWS) to TCP control block¶
SND.FWS - send fast window to store the sequence number to be used in FWA bit (1) Segment¶
SND.FWS is set to initial value of ISS (initial send sequence number) during the connection establishment. When the TCP Sender Sends the data to receiver. SND.NXT is updated with next in sequence sequence number. so¶
if SND.FWS < SND.NXT then¶
SND.FWS stores maximum sequence number sent by the TCP in the connection.¶
When the socket option to set FWA flag is received from the application TCP sender will set the FWA Flag in the next in-sequence segment to the receiver. TCP Sender use sequence number as in SND.FWS in FWA(1) TCP Segment. The sender application logic choses to set TCP FWA flag to discard any pending previous data at the TCP buffers. Through this socket option TCP sender invokes the FWA functionality.¶
<SEQ=SND.FWS><ACK=RCV.NXT><CTL=FWA,ACK>¶
At the TCP receiver, the FWA flag will force to advance its receiver window to set RCV.NXT to same as received sequence number and clear any pending data present in the receive buffer up to SND.FWS.¶
if (FWA is 1 in TCP FLAGS)¶
TCP receiver, will acknowledge the change in the RCV.NXT through ACK segment to the sender. TCP sender uses the TCP ACK segment to flush the pending buffer in the sender's buffer up to the sequence number (RCV.NXT) received in the TCP ACK segment.¶
Through this mode of operation, TCP receiver window will avoid HOL blocking of previously timed out/failed transaction and sends ACK to sender with updated sequence in ACK field of TCP header. This will allow both sender and receiver to continue next session without any HOL blocking caused by previous failed application session. TCP Header with FWA flag operation can clear partial received data that is waiting for remaining segments.¶
There is no negotiation needed in TCP handshake to negotiate the support of TCP FWA, TCP implementations which does not support FWA interpretation of TCP header can continue by ignoring the FWA bit. Since the flushing and changing the sequence number depends on positive ACK from the receiver. if the receiver does not support FWA, receiver sends the next expected sequence number as per the [RFC9293], so sender can not advance the window.¶
The receiver after receiving the segment with FWA bit set , should not delay the sending of the ACK even though delayed ACK is enabled and receiver SHALL repeat sending the ACK every 0.5 secs until sequence number from the sender changes from previous SND.FWS sequence number. This is to accelerate the buffer cleaning procedure in the sender and middle boxes.¶
The FWA bit does not impact the regular TCP connections which does not implement TCP Window Advance (FWA bit) both on sender and receiver.¶
TLS applications does not set FWA, as it will encounters decryption failures when FWA bit is set¶
There is no impact on stateless middle boxes, as these middle boxes are transparent or not alter the sequence numbers in between the end points. In stateful middle boxes, shall use the sequence numbers mapping between the entities to map the received sequence number,to generate the new sequence number of outgoing TCP connections.¶
Addition of FWA flag based on senders discretion improves the good put of the TCP. As the unnecessary retransmissions for timed out applications sessions are avoided.¶
example to describe the socket option usage:¶
int setsockopt(int socket_descriptor, int level, int option_name, char *option_value, int option_length)¶
socket_descriptor : socket id¶
level : IPPROTO_TCP¶
option_name : TCP_FWA¶
option_value : 0 : TCP FWA is not enabled 1 : Enable TCP FWA for the tcp connection¶
When option_value set to 1 : TCP Sender enables the TCP FWA functionality to clear the TCP senders buffer upto send_max¶
in TCP FWA function : TCP Sender adds FWA bit to TCP header. TCP Sender sets the sequence number send_max in seq.number field of the TCP Header. TCP Sender sets the last received or sent acknowledgement number in acknowledgement filed of TCP Header.¶
So application using setsockopt with TCP_FWA Enable(1) has option to discard the pending unacknowledged data upto send max sequence number. based on the application transaction status.¶
This document defines a a new flag in TCP Header which do not add any new security concerns beyond those discussed in [RFC9293].¶
This document requests new TCP flag in TCP header to indicate the FWA bit.¶