ietf
[Top] [All Lists]

Re: An alternative to TCP (part 1)

2001-02-08 11:10:03
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
randall(_at_)stewart(_dot_)chicago(_dot_)il(_dot_)us or rrs(_at_)cisco(_dot_)com
815-342-5222 (cell) 815-477-2127 (work)