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



    
    
    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.
    
    
    
    


Home

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