Subject: An alternative to TCP (part 1)

From: [email-masked] (Jun'an Gao)
Date: Tue, 06 Feb 2001 22:30:06 +0800 (CST)

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.

---

From: [email-masked]
Date: Tue, 06 Feb 2001 09:58:00 -0500

>    the transmit rate even if the loss is caused by physical link transmit error.

This may have been an issue back in the days of noisy, error-prone modems.
These days, the *right* answer is to fix the hardware.  On the other hand,
I believe much of Van Jacobsen's initial tuning work on TCP had to do with
the fact that even on noisy lossy lines, some 95% of lost packets were due
to router congestion rather than actual mangling of bits on the wire.

Yes, I know parts of the world still have poor infrastructrure.  But even
there, error-correcting modems do wonders.

And if you're in an environment such as wireless where packets literally
DO dissapear into the ether on a regular basis even when there is no
congestion, RFC2018 describes 'Selective ACK' to allow recovery without
losing your window.

>    about 36 seconds to consume the whole sequence number space when transmitting

RFC1323 addressed this issue in May 1992.

>    application might exploit UDP to avoid the congestion control of TCP.

In general, a router cannot *force* an end host to not send a packet.  The
best it can do is send a notification that if a packet *is* sent, it has a
high likelyhood to be dropped on the floor.

ICMP Source Quench - although as Van Jacobsen showed, the same effect can
be gotten just by treating a dropped packet as an implicit source quench.

>    In fact the video stream applications have caused some network    congestion troubles.

Well.. Yes.  RSVP and related are still more or less experimental...

<rest of note snipped - I didn't see where anything new was proposed that
isn't already in TCP-over-IP6+IPSec.>

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: John Stracke <[email-masked]>
Date: Tue, 06 Feb 2001 12:01:37 -0500

> 6.  Doing traffic shaping at the network edge is better than on the host node for

The host *is* the edge of the network.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |World domination should never be left to chance.|
[email-masked]|                                                |
\=================================================================/

---

From: stanislav shalunov <[email-masked]>
Date: 06 Feb 2001 12:47:06 -0500

[email-masked] (Jun'an Gao) writes:

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

But ECN seems to address this issue, and it can work for UDP as well
as TCP.

> This results in an unnecessary reduction in link bandwidth
> utilization, especially in the environment of wireless physical
> links.

One could argue that it's a responsibility of wireless link-layer
protocols to ensure that random loss is rare (say, by employing an
ECC).

> The other is that the unit of TCP sequence number is byte (octet)
> while the the sequence number is only 32 bit wide.

What practical implications does sequence numbers wrap-around have in
foreseeable future?  At 10Gbps, sequence number space will last for
3.4s, which seems to be larger than your typical round-trip time of a
hundred or two milliseconds.  It seems it could start to be a problem
at 100Gbps speeds, but current trend seems to be to increase the
number of 10Gbps lamdba channels rather than their bandwidth...

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

I never let school stand in the way of my education.       -- Mark Twain

---

From: "Rahmat M. Samik-Ibrahim" <[email-masked]>
Date: Wed, 07 Feb 2001 12:29:48 +0700

General Question:

- How to migrate?
  I have been using the "QWERTY" keyboard all the time.
  I am aware that it is not the best, but I am stuck.

Jun'an Gao wrote:

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

How are you going to route those random packets?

regards,

-- 
Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org
- Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 08 Feb 2001 12:09:46 -0600

Jun'an:

Now that I have scanned through most of this thread
I am going to pick up on this and reply :-) I have
been in a FreeBSD driver Hell so please forgive my
tardy response :-0

My bottom line thoughts after having scanned thread is
have you looked at SCTP? We have just finished almost
2 years of work and it solves some if not all of your
issues...

>    especially in the environment of wireless physical links.

This one seems to me a bit hard to solve. I think ECN is right now
the only answer and it is supported by SCTP. In either case TCP
or SCTP the solution is available in this form. It is not 100% and
of course not totaly deployed.. but that and some of the PILC work
is I think the way to go..

>    about 36 seconds to consume the whole sequence number space when transmitting

SCTP does solve this one. Since it does not track bytes but instead
Chunks. A chunk can contain close to 1 MTU of data. So in your 100Gig
e-net
scenario instead of 360 ms (I think I remember this is your claim) you 
now have 360ms X 1460  a bit longer.. but still finite.. as anything is
:-0

>    In fact the video stream applications have caused some network    congestion troubles.

And this is not a good thing... Eventually you may see UDP packets
dropped
more often when within un-responsive packet flows....

>    new IP address in each new connection, for the sake of anonymity.

I don't see how this is a big benefit.. it seems to me that
ports provide a useful abstraction within the network as well
as the de-muxing aspect. I know Keith Moore mentioned using a
"name" with a SYN packet.. but I think a look at what the wg Rserpool
is doing is beneficial in providing the fail-over that Keith mentions...

>    TCP/IP checksum. A new transport protocol should try to take advantage of AH.

Well, here SCTP does not do so. It uses the Adler32 sum. And the
work with SCTP and IPsec is just getting going :/

>    and the connection state for a considerable duration of packet exchange or    transmission.

And here SCTP can help again. There is a extension draft currently
bubbling through the IETF that allows N retransmit where N can
be anywhere from 0 to ?. N is how many attempts an individual 
data chunk can be given. See draft-ietf-sigtran-usctp-00.txt

>     the sake of application programming.

Yes, this is what ECN helps you do... but you still need
to rely on the drop packet for harsh sudden overloads of
an individual router...

> 1. Designed for IPv6. Free of constraint bestowed by IPv4.

SCTP will work on both IPv6 and IPv4.. in fact you can
have an individual association (something akin to a connection)
that spans both an IPv6 AND an IPv4 network...

> 2. No upper layer port as in TCP.

This is debatable.. I don't see removing the port gains you anything.

>    registered appropriately.

For registration issues look at Rserpool. This I think will handle
some of what you want.. it is a kind of session layer...

The binding to only one address does not provide any great gain
in my mind... you can always (as mentioned before) look at a
port as an extension to the IP address... relegating 16 bits
to  application selecting ... I don't see an advantage. 

>    IPv6 address. The allocation may be done randomly, providing client anonymity.

I just don't see the need for this. It provides some anonymity but I
would imagine I could still track you down if I want by using
the higher layer aggregators.

> 5. Receiver-Urged retransmission.

We attempted this to some degree and did not get
very far.. really SACK (which is required in SCTP) seems
to me the right choice here.

> 6. Inherit some basic mechanism and some enhancement of TCP, namely:

Been there we did that with SCTP...

> -- Piggybacking.

Yes, and multiplexing. I am also surprised you did not mention head
of line blocking. This too is a TCP problem that we worked on in
SCTP...

> -- Three-way handshaking during connection setup phase in normal mode.

Actually you should have 4 with a state cookie... this is what we ended
up with on SCTP but we do allow the two last legs of the handshake to
carry data...

> -- Initial Sequence Number selection method, which guarantee crash recovery.

Yep,

> -- Graceful simplex connection close, with modification to avoid FIN-WAIT2 deadlock.

Yep its there..

> -- Explicit congestion notification, now the mandatory congestion control and avoidance mechanism.

We have put this in.. but at the writting of SCTP we could not
refer to ECN directly since it was still experimental. I think
by the time SCTP is ready for its BIS we can mandate ECN presuming
that ECN will be on the standards track side (If I remember right
I think I saw an IESG mail saying it is):-)

> -- Accumulative acknowledgement.
Hmm I am not sure what you mean with this one  :/

> -- Selective acknowledgement.
This is mandatory...

I really think you need to have a look at

RFC2960 (SCTP)
and
the work going on in the Rserpool group in the
transport area..

Regards

R
-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 13:27:00 -0800

At 10:30 PM 2/6/2001 +0800, Jun'an Gao wrote:
>So transport layer should somehow enhance
>    the error check and/or correction mechanism.

actually, I would put it in the application layer. I would have the 
application include some form of checksum (PGP signature, file CRC, 
whatever) to ensure for itself that what was sent was what was received.