|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: 08 Comment, framingJulo, > We went through this several times. > Once the Framing becomes an RFC (informational) we will adjust the > appendix. I am not at all confident that framing will become an RFC prior to iSCSI being approved. I'd like to get the iSCSI spec changed now to cover that possibility. > Untill then this appendix represents the WG consensus and there no reason > to change that. So, you're saying that the framing team consensus is in conflict with the WG consensus? Dave > > Julo > > > > > > Dave Sheehy <dbs@acropora.rose.agilent.com> > Sent by: owner-ips@ece.cmu.edu > 09-10-01 08:54 > Please respond to Dave Sheehy > > > To: ips@ece.cmu.edu (IETF IP SAN Reflector) > cc: > Subject: 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 > > > > > --=_alternative 004F567E42256AE0_= > Content-Type: text/html; charset="us-ascii" > > > <br><font size=2 face="sans-serif">Dave,</font> > <br> > <br><font size=2 face="sans-serif">We went through this several times.</font> > <br><font size=2 face="sans-serif">Once the Framing becomes an RFC (informational) we will adjust the appendix.</font> > <br><font size=2 face="sans-serif">Untill then this appendix represents the WG consensus and there no reason to change that.</font> > <br> > <br><font size=2 face="sans-serif">Julo</font> > <br> > <br> > <br> > <br> > <table width=100%> > <tr valign=top> > <td> > <td><font size=1 face="sans-serif"><b>Dave Sheehy <dbs@acropora.rose.agilent.com></b></font> > <br><font size=1 face="sans-serif">Sent by: owner-ips@ece.cmu.edu</font> > <p><font size=1 face="sans-serif">09-10-01 08:54</font> > <br><font size=1 face="sans-serif">Please respond to Dave Sheehy</font> > <br> > <td><font size=1 face="Arial"> </font> > <br><font size=1 face="sans-serif"> To: ips@ece.cmu.edu (IETF IP SAN Reflector)</font> > <br><font size=1 face="sans-serif"> cc: </font> > <br><font size=1 face="sans-serif"> Subject: iscsi: 08 Comment, framing</font> > <br> > <br><font size=1 face="Arial"> </font></table> > <br> > <br><font size=2 face="Courier New">Since the following is the consensus of the framing team:<br> > <br> > > iSCSI, with minor modifications since the presentation at the IETF:<br> > > <br> > > <br> > > The Sender:<br> > > - MUST support no framing<br> > > - MUST support at least one framing solution<br> > > - MUST use the framing specified by the receiver, <br> > > if it supports that framing mode<br> > <br> > and ...<br> > <br> > > <br> > > First, a quick summary of the issues:<br> > > - Deploying iSCSI sender can be done:<br> > > - on top of an unmodified TCP stack with:<br> > > o No framing<br> > > o Marker based framing <br> > > - on top of a modified TCP stack can implement<br> > > PDU-alignment.<br> > > - The receiver trade-offs are:<br> > > o No framing - large receive reassembly buffer <br> > > (higher cost solution)<br> > > o Marker framing - receive reassembly buffer is reduced <br> > > to an eddy buffer, but requires modifications to<br> > > <br> > > TCP receive stack (medium cost solution)<br> > > o PDU-alignment - receive reassembly buffer can be<br> > > reduced <br> > > even further, but requires modifications to TCP <br> > > receive stack (lowest cost solution and enables <br> > > eventual deployment of a viable chunking protocol).<br> > > - The cost of implementing markers on unmodified TCP stacks<br> > > o sender cost is acceptable, assuming a gather list is<br> > > reasonably implemented.<br> > > o receiver cost is unacceptable<br> > <br> > > Initial implementations for initiator appear to be in two camps:<br> > > - Unmodified TCP software stacks<br> > > - Embedded TCP offload in the NIC (essentially TCP <br> > > is hidden from the host SCSI stack)<br> > > <br> > > Initial implementations for the target appear to be in two camps:<br> > > - Optimized NICs which will support framing - probably both <br> > > framing modes. Because both modes<br> > > require modifications to the receive TCP stack and <br> > > PDU-alignment is viewed as straightforward, it is <br> > > assumed that most implementations will implement <br> > > both framing solutions to allow them to transfer <br> > > data optimally with either unmodified send TCP stacks <br> > > or PDU-alignment send TCP stacks.<br> > > - Unmodified TCP software stacks<br> > > <br> > > It is primarily a receiver cost issue that motivates the framing<br> > > discussion. The primary sender issue is what, if any, optimizations can<br> > > be done for unmodified TCP send stacks? Note however, that the proposed<br> > > iSCSI requirements are not target or initiator oriented - they are<br> > > sender and receiver oriented. The receiver cost issue applies to either<br> > > a target or initiator - and they each have very different cost<br> > > trade-offs. <br> > > <br> > > Thus the best solution is to allow the receive side to control their<br> > > destiny - and require the sender to obey the receiver (within limits).<br> > > If this approach were taken, the sender would have to implement all<br> > > three framing options. Unfortunately, a highly desirable design goal is<br> > > to allow the sender (either the target or the initiator) to run on an<br> > > unmodified TCP stack. Thus the compromise in terms of sender<br> > > functionality. <br> > <br> > The iSCSI 08 draft Appendix C MUST be amended,<br> > <br> > from,<br> > <br> > "The use of markers is negotiable. The initiator and target MAY<br> > indicate their readiness to receive and/or send markers during login<br> > separately for each connection. The default is NO. In certain<br> > environments a sender not willing to supply markers to a receiver<br> > willing to accept markers MAY suffer from a considerable performance</font> > <br><font size=2 face="Courier New">degradation."<br> > <br> > to:<br> > <br> > "The use of markers is negotiable. The initiator and target MUST<br> > indicate their readiness to receive and/or send markers during login<br> > separately for each connection. The default is NO. In certain<br> > environments a sender not willing to supply markers to a receiver<br> > willing to accept markers MAY suffer from a considerable performance<br> > degradation."<br> > <br> > and in the next paragraph:<br> > <br> > "If a receiver indicates that it desires a marker, the<br> > sender SHOULD agree (during negotiation) and provide the marker at<br> > the desired interval."<br> > <br> > MUST be changed to:<br> > <br> > "If a receiver indicates that it desires a marker, the<br> > sender MUST agree (during negotiation) and provide the marker at<br> > the desired interval."<br> > <br> > Dave Sheehy<br> > <br> > </font> > <br> > <br> > --=_alternative 004F567E42256AE0_=-- >
Home Last updated: Tue Oct 09 18:17:24 2001 7167 messages in chronological order |