Re: iscsi: 08 Comment, framing

["Julian Satran" <Julian_Satran@il.ibm.com>]

Dave,

This was the consensus of the framing team - not of the IPS list.
It is inappropriate for us to replace a thing that we have and is agreed to something that
that is not here yet.  

As I stated if you want to do it independent of the ULP progress you have to reopen the issue on this list.

Regards,
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