Re: Frame Formats

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Maybe this helps expand the solution space or maybe it doesnt..

See http://ips.pdl.cs.cmu.edu/mail/msg03098.html
for another scheme to keep header digests limited to BHS
with Julian's comments on it.

-sandeep

P.S. my vote is for format-2.

"Robert D. Russell" wrote:
> 
> 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.
> >