RE: iscsi: 08 Comment, framing

[Black_David@emc.com]

Julian is correct.  In London the framing team consensus did not

translate into WG rough consensus.  Until it does, I think modifications

to the spec are not appropriate.  I suspect Framing is going to be on

the Salt Lake City agenda :-(.  --David

 

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, October 09, 2001 5:59 PM
To: ips@ece.cmu.edu
Subject: Re: iscsi: 08 Comment, framing

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