Subject: RE: An alternative to TCP (part 1)

From: "Jun'an Gao" <[email-masked]>
Date: Wed, 07 Feb 2001 09:59:12 +0800

> i hope you know about RFC1323 ftp://ftp.isi.edu/in-notes/rfc1323.txt
Well, I believe I have read rfc1323. I think I should give a short comparison between ATP and the enhancements of TCP (The enhancements include ECN.). I'll make the comparison(it may take me quite a few days for I 'm not a fluent English writer:-( ) after I have fully translated and posted the essay on ATP, which is originally written in Chinese. 

As to ECN, I believe it is a good idea. But ECN requires a somewhat fundamental change in the routing system. And it consumes two bits in the IP header (in the diffserv/traffic class field). I don't think it is feasible to implement ECN in an IPv4 network. I think designing a new transport protocol optimizing for IPv6 may be a better choice for the next generation Internet. In the key point 6, I specify that (trivially-updated) ECN is 'now' mandatory.

As to the sequence number, I have to confess that a 32 bit word counting byte is definitely abundant at least in the near future. But suppose some day TCP is applied in an ultra-high-performance distributed computing misson. Suppose two ultra-high-performance computers(or, some future version iSCSI devices) are linked with a 100Gbps network. I don't think it is difficult to design  I/O ports for two SMP computers each with four 500Mhz 64-bit CPUs to consume the bandwidth. It is quite possible that the full sequence number space is depleted in less than 345ms(The Twap should be less than about 170ms  in 100Gps network  for TCP to work correctly, according to rfc1323). Maybe the fiber network would never carry 100Gbps in a single lamda. Maybe never two computer joining in a ultra-high-performance distributed computing mission would be partitioned by a 100Gbps network with delay longer than 170ms.  Yet I want to quote the statement in rfc1323(page 6) 'Moving  towards gigabit speeds, Twrap becomes too small for reliable  enforcement by the Internet TTL mechanism' to call for pondering over the 32 bit TCP sequence number which counts byte.

Cheers!
Gao.

---

From: Keith Moore <[email-masked]>
Date: Tue, 06 Feb 2001 22:46:02 -0500

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.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Feb 2001 21:56:30 -0800

At 22:46 06/02/2001 -0500, Keith Moore wrote:
>exchange small amounts of data in one or two round trips,

One of the history lessons on this list about 6 months back referred to Dag 
Belsnes' original research proving that you cannot move a data item and end 
up with both parties knowing that the data has arrived safely in less than 
5 packets. Other people have the referents....it's not obvious to me either.
It's probably this one from RFC 675's reference list, but to find it...?

  BELS74

       D. Belsnes, "Note on single message communication," INWG Protocol
       Note #3. September 1974.

(In TCP, the packets are the 3-way handshake and the FIN exchange)

T/TCP can achieve shorter packet sequences by leveraging knowledge from 
previous interchanges. You can get away with fewer exchanges if you are 
willing to (for instance) have the recipient not know whether the sender 
thinks the data has been transmitted safely, I think.

So there is a limit to what is achievable....

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 07 Feb 2001 08:03:37 +0000

>>some need for well-known endpoint names to reach standard services. 

this is debateable - if we used GSE/8+8, then the route glop could get
you somewhere and the site glop to a machine ,and chaning EID is not
such a crazy idea at all - there have been protocol stacks like this
and there are certain privacy and other security advtangaes (it was
used in a secure ATM proposal i seem to recall fro mcambridge
university computer lab about 7 years ago...)

cheers

   jon

---

From: Keith Moore <[email-masked]>
Date: Wed, 07 Feb 2001 08:31:43 -0500

> So there is a limit to what is achievable....

Fascinating...if anyone can supply a usable reference, I'd appreciate it.

One of my assumptions about the operating environment for this protocol
is indeed that the initial receiver (i.e. the server) doesn't need to know 
that the initial sender (client) received its entire transmission - it's 
up to the client to retransmit if necessary.  Another of the assumptions
is that both the request and the response can often be contained in a 
single packet, so that (when both conditions hold) sequence numbering isn't 
an issue. 

For the cases when neither of the above is true, the protocol should
"upgrade" to TCP or something like it.

Keith

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 07 Feb 2001 08:59:25 -0600

Is that a bit of chauvinism, Harald?   :-)

D. Belsnes, "Single-Message Communication," IEEE Transactions on
Communication, Vol. TCOM -24, No. 2, pp.  190--194, February 1976.