Subject: doubts in rfc793

From: [email-masked] (Bhavesh Pathak - BasisComm)
Date: Sat, 10 Jul 1999 14:02:03 -0700 (PDT)

Dear everybody,
while going through the rfc793, I got following doubts. I absence
of any active mailing list where such a basic rfc can be help to 
resolve this kind of doubts, I am sending this queries to this list.

with regards,
bhavesh

Doubt-1
-------

      TCP A                                            TCP B

1.  CLOSED                                           CLOSED

2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...

3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT

4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED

5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

7.             ... <SEQ=101><ACK=301><CTL=ACK>     --> ESTABLISHED

   Simultaneous Connection Synchronization  (Figure 8.) 

Here(at line 6), I am not able to understand why TCP-B needs to re-transmit 
another SYN. 

Doubt-2
-------
The RFC says that  (this is just after connection diag. in the section 3.4)
"1. If the connection does not exist (CLOSED) then a reset is sent
    in response to any incoming segment except another reset. In particular, 
    SYNs addressed to a non-existent connection are rejected by this means. "
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    RFC seems to be saying that SYN addressed to non-existent connection
    is illegal. But, I think that when we are opening a connection, the SYN 
    can be addressed to ONLY non-existent connection because SYN only 
    starts up the connection.

Doubt-3
-------
RFC refers to "security level, compartment and precedence", have this
been in implemented in the TCP/IP stacks. 

Doubt-4
-------
RFC says that,
"The sending TCP must be prepared to accept from the user and send at 
 least one octet of new data even if the send window is zero. The sending 
 TCP must regularly retransmit to the receiving TCP even when the window 
 is zero."

 1. when send window is 0, how tcp will be able send data?
 2. does it mean that retransmission are not affected by the present
    window size (0 in the above case)?

---

From: der Mouse <[email-masked]>
Date: Sun, 11 Jul 1999 03:13:45 -0400 (EDT)

>     is illegal.

Basically, yes, though I would prefer a different word, since it's
valid to attempt to connect when there's nobody listening.  The
receiving TCP stack just has to reject the attempt.

>     But, I think that when we are opening a connection, the SYN can
>     be addressed to ONLY non-existent connection because SYN only

This is a flaw in the language.  When there is "someone there", the
receiving stack has a TCB in SYN-SENT or LISTEN (the former only in the
case of a simultaneous open, something that I suspect essentially never
happens in practice).  In the sentence you emphasized, I believe
"connection" really means "address/port pair" (loosely, "socket").

>  1. when send window is 0, how tcp will be able send data?

It can't.  The point of this low-rate constant retransmission is to
probe the window, so that in case it opens but the packet carrying that
fact manages to get lost in transit, data transfer doesn't stall
indefinitely.

>     window size (0 in the above case)?

Retransmission of what?  Zero-window probes are very different from
retransmitting already-sent data.  I don't recall offhand what you're
supposed to do if you send some data that's in-window, the peer shrinks
its advertised window so that what you sent is partially (or entirely)
past the window before acking what you sent, and then your
retransmission timer goes off.  It seems to me there's little point in
sending data outside what you think the window is, except for two
cases: (1) zero-window probes and (2) when the bandwidth*delay product
is high enough that the window is likely to have opened by the time the
segment arrives.  The latter case is hard enough to predict that it's
probably better addressed by window-enlargement schemes, it seems to
me.  (If the bandwidth*delay product is larger than the peer's
available buffer space, but the peer is fast enough to swallow bits at
full path bandwidth, this strategy will lose.  I suspect this is
relatively rare.)

					der Mouse

			       [email-masked]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B