ietf
[Top] [All Lists]

Re: An alternative to TCP (part 1)

2001-02-06 20:50:02
I think it would be very difficult to replace TCP.  However, a new
transport protocol that worked better than TCP in very high bandwidth / 
low delay conditions might be very attractive for hosts and applications
that were able to take advantage of it.

I don't agree that abundant IPv6 addresses remove the need for something
akin to a port number.   They might remove the need for transport-level
multiplexing, but only if any host could allocate a sufficiently large
subnet, and it's not clear that this will be the case.  However port
numbers are also used to form names of connection endpoints, and we have
some need for well-known endpoint names to reach standard services. 

We could think of IPv4 addresses as being 48 bits long, but the fact that
we "know" which bits are the host bits and which ones are the port bits
is what lets us use port numbers as well-known endpoint names.

We could solve this problem differently than by overloading of port numbers.
For example,.we could make the endpoint name a parameter of a SYN packet,
and have the response include the actual address to be used.  This would
be a useful facility for other reasons, including ability to load
balance a service across several hosts without having to result to
NAT-like kludges.  

Getting rid of port numbers would also make traffic analysis/classification
and filtering more difficult, which has both advantages and disadvantages. 

Keith

p.s. Personally I'm interested in a transport protocol for the other end
of the spectrum - something which has the order-preserving, duplicate
suppressing, and clean open and close properties of TCP but which can
exchange small amounts of data in one or two round trips, and degrade
to something no worse than TCP for larger amounts off data...  this 
would avoid the dilemma of whether to use TCP or UDP for simple 
RPC applications.  The difficult part of making this work seems to be 
avoiding the potential for denial-of-service attacks (similar to SYN 
attacks) without adding additional round-trips for authentication.