headers
Julian Satran | 2 Feb 2004 15:18
Picon
Favicon

Re: Fw: iSCSI: abort task set

I might be a bit late and you might have closed on all this but here is 
what I think although I have to admit that I don't recall the debate in 
its entirety

ips-admin <at> ietf.org wrote on 30/01/2004 21:33:55:

> On Fri, 30 Jan 2004, Mallikarjun C. wrote:
> 
> > Eddy,
> >
> > Sorry for not responding sooner, I was checking my old
> > notes (but couldn't find relevant ones so far).
> >
> > The authors' advice on this is the following -
> >
> > The wait for affected tasks can be done (need to
> > pick a point in time as the reference for determining
> > the "affected" tasks, regardless of the # of sessions).
> > However, an alternative that's also legal is given below.
> >
> > Bullet (b) should have been:
> >
> > b) Waits for all target transfer tags to be responded to
> >     and for all affected tasks in the task set to be
> >     received (alternatively, the target may plug the CmdSN
> >     gaps for unreceived commands just as if an abort request
> >     is received for each individual affected task, refer
> >     section 6.9 "SCSI timeouts")
> 
> Abort Task Set has to plug the whole CmdSN window on each session?? That
(Continue reading)

Permalink | Reply | 0 comments |
headers
pat_thaler | 2 Feb 2004 18:51
Favicon

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

If we really believe that the change would be overly painful for current and in development
implementations, I would prefer a change to make R2TSN and DataSN independent for bidirectional
commands. The logic:

Bidirectional commands already need extra context so carrying an extra SN variable is a very small burden
to them.

It is poor form to have one variable that is sitting under two names. It creates confusion and is likely to
cause interoperability problems in the future. 

Therefore, it is worth the burden of carrying an extra value in bidirectional command context to forstall
interoperability problems.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran <at> il.ibm.com]
Sent: Friday, January 30, 2004 3:57 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: cbm <at> rose.hp.com; ips <at> ietf.org; ips-admin <at> ietf.org;
wrstuden <at> wasabisystems.com
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
commands

Will fix the example (thanks Pat and perhaps add the text you suggested). 
For pratical purposes it should be noted that the only SCSI device that 
plans to use bidirectional data transfers to-date has different phases for 
input and output so that block are no mixed.
(Continue reading)

Permalink | Reply | 1 comment |
headers
pat_thaler | 2 Feb 2004 19:01
Favicon

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

I don't think "(read)" should be in there. We don't usually put read after Data-In. Also, I would rather have
it a separate sentence. 

For read commands, the number of Data-In PDUs the target has sent for the command. For bidirectional
commands, the number of Data-In PDUs and R2T PDUs the target has sent for the command.

or 

For bidirectional commands, the number of Data-In PDUs and R2T PDUs the target has sent for the command. For
all other commands, the number of Data-In PDUs the target has sent for the command.

The more I think about it, the more I lean toward leaving 10.4.8 as it is and changing 3.2.2 to disentangle
DataSN from R2TSN. Is it really worth these gymnastics to reduce bidirectional command context by one variable?

-----Original Message-----
From: Ramesh Mangamuri [mailto:rmangamuri <at> istor.com]
Sent: Saturday, January 31, 2004 1:27 PM
To: Ken Sandars; Julian Satran; Mallikarjun C.
Cc: THALER,PAT (A-Roseville,ex1); ips <at> ietf.org
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
commands

Hello Ken/Julian:

I have another proposal here for section 10.4.8:

Suggestion ---------------------------

10.4.8  ExpDataSN
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ramesh Mangamuri | 2 Feb 2004 19:06
Favicon

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

To be honest I really don't know about the resources we would be saving
by combining R2TSN and DataSN into one variable in the of bidirectional
. But from logical standpoint, Pat's suggestion makes perfect sense to
me.

More later ...,
Rams

-----Original Message-----
From: pat_thaler <at> agilent.com [mailto:pat_thaler <at> agilent.com] 
Sent: Monday, February 02, 2004 9:52 AM
To: Julian_Satran <at> il.ibm.com
Cc: cbm <at> rose.hp.com; ips <at> ietf.org; ips-admin <at> ietf.org;
wrstuden <at> wasabisystems.com
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
commands

If we really believe that the change would be overly painful for current
and in development implementations, I would prefer a change to make
R2TSN and DataSN independent for bidirectional commands. The logic:

Bidirectional commands already need extra context so carrying an extra
SN variable is a very small burden to them.

It is poor form to have one variable that is sitting under two names. It
creates confusion and is likely to cause interoperability problems in
the future. 

Therefore, it is worth the burden of carrying an extra value in
bidirectional command context to forstall interoperability problems.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Sandars | 2 Feb 2004 19:12

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

Hi Pat,

> -----Original Message-----
> From: pat_thaler <at> agilent.com [mailto:pat_thaler <at> agilent.com] 
> Sent: 02 February 2004 18:02
> To: rmangamuri <at> istor.com; ksandars <at> elipsan.com; 
> Julian_Satran <at> il.ibm.com; cbm <at> rose.hp.com
> Cc: ips <at> ietf.org
> Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for 
> bidirectional commands
> 
> 
> I don't think "(read)" should be in there. We don't usually 
> put read after Data-In. Also, I would rather have it a 
> separate sentence. 
> 
> For read commands, the number of Data-In PDUs the target has 
> sent for the command. For bidirectional commands, the number 
> of Data-In PDUs and R2T PDUs the target has sent for the command.
> 
> or 
> 
> For bidirectional commands, the number of Data-In PDUs and 
> R2T PDUs the target has sent for the command. For all other 
> commands, the number of Data-In PDUs the target has sent for 
> the command.
> 
> The more I think about it, the more I lean toward leaving 
> 10.4.8 as it is and changing 3.2.2 to disentangle DataSN from 
> R2TSN. Is it really worth these gymnastics to reduce
(Continue reading)

