Hi,

In the TCP RFC, it is recommended to use a 4 microsecond clock interval
for generating ISNs (Initial Sequence Numbers). In general, clock-based
sequence number systems limit the generation of new segments to the
clock rate. However, in TCP bytes are numbered instead of segments.

Taking this all together, this would mean that a TCP connection cannot
exceed a datarate of 250,000 bytes/s (i.e. no more than 1 byte per 4
microsecond). Does this mean that most TCP implementations don't limit
the datarate to the clock rate? (Otherwise, no more than 2 Mbps would
be possible over TCP...) And if so, how do they prevent the actual
sequence numbers to enter the forbidden zone from below (i.e.
increasing faster than the ISN curve)?

Thanks,

Dorian

In article <1160943999.767676.255170@e3g2000cwe.googlegroups. com>,
Dorian <dorianiii@gmail.com> wrote:

>In the TCP RFC, it is recommended to use a 4 microsecond clock interval
>for generating ISNs (Initial Sequence Numbers). In general, clock-based
>sequence number systems limit the generation of new segments to the
>clock rate. However, in TCP bytes are numbered instead of segments.

>Taking this all together, this would mean that a TCP connection cannot
>exceed a datarate of 250,000 bytes/s (i.e. no more than 1 byte per 4
>microsecond).

No, it would mean that you couldn't have more than 250,000
Initial Sequence Numbers (ISNs) per second -- 250,000 new connections
per second -- because, as you point out, after the ISN the SN increase
bytewise.

>Does this mean that most TCP implementations don't limit
>the datarate to the clock rate?

I don't believe they ever did, but I could be wrong. The recommendation
these days is to randomize the ISNs in order to deter connection
hijacking.

>(Otherwise, no more than 2 Mbps would
>be possible over TCP...) And if so, how do they prevent the actual
>sequence numbers to enter the forbidden zone from below (i.e.
>increasing faster than the ISN curve)?

Using changing ISNs is based upon the premise that there might be
some manner of SYN ACK segment hold time (e.g., routed the long way around
the world) comparable to the time to give up on a connection
that didn't receive a response, and that the delayed segment
arrives -just- as you are attempting to re-establish the connection;
if the ISN is always the same, then the delayed segement would be
accepted as if it were the new segment being awaited. If, though, one
randomizes the ISNs, then even if this kind of delay happened a lot
(which it doesn't), the probability of a clash for any given such
event would only be 1 in 2^32.

There's probably a "Birthday Paradox" argument that increases the absolute
probability, but "Birthday Paradox" arguments rely on the possibly-
matchable event having happened -- i.e., would rely upon there being
a number of occasions upon which SYN ACKs happening to get delayed
exactly to the point where a new SYN ACK with the same layer 4 parameters
is expected. I suspect that's a pretty low probability itself.

Teleset Canada's web site puts satellite delay (including signal
processing time) at about 320 milliseconds. If we started with
a TTL of 255 and assumed that (for maximum time delay) we had the
signal being routed to a satellite and back at each hop, that'd
give us (254 * 320 / 1000) = 81.28 seconds of delay. It appears that
the microsoft default initial transmission timeout is 3 seconds
according to the knowledgebase (hmmm, I was sure I'd seen it *much*
higher than that!); older TCP discussions seem to imply that 20-30 seconds
of delay is routinely expectable. Even with 3 seconds, you'd need
to be doing averaging 5 satellite hops in each direction in order to get
a delay in the right range; it doesn't seem very likely these days.

You're misunderstanding the purpose of the ISN.

The purpose of the ISN is to ensure that if a connection reuses the
same source and destination ports and addresses soon after the previous
connection using those ports/addresses is closed, that the data from
the two connections are not mixed. [The problem was discovered by
Ray Tomlinson c. 1974 when his tests using one of the first TCPs to
send stuff to a printer began mixing files in the printouts].

So the ISN limit would affect the number of TCP connections per unit
time (and, if one were truly careful, only the number of TCP connections
with the same port/address combo, but I don't know of anyone who does
that).

Craig


"Dorian" <dorianiii@gmail.com> writes:

>In the TCP RFC, it is recommended to use a 4 microsecond clock interval
>for generating ISNs (Initial Sequence Numbers). In general, clock-based
>sequence number systems limit the generation of new segments to the
>clock rate. However, in TCP bytes are numbered instead of segments.

>Taking this all together, this would mean that a TCP connection cannot
>exceed a datarate of 250,000 bytes/s (i.e. no more than 1 byte per 4
>microsecond). Does this mean that most TCP implementations don't limit
>the datarate to the clock rate? (Otherwise, no more than 2 Mbps would
>be possible over TCP...) And if so, how do they prevent the actual
>sequence numbers to enter the forbidden zone from below (i.e.
>increasing faster than the ISN curve)?

>Thanks,

>Dorian

Well, my confusion comes from the following explanation in Tanenbaum's
'Computer Networks" bible, section 6.2.2. where the principle of
clock-based ISNs and the concept of "forbidden region" are explained.
Tanenbaum says:

"The illegal combinations of time and sequence number are shown as the
forbidden region in Fig 6-10(a). Before sending any TPDU on any
connection, the transport entity must read the clock and to see that it
is not in the forbidden region.
The protocol can get itself into trouble [...] If a host sends too much
data too fast on a newly-opened connection, the actual sequence number
versus time curve may rise more steeply than the initial sequence
number versus time curve. This means that the maximum data rate on any
connection is one TPDU per clock tick."

(The figure can be found on the book home page:
http://authors.phptr.com/tanenbaumcn...geFigures.html)

Combining this statement with the 4 usec clock in TCP, I came to my
original conclusion, which obviously is wrong.

So, given the answers given here, does all this mean that after a
crash, a TCP connection can only be reopened after waiting for the
maximum packet lifetime to expire? Otherwise, the following could
happen: we open a new TCP connection with ISN x, send out data at a
much higher rate than the ISN clock rate, after which the host crashes.
If it immediately reboots and reopens the same connection (with a new
ISN, of course), the sequence numbers used might overlap the ones used
in the old connection.

Thanks for your replies, they are much appreciated!

"Dorian" <dorianiii@gmail.com> writes:

>Well, my confusion comes from the following explanation in Tanenbaum's
>'Computer Networks" bible, section 6.2.2. where the principle of
>clock-based ISNs and the concept of "forbidden region" are explained.
>Tanenbaum says:

Andy's right except that now that we use timestamps in the TCP
sequence number, you don't have to worry. In general, folks usually
don't worry anyway, as the risk is one of packet duplication -- which
is rare and so people haven't worried much about it. To explain slightly
more, you can't wrap the sequence space until all the segments have
been acknowledged -- so what you need is either (a) a retransmitted
segment that shows up late or (b) a duplicate segment that shows
up late.

>So, given the answers given here, does all this mean that after a
>crash, a TCP connection can only be reopened after waiting for the
>maximum packet lifetime to expire? Otherwise, the following could
>happen: we open a new TCP connection with ISN x, send out data at a
>much higher rate than the ISN clock rate, after which the host crashes.
>If it immediately reboots and reopens the same connection (with a new
>ISN, of course), the sequence numbers used might overlap the ones used
>in the old connection.

Precisely the problem Tomlinson found and yes, that's what systems should
do. In fact, most implementers ignore this and simply assume that
the system reboot time is longer than the MSL. I believe RFC 1123 has
some discussion on the subject.

Craig