Re: frame formats

[julian_satran@il.ibm.com]

Mark,

You might be getting a better protection but the implementation is more
complex .
BTW you would have had the same level of protection with less complexity
with Format 1.

Julo

Mark Bakke <mbakke@cisco.com> on 02/04/2001 15:42:40

Please respond to Mark Bakke <mbakke@cisco.com>

To:   "Robert D. Russell" <rdr@mars.iol.unh.edu>
cc:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
Subject:  Re: frame formats




Bob-

Good point about option 2.  If we have separate BHS and AHS CRCs,
all of lengths are checked.  I don't mind having the extra CRC, since
I really don't think we will see that many PDUs use the AHS.

It is possible to optimize reading option 1 (at least in software).
Just read the 48 bytes + 4 for the digest, and if there is an AHS,
keep the extra four as part of the next read.  So you still have
a single read for most frames, and two for those with AHS.

Still, option 2 does offer the best protection.  I'm fine with
option 2, but could live with option 1.  Anything but 3.

--
Mark

"Robert D. Russell" wrote:
>
> Mark:
>
> There is a potentially important distinction between the 2 choices
> that is missing from your summary when you indicate that both
> choices involve a variable length.
>
> In option 1, a single header digest after the BHS and AHS,
> you do not know when you start reading the header how long
> it will be and therefore you do not know where the digest is.
> This complicates the reading process, since it will have to either
> do the read in 2 steps (1st the BHS and then 2nd the AHS (if any)
> followed by the digest), or 1 read that interprets the data being read
> "on the fly" to extract the AHS length and extend the length of the read
> accordingly.
>
> In option 2 the first read is always for 48 bytes of header and you
> always know where the digest is.  The second read is needed
> only if the AHS length field in the BHS is non-zero, and its length
> is determined by that AHS length field. However, when the 2nd read
> is started the length IS known and the position of the digest
> IS known -- you do NOT have the "on the fly" searching needed
> in option 1.  This may (or may not) be a simplification.
>
> The other advantage to option 2 is that the input process never
> has to use unverified data (i.e., the AHS length field) to find
> the digest (and thus verify the data).
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>
> On Fri, 30 Mar 2001, Mark Bakke wrote:
>
> >
> > Excellent.  Which header digest positioning method will we choose?
> >
> > 1. Single header digest, after BHS and AHS
> >
> > 2. Two header digests, one for BHS, one for AHS
> >
> > 3. Single header digest for BHS; AHS is added to data digest
> >
> > Option 3 will not work well with iSCSI proxies and gateways
> > that may change header information, but keep the data end-to-end.
> >
> > To me, that leaves option 1 and 2.  So, which is easier, having
> > a single header digest in a variable location, or having the
> > potential for two header digests; one in a fixed location, and
> > an optional one in a variable location?
> >
> > I don't believe that we will see AHS on most iSCSI PDUs, so is
> > it OK to have a "slow path" for these?
> >
> > --
> > Mark
> >
> > julian_satran@il.ibm.com wrote:
> > >
> > > Dear colleagues,
> > >
> > > It look like Format-2 is selected by popular vote.
> > >
> > > Julo
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054