Subject: Re: frame formats

From: [email-masked] (Sandeep Joshi)
Date: Sun, 1 Apr 2001 14:54:21 -0400 (EDT)

Well, perhaps I was just not quick enough.  I thought I would let this
settle out a bit before I added my two cents.
 
If you all remember, some folks on this reflector gave Julian a hard time
because you would have to use a length field that you were not sure was OK,
if you had a digest error and wanted to jump forward to the next, etc. etc.
etc.  I am sure you all remember this.  OK, now that Julian proposed a
parity way to ensure that you could trust the length field, some of the
parties, have now, I think, voted for format #2.  Unless you want now to
reconsider your vote, we should stop giving Julian a hard time about the
length not being ensured correct in the presents of a Digest Error.
 
Either drop the session, or use the length to see if you can get somewhere,
search for the next marker etc.  All the stuff you said you did not like
before.  OK, now you have format 2, but lets not go over that old ground
now that you have decided against the parity.

---

From: [email-masked] (Sandeep Joshi)
Date: Sun, 1 Apr 2001 14:54:26 -0400 (EDT)

---

From: [email-masked]
Date: Sun, 1 Apr 2001 21:54:12 +0200

Sure - the "deep processing" required was to look at a bit.
And no we went  over the lengths. There is no need for a parity check for a
one byte field.
The Header digest plus an ocasional timeout will take care of checks.

Julo

[email-masked] (Sandeep Joshi) on 01/04/2001 21:19:37

Please respond to [email-masked] (Sandeep Joshi)

To:   [email-masked]
cc:
Subject:  Re: frame formats

To steal & reintroduce that idea, is it possible to borrow
a bit or two from the DataLen field to parity-check the AHSLen ?

Adding an entire BHS header digest, when all you need to verify
is that AHS-length field, seemed overkill.   On the other hand,
Format-1's chief disadvantage was that it required some processing
(QL) to locate either/both the length fields.   This has complicated
the choice between all these 3 formats resulting in the current vote.

Borrowing the bits for AHS parity from DataLen solves this problem.

DataLen will now be max 8M/4M but then we dont wish to have large
iSCSI PDUs in any case.  Btw, I assume Next DataLen AHS does not
exist in the new setup ?

-Sandeep

> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: [email-masked]
>
>
> Julian Satran/Haifa/IBM@[email-masked] on 03/30/2001 08:51:50 AM
>
> Sent by:  [email-masked]
>
>
> To:   [email-masked]
> cc:
> Subject:  frame formats
>
>
>
>
>
> Dear colleagues,
>
> It look like Format-2 is selected by popular vote.
>
> Julo
>
>
>

---

From: Mark Bakke <[email-masked]>
Date: Mon, 02 Apr 2001 08:42:40 -0500

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
> [email-masked]
> 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
> >
> > [email-masked] wrote:
> > >
> > > Dear colleagues,
> > >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > [email-masked]
> > 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: [email-masked]
Date: Mon, 2 Apr 2001 15:52:35 -0400

Let me jump in here and do this officially (or
is that officiously :-)?) -- Format 2 is the
"rough consensus" of the working group.  Those
who disagree should post to the list.

The following related issues are still open:
- what pieces of the header are covered in which
	digest(s)
- if a length field covered by a digest has to
	be used to locate that digest, whether
	and how to protect that length.
We need to reach consensus on these in the next
few days.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, March 30, 2001 11:52 AM
> To:	[email-masked]
> Subject:	frame formats
> 
> 
> 
> Dear colleagues,
>

---

From: [email-masked]
Date: Tue, 3 Apr 2001 03:10:14 +0200

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 <[email-masked]> on 02/04/2001 15:42:40

Please respond to Mark Bakke <[email-masked]>

To:   "Robert D. Russell" <[email-masked]>
cc:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
Subject:  Re: frame formats

Bob-

--
Mark

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054