RE: iSCSI draft-07 Padding

["Robert Griswold" <rgriswold@Crossroads.com>]

I am generally in agreement with those discussing the 'bad iSCSI'
behavior on this thread, but am reluctant to spend too many words
defining implementation guidelines in the body of the specification.  By
Julian using 'should' we allow the bad to take place, but do not lock
out the unknown legitimate use of such a transfer.  I would like to
think that if the I_T nexus can operate on a set of parameters governing
communication, and within the bounds of the transport and protocol, that
the communication would be allowed to take place.  A simple annex or
white paper would be good to explain why not to do something bad.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Julian Satran [mailto:Julian_Satran@il.ibm.com] 
Sent:	Tuesday, July 24, 2001 11:00 AM
To:	ips@ece.cmu.edu
Subject:	RE: iSCSI draft-07 Padding


I'll add to 2.7.6:

   The Data Segments of Data-in and Data-out PDUs SHOULD be filled to
   integer number of 4 byte words (real payload) unless the F bit is set
to
   1.

Julo

Michael Schoberg <michael_schoberg@cnt.com> on 24-07-2001 18:13:14

Please respond to Michael Schoberg <michael_schoberg@cnt.com>

To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI draft-07 Padding




Yes, at the very least the spec should not allow padding on intermediate
ReadData/WriteData bursts.  I can't think of a reason why one would want
to
use odd length intermediate bursts, so hopefully it's safe to restrict
it.
Padding the last burst still seems reasonable for easy CRC calculation.

Setting a fixed size is optional.  A minimum would avoid memory
fragmentation when working with memory descriptors.

: -----Original Message-----
: From: Robert Snively [mailto:rsnively@Brocade.COM]
: Sent: Tuesday, July 24, 2001 8:34 AM
: To: ips@ece.cmu.edu
: Subject: RE: iSCSI draft-07 Padding
:
:
: Fibre Channel's approach to this problem is to prohibit padding
: for all transfers except the transfer that moves the last bytes
: in the last (or highest pointer value) burst of data.  Intermediate
: bursts are required to end on 4-byte boundaries, regardless of
: tranfer order as allowed by EMDP.
:
: Bob
:
: ----- Original Message -----
: From: "Michael Schoberg" <michael_schoberg@cnt.com>
: To: <ips@ece.cmu.edu>
: Sent: Friday, July 20, 2001 4:27 PM
: Subject: iSCSI draft-07 Padding
:
:
: > I couldn't find anything in the latest iSCSI spec
: (draft-07) that prevents
: > someone from issuing multiple padded PDU's for iSCSI Data
: In/Out segments.
: > I guess I'm worried that someone could issue padded
: odd-length write/read
: > data when it wasn't necessary.  Example: When moving a 512 byte disk
: sector
: > an initiator/target could legally issue 512 1-byte DataSegmentLength
: > messages (each padded up to a 32-bit boundary).  This isn't
: the sort of
: data
: > stream one would expect, but it's allowed in the draft.
: >
: > This also leads into whether fixed or minimum length data
: segments (for
: all
: > but the last) would be nice to include as part of the spec.
:  It may result
: > in a simpler software/hardware design.
: >
: