Network Working GroupG. Bolognesi
Expires: October 3, 2006April 1, 2006

No Frills TCP: a simpler TCP

draft-no-frills-TCP beta1

Status of this Memo

This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on October 3, 2006.


Modern Internet requires more and more speed, and as time passes transmission lines get more reliable. This memo describes a simpler (and hence, faster) implementation of the ubiquitous TCP Protocol.

Table of Contents

1.  Introduction
    1.1.  Terminology
2.  TCP Performance
    2.1.  Current mode of operation
    2.2.  Shortcomings
3.  NFTCP: Proposed implementation
    3.1.  TCP packet modification
    3.2.  Modes of operation
        3.2.1.  Session establishing
        3.2.2.  Session Life
        3.2.3.  Session Teardown
4.  Further improvements
    4.1.  Recycling Useless Flags
        4.1.1.  RST
        4.1.2.  SYN+PSH
        4.1.3.  URG
    4.2.  Recycling unused header space
5.  Security Considerations
6.  Thanks
7.  References
§  Author's Address


1. Introduction

Transmission Control Protocol (TCP) [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.),[RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) is intended for use as a reliable host-to-host protocol in a packet-switched communication network and in interconnected systems of such networks. At this moment TCP is probably the most deployed networking protocol on this world. However, it shows some redundancy having been designed more than 30 years ago -- when transmission lines, computers and applications were far slower and less reliable than nowadays. In this memo we will try to show that while keeping backward compatibility with the current TCP/IP infrastructure, it is possibile to reach new heights in data transfer with some selected modifications to TCP.


1.1. 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).


2. TCP Performance


2.1. Current mode of operation

The current TCP implementation uses what is commonly referred to a "three way handshake" to establish sessions: if the destination port is open, the originator host sends a SYN packet, the receiver replies with a SYN+ACK packet, and when the originator replies with an ACK the connection is considered open. After the connection has established, both hosts update an internal state according to [RFC2581] (Allman, M., Paxson, V., and W. Stevens, “TCP Congestion Control,” April 1999.) in order to avoid network congestion. In particular, the "congestion window size" is evaluated in order to decide the amount of data which can be trasmitted by an host before an ACKnowledge is received.

If the destination port is closed, this is signalled to the originator with an RST packet, which closes the communication immediately.


2.2. Shortcomings

On slow lines, the session establishing procedure shows many shortcomings: the session opening speed is limited by the RTT, and window size may be reduced depending on the packet loss. This could limit originating host transmission speed to less then full-bandwidth, and we know by general consensus that this is the most important thing to consider.


3. NFTCP: Proposed implementation


3.1. TCP packet modification

We are proposing a completely backward-compatbile TCP implementation: routers MUST NOT modify or inspect packets as they pass though them.

The structure of the NFTCP header:

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 |N|D|  Re   |U|A|P|R|S|F|                               |
| Offset|F|S|  ser  |R|C|S|S|Y|I|            Window             |
|       |T| |  ved  |G|K|H|T|N|N|                               |
|           Checksum            |         Urgent Pointer        |
|                    Options                    |    Padding    |
|                             data                              |
 Figure 1 

Figure 1 illustrates the new defined NFTCP header in which the leftmost reserved bit is used to mark a traditional TCP packet as a NFTCP packet (indicated with NFT). Subsequently, each packet will be referred to as a "NoFrills" packet if the additional bit is used. For instance, the SYN packet will be called NFSYN.

The reserved bit marked as "DS" is another speed enhancing feature of NFTCP: all packets marked with this bit ("Don't Snoop") MUST be ignored by any security device. Packets belonging to VPN connections, private emails, and so on SHOULD be marked with this "privacy" bit, thus allowing faster traversal through firewalls and other security devices, and so lighten the load on IDS systems, and so on.

Please bear in mind that this MUST NOT collide with the directions given in [RFC3514] (Bellovin, S., “The Security Flag in the IPv4 Header,” April 1 2003.) on setting the "Evil Bit". In case of conflict, previous suggestions MUST be applied to ensure consistency. NFTCP authors support completely the EB concept, and admire its semplicity and contribution to performance.


3.2. Modes of operation


3.2.1. Session establishing

Negotiating NFTCP is easy: upon session startup, sender SHOULD generate a NFSYN packet. If the receiver replies with a NFACK, we will declare the establishing of a NFTCP session, without other time-consuming packets exchange, and then fill the connection pumping packets at full speed. Otherwise, if sender receives an "old" TCP SYN+ACK packet, it MUST establish a normal TCP session, therefore granting backward compatibility.


3.2.2. Session Life

Data flow inside a NFTCP session is easy and quick:

TCP congestion control is useless, today networks are really fast: there's no reason for wasting a few RTTs for the slow start phase if you already know that the network will accept a large amount of data without any problem. For backward compatibility, this memo recommends to fix the "congestion window size" to the maximum value and not to change it for whatever reason. This way it's easy to realize that [RFC2581] (Allman, M., Paxson, V., and W. Stevens, “TCP Congestion Control,” April 1999.) should be considered obsolete.