Permalink | Reply | 0 comments |
headers
pat_thaler | 2 Feb 2004 19:43
Favicon

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

Ken,

Good point. I had missed that the DataIn and R2T are one SNACK type. Changing that would affect current
implementations even if they don't do bidirectional. While I don't like the one variable, two names
thing, changing it isn't worth that turmoil.

Given that, I think we need to keep target DataSN and R2TSN as one sequence for bidirectional.

There is another way to clean things up which is editorially significantly more radical but which should be
less tramatic for implementations.

DataSN (for DataIn PDUs) and R2TSN are really two names for one counter variable - 
Write only commands use the counter for R2T PDUs and call it R2TSN
Read only commands use the counter for DataIn PDUs and call it DataInSN
Bidirectional commands use the counter for both kinds of PDUs and both names are applied to it depending on
the PDU type.

The obvious way to clean this up is to give the SNs generated for DataIn and R2T PDUs a single name such as:
DataR2TSN
DRSN
or even just the current DataSN 
The justification for DataSN is that both R2T and DataIn are concerned with the movement of data. (See also
iSER which classifies both PDUs as iSCSI data type PDUs.) Keeping this name  would minimize the amount of
editorial change.

I know this editorial change would have to be carefully made (there are 35 instances of R2TSN in the draft
most of which would be pretty straight forward to convert), but in the long run that is probably
significantly less effort than we will expend explaining to people that DataSN and R2TSN form one sequence.

Regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
wrstuden | 2 Feb 2004 21:05

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

On Mon, 2 Feb 2004, Ramesh Mangamuri wrote:

> To be honest I really don't know about the resources we would be saving
> by combining R2TSN and DataSN into one variable in the of bidirectional
> . But from logical standpoint, Pat's suggestion makes perfect sense to
> me.

I think the reason they are the same variable is that they (R2T numbers
and DataSN) are in the same number space, due to how SNACK Requests work.
To request a given DataSN or a given R2T be retransmitted, the initiator
sends a SNACK Request of Type 0. That's a Type 0 for _either_ a R2T or
DataSN retransmit. So for the target to keep things clear, it has to use
the same number space for both.

I think separating the number spaces would be ok, but it means changing
SNACK requests so that BiDi commands can tell what's being asked for.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Permalink | Reply | 0 comments |
headers
Ramesh Mangamuri | 2 Feb 2004 21:41
Favicon

RE: iSCSI: Correct value for ExpDataSN for bidirectionalcommands

From the discussion so far, I am interested to know Julian's plans on
about the below approaches in the case of a bidirectional commands. 

Implementation 1:
=================
Keep the same variable for both <R2TSNs & DataInSNs> so that there is no
need to introduce another new SNACK type for R2TSN.

Or,

Implementation 2:
=================
Use different variables for R2TSNs and DataInSN and introduce new SNACK
type for R2TSNs.

More later...,
Rams

-----Original Message-----
From: wrstuden <at> wasabisystems.com [mailto:wrstuden <at> wasabisystems.com] 
Sent: Monday, February 02, 2004 12:06 PM
To: Ramesh Mangamuri
Cc: pat_thaler <at> agilent.com; Julian_Satran <at> il.ibm.com; cbm <at> rose.hp.com;
ips <at> ietf.org; ips-admin <at> ietf.org
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for
bidirectionalcommands

On Mon, 2 Feb 2004, Ramesh Mangamuri wrote:

> To be honest I really don't know about the resources we would be
(Continue reading)

Permalink | Reply | 2 comments |
headers
wrstuden | 2 Feb 2004 21:45

RE: iSCSI: Correct value for ExpDataSN for bidirectional commands

On Mon, 2 Feb 2004 pat_thaler <at> agilent.com wrote:

> Ken,
>

> Good point. I had missed that the DataIn and R2T are one SNACK type.
> Changing that would affect current implementations even if they don't do
> bidirectional. While I don't like the one variable, two names thing,
> changing it isn't worth that turmoil.
>
> Given that, I think we need to keep target DataSN and R2TSN as one
> sequence for bidirectional.

Not necessarily. We could add a new SNACK type for BiDi commands, say for
R2Ts for a BiDi. If we make the new type used only for BiDi commands, we
do not impact implementations that do not handle BiDi commands (for which
there is no such ambiguity).

This would, though, impact existing implementations that do support BiDi
commands. I'm not sure if we want to be that tramatic.

> There is another way to clean things up which is editorially
> significantly more radical but which should be less tramatic for
> implementations.

This option also would work.

> DataSN (for DataIn PDUs) and R2TSN are really two names for one counter
> variable -
> Write only commands use the counter for R2T PDUs and call it R2TSN
(Continue reading)

Permalink | Reply | 0 comments |
headers
wrstuden | 2 Feb 2004 22:08

RE: iSCSI: Correct value for ExpDataSN for bidirectionalcommands

On Mon, 2 Feb 2004, Ramesh Mangamuri wrote:

> >From the discussion so far, I am interested to know Julian's plans on
> about the below approaches in the case of a bidirectional commands.
>
> Implementation 1:
> =================
> Keep the same variable for both <R2TSNs & DataInSNs> so that there is no
> need to introduce another new SNACK type for R2TSN.
>
> Or,
>
> Implementation 2:
> =================
> Use different variables for R2TSNs and DataInSN and introduce new SNACK
> type for R2TSNs.

As noted in my other note, I'd like to propose we consider this new SNACK
type as applying only for BiDi commands. Otherwise we impact all existing
implementations.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
(Continue reading)

Permalink | Reply | 0 comments |

Gmane