RE: iSCSI - change proposal LUN field definition on every PDU

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

I agree with all the folks who oppose this change.
The approach should be to question usefulness of each
and every field, not add more.

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Robert Snively
> Sent: Tuesday, November 13, 2001 8:23 AM
> To: 'Julian Satran'; ips@ece.cmu.edu
> Subject: RE: iSCSI - change proposal LUN field definition on every PDU
> 
> 
> Folks,
> 
> I have followed this thread up to the current time, and I have
> to agree with the people who think that this is probably
> not necessary and has undesirable consequences.
> 
> One reason that it is not necessary is that as we write, the
> SCSI MIB people are defining the properties and statistic
> gathering capabilities of SCSI logical units.  These capabilities
> are clearly going to require logical units to capture additional
> performance information using SCSI logging commands (which
> already capture a huge amount of error information).
> 
> A second reason that it is not necessary is that the command
> and data counts can be extracted from the command PDU's
> CDB field, which is labeled with a logical unit.  Given that
> the command completes correctly, the counting is already done
> and the count is in the command PDU.
> 
> A third reason that it is not necessary is that any decent
> instrumentation on the line has to already be capable of sorting
> through the TCP/IP mapping, the security mappings, and the
> basic PDU identification.  All the monitors that we have today
> in the SCSI environment apply a little simple postprocessing to
> the data they have captured and presto, they not only identify
> PDU's related to particular logical units, but to particular
> commands, and they have interpreted the commands and verified
> that the responses are appropriate to the commands.
> 
> If the instrumentation is inline with the receiving code,
> it is by definition aware of the states and identifications
> already available to it and does not need this additional information.
> 
> As for undesirable consequences:
> 
> Paul Koning's objection to the additional functional steps
> required to provide the LUN is a valid concern.
> 
> Mallikarjun Chadalapaka's concern about the requirement for
> additional consistency checking (and a whole new class of
> non-SCSI protocol error checking) is also a valid issue.
> 
> Let's talk to your colleague and explain to him/her how there
> are better ways to achieve his/her goals.
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> 
> 
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Monday, November 12, 2001 4:31 AM
> > To: ips@ece.cmu.edu
> > Subject: iSCSI - change proposal LUN field definition on every PDU
> > Importance: High
> > 
> > 
> > Dear colleagues,
> > 
> > A colleague interested in instrumentation approached me with 
> > a question 
> > about stateless logging of specific LU activity.
> > With the current iSCSI PDU formats this is not possible.
> > We have consistently avoided having fields that are redundant 
> > and will 
> > need consistency checking.
> > However I think we should consider including the LU field in 
> > all PDUs that 
> > are referencing a specific LU to simplify this type of 
> > instrumentation (as 
> > we did with the direction bit in the op-code).
> > 
> > As I am already in "count-down" mode for version 09 I would 
> > appreciate 
> > your comments ASAP.
> > 
> > Julo
> > 
>