RE: Frame Formats

[Mike Thompson <mike.thompson@qlogic.com>]

Julian,

My major objection to Format 1 is that, as I interpret it, to determine the
total length of the PDU requires a more processing. In format 2, I only have
to interpret the first word (of course after verifying the digest). This
allows hardware to quickly scan for data PDUs to do data placement when in
an out of order condition. In format 1, the first word sometimes has the
data length and I have to interpret the DL bits and conditionally look in a
couple of locations to gather up the lengths to do the processing.

Mike

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Tuesday, March 27, 2001 11:12 PM
> To: ips@ece.cmu.edu
> Subject: Re: Frame Formats
> 
> 
> 
> 
> Mike,
> 
> I understand your concerns (as my hearth is still divided 
> between hardware
> and software -:))
> 
> Regarding digests including only BHS - it has crossed my mind 
> too several
> times.  The argument against it is that it is not future 
> proof - yes todays
> AHSs don't get modified by a proxy but how long will it hold?
> 
> In addition I have some trouble understanding what you find 
> objectionable
> on format 1 (remember I am neutral).  With both 1 and 2 you 
> know where the
> digest is and you don't have to use the data length until the 
> header is
> checked. With 1 you have the additional benefit of a parity 
> check for the
> length. In 99.99% of the cases
> you have only one length to care about and in format 1 this 
> is additionally
> protected with parity (makes resynch easier in case of a header digest
> failure).
> 
> 
> As for the size of the PDU - I am older and more cautious on this as I
> recall the days when 64k was more that you would ever need 
> and I built a
> large machine with an ALGOL compiler on 24k -:).  But I agree 
> that for now
> 24 bit should suffice and for later we can use an AHS if need arises.
> 
> Julo
> 
> Mike Thompson <mike.thompson@qlogic.com> on 27/03/2001 19:05:36
> 
> Please respond to Mike Thompson <mike.thompson@qlogic.com>
> 
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> cc:
> Subject:  Re: Frame Formats
> 
> 
> 
> 
> 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.
> 
> 
> 
>