Path: utzoo!attcan!uunet!mailrus!iuvax!purdue!mentor.cc.purdue.edu!dls
From: dls@mentor.cc.purdue.edu (David L Stevens)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Proper handling of PUSH & small window by sender?
Message-ID: <7410@mentor.cc.purdue.edu>
Date: 13 Feb 90 15:50:18 GMT
References: <589@dino.cs.iastate.edu>
Organization: PUCC UNIX Group
Lines: 35

In article <589@dino.cs.iastate.edu>, hascall@cs.iastate.edu (John Hascall) writes:
>         +-+-+-+-+-+-+-+-+-+-+-+p+-+-+-+-+-+-+-+-+-+-+-+
>  case 1 |<--window--->|
>  case 2 |<----------window----------->|
>  case 3 |<--------------------window--------------------->|
> 
>     Case 1:  do I hold off, waiting for a bigger window?  (deadlock?)

	I'd say this depends on how big a segment you can send. If you can
send multiple full segments for chunk1, send all the full segments you can
up to the window (no "PUSH" set). When the window opens past chunk1, you
send that segment promptly (full or not) with PUSH set.

>     Case 2:  do I hold off, waiting for a bigger window?  (doesn't seem right)
>              do I send only chunk1 (setting PUSH)         (my current guess)
>              do I send all I can (setting PUSH)           (too much pushed?)

	I say the 3rd, because it says that "...PUSH bit will be set in the
last TCP segent created from the buffer." Since PUSH is not a record mark,
that segment can contain other data as well. It should not WAIT for other
data (buffering), but if the data is there already... In other words, this
interpretation is "send AT LEAST chunk1 promptly." Since PUSH is to avoid
buffering delays (and NOT, for example, for URGENT data), it's ok to use
the extra buffer the receiver has told you he has. The user will get a more
full buffer on his receive (better) and that's ok, because PUSH is not a
record mark.

>     Case 3:  do I send only chunk1 (setting PUSH)         (correct?)
>              do I send it all (setting PUSH)              (too much pushed?)

	Send it all. Set PUSH in the segment containing data that corresponded
to the last octets of "chunk1". Again, if the receiver has the buffer space, it
makes everything better.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)