SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    


Home

Last updated: Tue Sep 04 01:05:12 2001
6315 messages in chronological order