iscsi: 08 Comment, framing

[Dave Sheehy <dbs@acropora.rose.agilent.com>]

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