Re: An alternative to TCP (part 1)

["Randall R. Stewart" <[e-mail]>]

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


Jun'an Gao wrote:
> 
> 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.

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

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

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

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

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

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

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

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

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

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

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



> 
> 6.  Doing traffic shaping at the network edge is better than on the host node for
>     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...

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


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

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. 

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

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
[e-mail] or [e-mail]
815-342-5222 (cell) 815-477-2127 (work)