ietf
[Top] [All Lists]

An alternative to TCP (part 1)

2001-02-06 07:30:03
Motivations

1. There are two annoying incompetence of TCP. One is that TCP does not
   distinguish packet loss caused by network transmission error from that
   caused by network congestion. The congestion control and avoidance mechanism 
   makes TCP drop its transmit window upon detecting a packet loss, thus lowers
   the transmit rate even if the loss is caused by physical link transmit error.
   This results in an unnecessary reduction in link bandwidth utilization, 
   especially in the environment of wireless physical links.

   The other is that the unit of TCP sequence number is byte (octet) while the
   the sequence number is only 32 bit wide. It is not a big problem for a
   no-more-than-100Mbps network. But in a modern gigabit network, it takes only
   about 36 seconds to consume the whole sequence number space when transmitting
   at the maximum bit rate.

2. There is an observation that congestion control is somewhat the obligation
   of routing system. If it were to be done by the end host, an end host
   application might exploit UDP to avoid the congestion control of TCP.
   In fact the video stream applications have caused some network    congestion 
troubles.

3. Abundant IPv6 addresses, especially the 64 bit interface ID space, makes
   transport layer multiplexing is somewhat unnecessary. IPv6 has the built-in
   support for multiple simultaneous addresses. It further recalls the necessity
   of transport layer multiplexing. And quite a number of users (would?) prefer 
a
   new IP address in each new connection, for the sake of anonymity.

4. There is no checksum field in the IPv6 fixed header. The designers of IPv6
   count on link layer and transport layer error check and/or correction 
mechanism 
   to ensure data transmit reliability. So transport layer should somehow 
enhance
   the error check and/or correction mechanism. Besides, the IPv6 authentication
   header provides a much stronger data integrity check mechanism than 
traditional
   TCP/IP checksum. A new transport protocol should try to take advantage of AH.

5. Some applications such as stream media or interactive TVs do not require
   reliability that TCP provides, but need to preserve data transmission order
   and the connection state for a considerable duration of packet exchange or   
 transmission.

6.  Doing traffic shaping at the network edge is better than on the host node 
for
    the sake of application programming.


Key Points
1. Designed for IPv6. Free of constraint bestowed by IPv4.
2. No upper layer port as in TCP.
3. There may be a number of IPv6 addresses for a physical server, each address
   is bound to one (and only one) logical network service. The services could be
   registered appropriately.
4. Each time the client end initiates a new connection it will allocate a new
   IPv6 address. The allocation may be done randomly, providing client 
anonymity.
5. Receiver-Urged retransmission.
6. Inherit some basic mechanism and some enhancement of TCP, namely:
-- Piggybacking.
-- Three-way handshaking during connection setup phase in normal mode.
-- Initial Sequence Number selection method, which guarantee crash recovery.
-- Graceful simplex connection close, with modification to avoid FIN-WAIT2 
deadlock.
-- Explicit congestion notification, now the mandatory congestion control and 
avoidance mechanism.
-- Accumulative acknowledgement.
-- Selective acknowledgement.
7. Integrated with IPv6 AH. Managed to take account of features provided by
   ISAKMP, RSVP and MPLS. Most importantly, Admission Control and Traffic
   Shaping are to be integrated in the near future.



<Prev in Thread] Current Thread [Next in Thread>