|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iscsi: 08 Comment, framingSince 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 |