SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Framing Steps



    A few more clarifications:
    
    (1) If the data-dependent memory allocator below TCP gets confused,
    	that's its problem, and iSCSI's problem, not TCP's.  As long
    	as the inbound data is presented to TCP in the order it came
    	off the wire, TCP's processing behavior is unchanged.  If the
    	data is delivered by TCP in locations other than those iSCSI
    	was expecting, it can be copied to the right locations with
    	suitable safeguards.
    
    (2) FIM processing makes no changes to packet contents, period.
    	I have no idea where Doug got the impression "it is not the packet
    	location that is being changed, but the content of the packet
    	or it would be of little value".  That is simply not true -
    	the FIM markers can't be removed below TCP because they were
    	sent in the TCP bytestream and have to be presented to TCP.	
    	The contents of each packet may not be contiguous in
    	memory, but that has been common in TCP implementations
    	from the beginning (e.g., see the original BSD mbuf code).
    
    (3) Zero-copy TCP is irrelevant to this discussion.  In an integrated
    	TCP/FIM/iSCSI implementation, there would be no address boundaries
    	between any of the components and hence no need to avoid the copy
    	across address boundaries that is the motivation for zero-copy TCP.
    	Zero copy TCP schemes cannot achieve "appropriate packet placement"
    	for iSCSI by themselves because they're not capable of ensuring that
    	a 4k SCSI data payload lands in 4k of contiguous memory aligned to
    	a 4k boundary, and hence will cause copies to be made.
    
    Beyond this, Doug continues to claim that there are new security
    issues in FIM but has failed to describe any significant new risks,
    aside from a general concern that implementation work could introduce
    security bugs - that is the case for most IETF protocols, and is not
    a reason to stop working on protocols.
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------
    


Home

Last updated: Tue Jan 29 17:17:59 2002
8551 messages in chronological order