TCP Header Window size is useless too: RAM comes cheap these days, so stop bothering about small TCP receive buffer size and just increment its size. This allows the NFTCP to use even these 2 bytes for transmitting data thus allowing a better bandwidth usage.

MTU SHOULD be fixed-size, to 1500 bytes. Even if this specification does not belong to this RFC, it is RECOMMENDED. After all, most of the networked host on this planet are on an Ethernet network.

Sequence Number can OPTIONALLY be correct and respect [RFC1122] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.). Anyway, this SHOULD NOT be taken as granted and MAY be changed in a future specification of NFTCP to make room for additional data. If the receiver messes around with the packets sender is transmitting, and looses order, is not our fault. Stop playing with someone else's data, and nobody gets hurt.

Classical retransmission is not allowed and MUST NOT happen. Receiver MUST listen to originator, not juggle with packets. Stay put and pay attention.


3.2.3. Session Teardown

The first one of the two hosts communicating that desires closing the session MUST send a NFFIN packet. As soon as the packet is sent or received, the host MUST close the connection, MAY flush the connection caches, and free precious memory resources.

In case the remote port is closed, destination host MUST reply with a NFFIN packet even to connection requests. Semplicity is good.


4. Further improvements


4.1. Recycling Useless Flags


4.1.1. RST

As you may have noticed, NFTCP does not use the RST flag. This follows the idea to remove all those byzantine flags and complicated numbers. Anyway, it MAY be used in the future to signal the destination host to close ALL the connections with the originating host, if any.

More aggressive implementation options are being considered, but some are not backward compatible despite being very useful:

last hop router receiving a NFRST packet SHOULD rewrite the destination address with the broadcast address of the nework of the destination host. This should achieve the effect of terminating ALL current connections over the network with the sender host.

the most extreme semantic of the NFRST flag would be "Reboot": any networked host (computer, router, ...) which receives such a packet MUST schedule an orderly reboot. Without any doubt this would solve many remote administration nightmares.

It is not by chance that we choose local broadcast over a multicast group as the destination of the last hop packet: most of the machines which will benefit the most of this innovative method of remote administration will be running an OS that pioneered the use of broadcast for the most inventive purposes.


4.1.2. SYN+PSH

Turning on the PSH bit within an NFSYN packet can trigger different actions, according to the configuration of the device which will receive the packet. An host receiving an NFSYNPSH packet on a port which already has an application listening, MUST drop the packet (it makes no sense pushing an open port). If the port has not been claimed by any active application and the host is properly configured to support NFCTP, the reception of this type of packet SHOULD trigger the execution of a random application which can communicate over [NF]TCP; however having the host execute an "emergency administrative shell" (for example a root sshd for *NIX hosts, or an Administrator terminal service for Windows) will ensure a reliable help for administrators in distress (or hours of fun and relax).


4.1.3. URG

Setting the URG bit within an NFTCP packet MUST have the effect of closing all the connections with other hosts, and keep connections open with the sender only: if it's urgent, listen to us and nobody else.

In case there is no open connection with the source host, the packet MUST be discarded; destination host MAY look inside the packet to see if it contains something interesting.


4.2. Recycling unused header space

Given the secondary role of the Sequence and Acknowledge number within the header, these eight bytes of superfluous content MAY be filled up with interesting data. This can allow hosts to use a second data channel over the established one, or to use the bytes for augmenting the bandwidth of the current communication by a whopping 5%, without taking into account the suppression of the Window Size which gives us another two bytes to play with.


5. Security Considerations

Being a simple modification of the original TCP protocol, NFTCP does not have particular security problems per se. After all, the Internet was not originally built or thought with security in mind, so if the Great Fathers did not worry, why should us? Yes, the PSH part may pose some problems, but it can always be disabled.


6. Thanks

The idea behind this RFC was born troubleshooting (with other three people) the packet forwarding anomalies of a famous commercial firewall box. The original idea came out of this "Fab Three" group (you know who you are): most of the funny ideas are theirs, and errors writing them down are mine. To you three, thanks: working with you in the last couple of years has been both fun and a pleasure every day. Many others have read, laughed and suggested corrections to this document: most s0ftpj and antifork groups, and some others -- without your contribution NFTCP wouldn't be working so well. :)


7. References

[RFC0793] Postel, J., “Transmission Control Protocol,” STD 7, RFC 793, September 1981.
[RFC1122] Braden, R., “Requirements for Internet Hosts - Communication Layers,” STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2581] Allman, M., Paxson, V., and W. Stevens, “TCP Congestion Control,” RFC 2581, April 1999.
[RFC3514] Bellovin, S., “The Security Flag in the IPv4 Header,” RFC 3514, April 1 2003.


Author's Address

  Guido "Zen" Bolognesi
  1, No Way
  Milan, I-20100