Re: FCIP: A question about framing

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Marjorie:

Let me give you a quote from RFC1122 about the PUSH bit:

"


         4.2.2.2  Use of Push: RFC-793 Section 2.8

            When an application issues a series of SEND calls without
            setting the PUSH flag, the TCP MAY aggregate the data
            internally without sending it.  Similarly, when a series of
            segments is received without the PSH bit, a TCP MAY queue
            the data internally without passing it to the receiving
            application.



Internet Engineering Task Force                                [Page 82]




RFC1122                  TRANSPORT LAYER -- TCP             October 1989


            The PSH bit is not a record marker and is independent of
            segment boundaries.  The transmitter SHOULD collapse
            successive PSH bits when it packetizes data, to send the
            largest possible segment.

            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
            are not implemented, then the sending TCP: (1) must not
            buffer data indefinitely, and (2) MUST set the PSH bit in
            the last buffered segment (i.e., when there is no more
            queued data to be sent).

            The discussion in RFC-793 on pages 48, 50, and 74
            erroneously implies that a received PSH flag must be passed
            to the application layer.  Passing a received PSH flag to
            the application layer is now OPTIONAL.

            An application program is logically required to set the PUSH
            flag in a SEND call whenever it needs to force delivery of
            the data to avoid a communication deadlock.  However, a TCP
            SHOULD send a maximum-sized segment whenever possible, to
            improve performance (see Section 4.2.3.4).

            DISCUSSION:
                 When the PUSH flag is not implemented on SEND calls,
                 i.e., when the application/TCP interface uses a pure
                 streaming model, responsibility for aggregating any
                 tiny data fragments to form reasonable sized segments
                 is partially borne by the application layer.

                 Generally, an interactive application protocol must set
                 the PUSH flag at least in the last SEND call in each
                 command or response sequence.  A bulk transfer protocol
                 like FTP should set the PUSH flag on the last segment
                 of a file or when necessary to prevent buffer deadlock.

                 At the receiver, the PSH bit forces buffered data to be
                 delivered to the application (even if less than a full
                 buffer has been received). Conversely, the lack of a
                 PSH bit can be used to avoid unnecessary wakeup calls
                 to the application process; this can be an important
                 performance optimization for large timesharing hosts.
                 Passing the PSH bit to the receiving application allows
                 an analogous optimization within the application.
"

Note in the discussion above that the Sender will collapse the
PUSH calls (if multiple are queued) into 1. It explicitly states
it is NOT a record marker.

On the receiver side you will get awoken when the segment
with the push arrives.. but this may well represent more than
one PUSH that was done by the sender... This is one of the
reasons you cannot depend on this behavior to setup your
message boundaries... Fundamentally TCP is a byte oriented 
stream.. if you are not prepared to delineate your messages
within a stream of bytes then you will have some problems making
this work... like I said... been there ... done that... it was
ugly.. and we ended up adding something like I described earlier
to solve the problem...

R




"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> Do TCP RFCs specify the behavior of the receiver regarding when to deliver
> data to the application?  From what I've read, different implementations act
> differently - some buffer data received data and deliver it to the app when
> the buffer's full, others deliver data immediately when each packet is
> received.  In either implementation, when the PUSH flag is set, all data is
> delivered immediately to the application.  In a FCoIP device, could't the
> receipt of the packet with the PUSH flag set indicate that this is the "end
> of a frame"?  Assuming that the FC aware code can also view the TCP header.
> 
> I understand the truth of what you are saying when TCP is delivering data to
> an "application", but I'm assuming that FCoTCP implementations will have
> some level of mapping interaction between the TCP and the FC layer?
> 
> > -----Original Message-----
> > From: Randall R. Stewart [mailto:randall@stewart.chicago.il.us]
> > Sent: Thursday, November 02, 2000 11:34 AM
> > To: Murali Rajagopal
> > Cc: Douglas Otis; Merhar, Milan; ips@ece.cmu.edu
> > Subject: Re: FCIP: A question about framing
> > Murali:
> >
> > Using Push does not guarantee that you will get "datagram-like"
> > behavior. You
> > must have some mechanism to find your "message" amongst a stream of
> > bytes... this is what TCP presents you with. This usually means a
> > message/finder that can parse the incoming stream and find the
> > beginning/ending of the message boundaries... Some apps have
> > been known
> > to write every message in two pieces... write the number of bytes
> > in this message in a 4 byte int, followed by the message with the PUSH
> > flag set.  Even at that the reader side must read the 4 byte value
> > and then continue to read until it has assembled a complete message.
> >
> > The PUSH flag is just a hint to TCP it does not assure you
> > that you will
> > get a datagram behavior depending on PUSH will not help you... been
> > there ..
> > . done that.. it don't work :/
> >
> > R
> >
> 
> Marjorie Krueger
> Networked Storage Architecture
> Hewlett-Packard Storage Organization
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)