Subject: Re: [Tsvwg] Comments on draft-ietf-tsvwg-tcp-ulp-frame-00.txt

From: "Edward A. Gardner" <[email-masked]>
Date: Thu, 25 Oct 2001 10:25:36 -0600

Douglas Otis wrote:

>May I also add there is an additional general omission from this proposed
>encapsulation.  As iWarp, iSCSI, RPC, Ad Infinitum expect the ability to
>place data chunks into user space, a general provision for doing so should

While there are many protocols that expect the ability to place data chunks
in user space, there are many conceptual models for doing.  The closest I
know of a common model is the RDMA / iWARP model.  Yet several protocols
(e.g. iSCSI) claim to not want the RDMA model, and I see little reason to
coerce square pegs into round holes.  If you can devise a universal memory
placement model, I urge you to document it in full detail.  I would applaud
anyone who succeeded at such an endeavor.

I would contrast this with CRC checking.  There is little disagreement on
the use of CRC for non-cryptographic validity checks.  We were already
working towards agreement on a common polynomial.  Agreeing on common
placement is in one sense a trivial enhancement, but one that pays off amply
in hardware support.

>As far as CRC, the all ones initialization ensures proper processing of
>leading zeros.

And storing the complemented CRC brackets the end of the frame.  Together
they encode the frame length.  This encoding of the frame length "beats"
against the encoding resulting from the length field (actually the length
field and the first 16-bits of the key, since the CRC is 32 bits).  In
certain combinations they might cancel out, resulting in lesser protection
(e.g. an equivalent 16-bit CRC).  Evaluating whether this might actually
occur requires knowledge of the specific polynomial and an exhaustive amount
of detailed study.

However, we don't need that for a decision.  Including the complements
creates a possible risk and provides no benefits.  Omitting the complements
avoids the risk with no adverse consequences.  Conclusion: omit the
complements and skip the exhaustive analysis.

If you look at existing practice with CRCs, the interconnects that use the
CRC complement trick do not have length fields.  They all determine packet
length from carrier sense or out of band delimiters.  The complements encode
the packet length and framing into the CRC to validate that the out of band
framing was valid.

Interconnects that have length fields generally use straight CRCs (no
complementing), since the CRC covers the length field directly.

Anytime one encodes the same information in multiple ways and covers them
with the same CRC there is a risk that the two encodings may cancel out,
provided the total size exceeds the CRC length.  That would be the case
here.

Edward A. Gardner               [email-masked]
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 25 Oct 2001 11:53:07 -0700

Edward,

> While there are many protocols that expect the ability to place data
> chunks in user space, there are many conceptual models for doing.  The
> closest I know of a common model is the RDMA / iWARP model.  Yet several
> protocols (e.g. iSCSI) claim to not want the RDMA model, and I see little
> reason to coerce square pegs into round holes.  If you can devise a
> universal memory placement model, I urge you to document it in full
detail.
> I would applaud anyone who succeeded at such an endeavor.

In the past, I have made an initial effort at such a scheme employing SCTP.
I added a payload type that included a data placement offset at the
beginning of this defined payload encapsulated as an SCTP data chunk.  I see
nothing that would prohibit this being a standard mechanism for many
different protocols including iWarp.  I think it is still in the draft
library.

> placement is in one sense a trivial enhancement, but one that
> pays off amply in hardware support.

As there has been already significant work in establishing an extensible
format that can encompass more than a single application while allowing for
network layering, it would seem to place such an effort years ahead by
taking advantage of this.  If you must muck with TCP to achieve user space
data placement, adopting the SCTP structures would still allow convergence
for both hardware and software support.  Review the intent behind this
framing effort and discover a desire to create a new transport for doing
exactly the same thing as SCTP.  Those wishing to "invent" the ideal
transport do not wish to saddle themselves with the seemingly odd Stream
convention that does not fit directly into their preconceived structures.
Rather than restructuring this communication, they wish to wipe the slate
clean.  In doing so, there is no clear means for extension, multiple
application use, or standardized transport for proper layering.  Instead you
hear about packet filtering and various signaling methods that are not
described in these specifications.  Such obfuscation will thwart any
community efforts as this "new" transport becomes a conglomeration of
proprietary implementations.

> occur requires knowledge of the specific polynomial and an
> exhaustive amount of detailed study.

As CRC is an XOR process, feeding zeros into zeros does nothing until the
first one is introduced.  By initializing the CRC value to all ones, as is
the convention for Ethernet, a change in the number of leading zeros will
result in different values.  The inverted store helps delineate trailing
zeros which should not be a problem for SCTP.  These two techniques do not
"beat" nor detract from each other.

> creates a possible risk and provides no benefits.  Omitting the
> complements avoids the risk with no adverse consequences.  Conclusion:
> omit the complements and skip the exhaustive analysis.

These techniques have a benefit or they would not be employed.

> length from carrier sense or out of band delimiters.  The complements
> encode the packet length and framing into the CRC to validate that the out
> of band framing was valid.
>

I have no reason to disagree with this statement but my comment was about
all ones initialization.

> provided the total size exceeds the CRC length.  That would be the case

I do not understand this statement.

Doug