RE: FCIP: A question about framing

["Douglas Otis" <dotis@sanlight.net>]

Murali,

Please review the charter for this WG:

1)
"The group will focus on the transport or transports and related issues
(e.g., security, naming, discovery, and configuration), as opposed to
modifying existing protocols."

2)
"The WG cannot assume that any changes it desires will be made in these
standards, and hence will pursue approaches that do not depend on such
changes unless they are unavoidable."

3)
"It may be necessary for traffic utilizing the WG's encapsulations to pass
through Network Address Translators (NATs) and/or firewalls in some
circumstances; the WG will endeavor to design NAT- and firewall-friendly
protocols that do not dynamically select target ports or require Application
Level Gateways."

4)
"The WG will not work on:
- Modifications to internet transport protocols or approaches requiring
transport protocol options that are not widely supported, although the WG
may recommend use of such options for block storage traffic."

This FC encapsulation proposal changes TCP explicitly for use with FC
encapsulation (not even as an option to TCP) and violates the WG charter.
RFC 2960 allows desired alignment and precise encapsulation for the desired
acceleration without violating a transport specification.  As there is a
valid alternative that does not require modification of a transport protocol
for desired features, there is little justification for making these
changes.

Doug


> 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
>
>
> -----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
> >
>
>