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.