Re: FCIP: A question about framing

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

Murali Rajagopal wrote:
> 
> Doug/Milan:
> 
> Just another clarification on the SOF/EOF.These codes are NOT used for TCP
> level framing.
> These codes are needed to retain the frame identity.The intenet is to map a
> single FC Frame
> to a single TCP segment and get a "datagram-like" behavior. PUSH flag also
> helps to accelerate
> the situation in this regard.
> 

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

> -Murali
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Douglas Otis
> Sent: Wednesday, November 01, 2000 5:34 PM
> To: Murali Rajagopal; Merhar, Milan; ips@ece.cmu.edu
> Subject: RE: FCIP: A question about framing
> 
> Murali,
> 
> I fully understand a need for alignment.  TCP however will not provide any
> alignment!  With respect to the FC frame bytes, an encapsulation process
> could easily move both SOF and EOF into a prefix to aid in processing these
> bytes.  This prefix could include a timestamp as well.  Do you know the
> algorithm for creating these byte codes?  For alignment, you should review
> RFC 2960.
> 
> You can see an example at:
> http://search.ietf.org/internet-drafts/draft-otis-fc-sctp-ip-01.txt
> 
> Doug
> 
> > Doug/Milan:
> >
> > Although there are 4 bytes specified, only a single byte is really used.
> > The reason for using 4 bytes instead of one was word boundary alignement
> > previously discussed in FC-BB T11 WG.
> >
> > Hope this helps.
> >
> > Murali Rajagopal
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Merhar, Milan
> > Sent: Wednesday, November 01, 2000 10:11 AM
> > To: ips@ece.cmu.edu
> > Subject: FCIP: A question about framing
> >
> >
> > I was pleased to see the new draft for FC over IP
> > ( draft-ietf-ips-fcovertcpip-00.txt ) but something
> > in it left me a bit puzzled.
> >
> > The encapsulation that is described envelops the
> > entire FC frame, including its SOF and EOF delimiters,
> > and then transports it over TCP.  The draft correctly
> > points out that in FC the SOF and EOF sequences
> > are encoded at the 8b10b level starting with a "comma"
> > character, which is a reserved 10-bit code, which does not
> > correspond to any 8 bit value.  But, it then says
> > that SOF and EOF are encoded in TCP as 4 byte sequences.
> >
> > This is where I get confused.  Don't you then have to
> > prohibit the appearance of the SOF and EOF sequences
> > (which are now just a set of four regular bytes)
> > in the normal payload stream, using a processing-intensive
> > technique like escape sequence insertion, etc?
> >
> > The only other alternative that comes to mind is to use
> > the presence of a valid CRC as a gate to on accepting an EOF
> > sequence.  And that, I believe, is patented technology.
> >
> > - milan
> >

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