Re: Frame Formats

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Mike:

I agree with all your comments.

Earlier I had proposed that the BHS be covered by a digest that
was always after the 48th byte (i.e., at a fixed offset), and that
the AHS, if present, would be covered by a second digest of its own.
(not by the data digest, which would be after the end of the data).
By having 3 digests, 1 for the BHS, 1 for the AHS, 1 for the data,
every read is fixed length and the digest is at the end of each
of the reads.
However, there was opposition to having a second header digest
that just covered the AHS, so now there is only 1 header digest
which covers both the BHS and the AHS and therefore, as you pointed
out, it is at a position that is unknown when you start to read the
header.

Since you are a hardware implementer, let me ask the obvious question --
wouldn't it simplify everything to have a 2nd digest that covered just
the AHS?  The steps to receive a PDU would then be:
	1. Read the fixed length BHS with its own digest and check it.
	2. Extract the length of the AHS from the BHS
	   If this length is 0 there is no AHS.
	   If this length is positive, read that many bytes of AHS plus
	   the AHS digest and check it.
	3. Extract the length of the data from the BHS
	   If this length is 0 there is no data.
	   If this length is positive, read that many bytes of data plus
	   the data digest and check it.

From a software point of view this looks a lot simpler, since every
read is for a known number of bytes and every read ends with a digest.
However, I am not sure if it simplifies the hardware significantly.

Thanks,
Bob Russell


On Tue, 27 Mar 2001, Mike Thompson wrote:

> As an implementer of a hardware implementation of iSCSI/TCP, I would like to
> see format 2 from the slide set presented at IETF. The fixed location of the
> total data length and AHS length will make out of order data placement
> reasonable. With these two fields at the beginning of the PDU, hardware will
> immediately know how much data needs to be checked to verify the header
> digest and if the digest is valid, it can go on to process the next PDU,
> looking for data PDUs that can be processed. In previous formats, the
> hardware has to process too many fields to get to the digest.
> 
> Ideally, I would like to see a slight modification to this format where the
> header digest just covers the BHS. My understanding of the header digest is
> to allow for iSCSI routers to be able to modify a PDU header if it is acting
> as a proxy of some type. It seems that in this case the only thing that
> would be modified would be the BHS and not the AHS. With this change, I
> would envision the AHS be covered by the data digest. Again, this makes
> hardware processing easier, since the header that the digest covers
> is always a fixed length.
> 
> I also think that the 24 bit total data length is more than adequate for the
> total PDU length. In order to be able to efficiently/reliably process PDUs,
> the PDU length should be on the order of 8-64kBytes in length. PDUs of 4
> GBytes will require 4 Gbytes of reassembly memory in out of order cases.
> This is not reasonable.
>