SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: new iSCSI draft - 02.txt



    
    
    Glen,
    
    I can hardly agree with your assumption that CRCs will have to be
    recomputed in the end-nodes as the only means for real protection.  Our
    design assumptions was that we don't want to mandate that - it is
    impractical at high speed.
    The end node will get data fit to its quality. If it has a bad DMA it will
    get bad data from local disk too!
    You are right about the major objection with regard to byte stuffing being
    copy - and I don't see how COBS is better than other schemes.  An iSCSI
    hardware adapter could do it efficiently while using a plain (even
    accelerated) TCP adapter will make it very inefficient.
    The marker scheme suggested does not require any TCP internal knowledge -
    sequence numbers are not used and markers are relative.  Yes you have to
    count every byte but you can do it independent of the TCP count.
    Buffer copies become either rare or are eliminated if your DMA mechanism is
    sophisticated enough.
    
    Julo
    
    Glen Turner <glen.turner@aarnet.edu.au> on 04/01/2001 07:01:31
    
    Please respond to Glen Turner <glen.turner@aarnet.edu.au>
    
    To:   sukha_ghosh@ivivity.com
    cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
    Subject:  Re: new iSCSI draft - 02.txt
    
    
    
    
    Sukha Ghosh wrote:
    >
    > Also I like the idea of fixed length PDU better than a new TCP
    > option indicating message boundary.
    
    A fixed length PDU doesn't solve the fundamental problem.  In a
    stream of bytes you still can't tell where the PDU starts
    unless you assume PDUs pack nicely into packets and frames
    and the iSCSI process has special knowledge of the data
    stream (such as TCP options).
    
    Without altering TCP (which this IESG is opposed to) the
    options are an adaption layer containing either a flag
    byte and escapes (as in SLIP) or a counting scheme (such
    as computing a CRC which becomes 0 when the PDU is complete).
    
    Objections that byte stuffing to mark the PDU boundary
    discourages host-based implementations are somewhat difficult
    to understand.  Firstly, the feature can, and should, be
    negotiatable in both directions.  A host processor implementation
    can chose not to negotiate the reception of packets with
    byte stuffing, at the cost of incurring TCP head-on-line
    blocking due to late packets.
    
    Secondly, the decision to include a iSCSI-level checksum (to avoid
    surprisingly common corruption by DMA chips and the like, see the
    SIGCOMM2000 Proceedings) means that the data has to be scanned
    by the CPU anyway.  Any other implementation of the iSCSI-level
    checksum gives no protection.
    
    The real objection is that removing the byte-stuffing requires
    a buffer copy, not just a scan.  The second objection is that
    the overhead from SLIP-style byte stuffing has a pathological case.
    
    The counting schemes do not need a buffer copy (as you can arbitrarily
    drop, say, the last 8 octets that were required to drive the CRC
    to 0 and retreive the original data).  However, these schemes are
    unavoidably computationally expensive, perhaps more so than a buffer
    copy (although RISC processors do about 100 instructions per
    memory cycle, so this assumption needs testing).
    
    A modification of "Consistent Overhead Byte Stuffing" (IEEE/ACM
    Transactions on Networking, Vol 7, No 2, 1999) seems to hold
    a neat solution to the pathological case of SLIP.  It offers a
    neat way of identifying packet boundaries that has a bound on
    the growth in the packet size.  However, like SLIP it also
    requires that a buffer copy occur to undo the detection of the
    packet boundary.
    
    If the WG find it best to deal with TCP as a stream of octets
    with zero knowledge of the underlying packet boundaries, options
    and sequence numbers then an adaption layer for TCP with a
    COBS-based scheme to identify packet boundaries seems to have the
    most promise.
    
    Regards,
    Glen
    
    --
     Glen Turner                                 Network Engineer
     (08) 8303 3936      Australian Academic and Research Network
     glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
    --
     The revolution will not be televised, it will be digitised
    
    
    
    


Home

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