SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iscsi: 08 Comment, framing



    Since the following is the consensus of the framing team:
    
    > iSCSI, with minor modifications since the presentation at the IETF:
    > 
    > 
    > 	The Sender:
    > 		- MUST support no framing
    > 		- MUST support at least one framing solution
    > 		- MUST use the framing specified by the receiver, 
    > 			if it supports that framing mode
    
    and ...
    
    > 
    > First, a quick summary of the issues:
    > 	- Deploying iSCSI sender can be done:
    > 		- on top of an unmodified TCP stack with:
    > 			o No framing
    > 			o Marker based framing 
    > 		- on top of a modified TCP stack can implement
    > 			PDU-alignment.
    > 	- The receiver trade-offs are:
    > 		o No framing - large receive reassembly buffer 
    > 			(higher cost solution)
    > 		o Marker framing - receive reassembly buffer is reduced 
    > 			to an eddy buffer, but requires modifications to
    > 
    > 			TCP receive stack (medium cost solution)
    > 		o PDU-alignment - receive reassembly buffer can be
    > reduced 
    > 			even further, but requires modifications to TCP 
    > 			receive stack (lowest cost solution and enables 
    > 			eventual deployment of a viable chunking protocol).
    > 	- The cost of implementing markers on unmodified TCP stacks
    > 		o sender cost is acceptable, assuming a gather list is
    > 			reasonably implemented.
    > 		o receiver cost is unacceptable
    
    > Initial implementations for initiator appear to be in two camps:
    > 	- Unmodified TCP software stacks
    > 	- Embedded TCP offload in the NIC (essentially TCP 
    > 		is hidden from the host SCSI stack)
    > 
    > Initial implementations for the target appear to be in two camps:
    > 	- Optimized NICs which will support framing - probably both 
    > 		framing modes. Because both modes
    > 		require modifications to the receive TCP stack and 
    > 		PDU-alignment is viewed as straightforward, it is 
    > 		assumed that most implementations will implement 
    > 		both framing solutions to allow them to transfer 
    > 		data optimally with either unmodified send TCP stacks 
    > 		or PDU-alignment send TCP stacks.
    > 	- Unmodified TCP software stacks
    > 
    > It is primarily a receiver cost issue that motivates the framing
    > discussion. The primary sender issue is what, if any, optimizations can
    > be done for unmodified TCP send stacks? Note however, that the proposed
    > iSCSI requirements are not target or initiator oriented - they are
    > sender and receiver oriented. The receiver cost issue applies to either
    > a target or initiator - and they each have very different cost
    > trade-offs. 
    > 
    > Thus the best solution is to allow the receive side to control their
    > destiny - and require the sender to obey the receiver (within limits).
    > If this approach were taken, the sender would have to implement all
    > three framing options. Unfortunately, a highly desirable design goal is
    > to allow the sender (either the target or the initiator) to run on an
    > unmodified TCP stack. Thus the compromise in terms of sender
    > functionality. 
    
    The iSCSI 08 draft Appendix C MUST be amended,
    
    from,
    
    "The use of markers is negotiable. The initiator and target MAY
    indicate their readiness to receive and/or send markers during login
    separately for each connection. The default is NO. In certain
    environments a sender not willing to supply markers to a receiver
    willing to accept markers MAY suffer from a considerable performance
    degradation."
    
    to:
    
    "The use of markers is negotiable. The initiator and target MUST
    indicate their readiness to receive and/or send markers during login
    separately for each connection. The default is NO. In certain
    environments a sender not willing to supply markers to a receiver
    willing to accept markers MAY suffer from a considerable performance
    degradation."
    
    and in the next paragraph:
    
    "If a receiver indicates that it desires a marker, the
    sender SHOULD agree (during negotiation) and provide the marker at
    the desired interval."
    
    MUST be changed to:
    
    "If a receiver indicates that it desires a marker, the
    sender MUST agree (during negotiation) and provide the marker at
    the desired interval."
    
    Dave Sheehy
    
    


Home

Last updated: Tue Dec 04 00:17:39 2001
7988 messages in chronological order