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
sp!
eeds, 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.
