Subject: TCP "doubt"s

From: der Mouse <[email-masked]>
Date: Fri, 14 Dec 2001 06:28:46 -0500 (EST)

> DOUBT : Lets say, that applicaion A (sending TCP) has sent
> application B (Receiving TCP) a segment of 1000 bytes.  Of these 1000
> only 500 reached B and A has to retransmit the rest (500 bytes).

I don't think this is possible.

If a sending TCP sends a segment, I _think_ it's all-or-nothing, that
it can't partly but not entirely reach the receiving TCP.  (If it's
fragmented, it can partially but not entirely reach the receiving TCP's
host, but if a fragment is lost reassembly will fail and the partial IP
packet will be discarded rather than passed up to the TCP layer.)

However, something very similar _is_ possible.

If the receiving TCP can't hold all the incoming segment's data for
some reason, it seems to me that it's permissible for it to ACK only
the part that it can keep.  Page 74 of RFC 793 seems to imply that a
receiving TCP may accept some but not all of the data in an incoming
segment, in which case it should, of course, ACK only the data it
actually accepts.  (If it can't take it all, it really should have
advertised a smaller window, but I'm sure there will be cases where
that's not possible.)  How reasonable this is is another question.

> 1 )  Can A now send a segment of these 500 bytes only ? Or, it MUST
> append 500 bytes lying next to this segment and then send a segment
> of 1000 bytes ?

I can't see any reason it must - or even should - retransmit
already-acked data just for the sake of retransmitting unacked data in
the same context it was originally sent in.

Of course, I've missed things plenty often before, and will again.  If
someone has such a reason, I daresay we'll hear about it. :-)

> Which of the above should be followed ?

Absent some reason it must retransmit the whole thing, I'd say it's
probably better to send only the unacked stuff.

> 2 )  if the former is allowed, does it lead to silly wondow syndrome
> (lets say, instead of 500 bytes we had to retransmit 50 bytes)?

I don't think so, provided we're careful to send a full segment if we
have enough data waiting following the unacked portion.

> DOUBT : When a segment arrives with a "push" bit set, do we need to
> inform the PUSH bit to the application ?

You should push the data to the application, if it's ready to accept
it.  I see no reason to tell the application where PSH bits actually
appeared in the data stream; indeed, RFC793 specifically says "The
exact push point might not be visible to the receiving user and the
push function does not supply a record boundary marker.".  However, the
"receive" call from the higher layer does include a "push seen" flag in
the return; this seems to be largely for user convenience, and I've
never seen it actually reflected to userland in sockets, which are
depressingly close to a near-universal TCP API.

My impression from 793 is that PSH basically means "don't wait for more
following data before getting this data to the receiving process".
Implementations I've looked at behave, loosely speaking, as though
every incoming segment had its PSH bit set - they never gratuitously
withhold data they have from the application.  PSH is perhaps more
important on the transmitting TCP's send call; sockets generally behave
as though every completed send()/write()/etc implies a push,
unfortunate as this is in some respects.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B