RE: iSCSI: Use of the A bit

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

I don't know the original reason why TTT was added but from my perspective,
I never liked the search for ITT (or hash table). So I thought it was a good
idea.

Now that it has been added we should be able to get rid of the ITT and that
will solve the problem you have pointed out.

BTW, the problem you pointed out has nothing to do with the A bit problem
this thread was addressing. But, I'm really glad you pointed that out! (It
would have been yet another good reason for the TTT).

If there is debate on what Rod pointed out, we should probably start another
thread.

Eddy

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Saturday, March 16, 2002 11:00 AM
To: Eddy Quicksall; Mallikarjun C.; ips@ece.cmu.edu
Cc: Julian_Satran@il.ibm.com
Subject: RE: iSCSI: Use of the A bit



	I believe so, but I thought targets were intending to do some
indexing on the ITT? This has always seemed odd to me, but I thought
it was the case.

	- Rod

-----Original Message-----
From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
Sent: Saturday, March 16, 2002 3:57 PM
To: Rod Harrison; Mallikarjun C.; ips@ece.cmu.edu
Cc: Julian_Satran@il.ibm.com
Subject: RE: iSCSI: Use of the A bit


The ITT has no good use in a DataACK SNACK and is residual after we
added
the TTT. It should  probably be "reserved" for DataACK SNACK.

Would that take care of the problem?

Eddy

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Saturday, March 16, 2002 10:43 AM
To: Eddy Quicksall; Mallikarjun C.; ips@ece.cmu.edu
Cc: Julian_Satran@il.ibm.com
Subject: RE: iSCSI: Use of the A bit


Mallikarjun, Eddy and all,

	I think this might be dangerous.

	If the initiator receives a DATA-IN with F and A bits set and a GOOD
SCSI status it would be required to send a data SNACK PDU containing
an initiator task tag that has "expired" at the initiator.

	Initiator task tags are of course reused and there is no requirement
for the data SNACK to be sent immediately so it would be possible to
have a single ITT in the network referring to more than 1 task. I
think it is way too late in the game to start considering conservative
reuse rules for initiator task tags. That could be a potentially
invasive implementation change, especially when you consider that
reusing things is generally a good thing to do from a caching
perspective.

	Even if the data SNACK were required to be sent immediately there is
no guarantee that it would be received by the target before PDUs for
the task with the reused ITT when there is more than one connection
per session.

	Since the SCSI status ends the task and therefore releases the ITT
it
seems the only safe way to do this would be to make piggyback status
mutually exclusive with the A bit in a DATA-IN with the F bit set.
This would require the target to wait for the data SNACK before
issuing a SCSI status PDU. Clearly this is unpalatable for latency
reasons.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Eddy Quicksall
Sent: Saturday, March 16, 2002 12:41 PM
To: Mallikarjun C.; ips@ece.cmu.edu
Cc: Julian_Satran@il.ibm.com
Subject: RE: iSCSI: Use of the A bit


Yes, I agree.

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Friday, March 15, 2002 11:22 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: Use of the A bit


I agree with Julian.

Seems to me that targets should be allowed to ask for an ack
on the last Data-In PDU that concludes the entire transfer for the
task - a follow-up NOP-ping is needless.  I propose that we

replace:
  "it MAY set the A bit to 1 only once every MaxBurstSize bytes and
MUST NOT
do so more frequently than this."

with:
  "it MAY set the A bit to 1 only once every MaxBurstSize bytes or on
the
last
   Data-In PDU that concludes the entire requested transfer from the
target's
   perspective, and MUST NOT do so more frequently than this."
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "Paul Koning" <ni1d@arrl.net>
Cc: <Eddy_Quicksall@ivivity.com>; <ips@ece.cmu.edu>;
<owner-ips@ece.cmu.edu>; <rod.harrison@windriver.com>
Sent: Friday, March 15, 2002 11:50 AM
Subject: RE: iSCSI: Use of the A bit


> That could be so but it would be overkill. Status ACK can implicitly
> acknowledge the last transfer.
> And Yes the fact that the last transfer is not mentioned is an
oversight
> that I will correct.
> This does not mean that you HAVE TO raise the A flag or that you are
> ENCOURAGED to do so :-)
>
> Julo
>
>
>
>
> Paul Koning <ni1d@arrl.net>
> Sent by: owner-ips@ece.cmu.edu
> 15-03-02 16:09
> Please respond to Paul Koning
>
>
>         To:     Eddy_Quicksall@ivivity.com
>         cc:     rod.harrison@windriver.com, ips@ece.cmu.edu
>         Subject:        RE: iSCSI: Use of the A bit
>
>
>
> >>>>> "Eddy" == Eddy Quicksall <Eddy_Quicksall@ivivity.com> writes:
>
>  Eddy> I think we may need better explanation about why some folks
>  Eddy> don't want to do the "positive ack".
>
>  >> We got to this position, since so many folks did not want to
>  >> support the positive ack.
>
> Something doesn't compute here.
>
> I don't believe the discussion has anything to do with whether you
> support positive ACK or not.  If you're doing error recovery level 1
> or above, then you are required to support it, because the other end
> is allowed to say A=1 and you're required to answer that.
>
> If you don't want to support positive ACK, the solution is to
support
> only error recovery level 0.
>
> The issue under discussion is whether the rule "you are allowed to
set
> A=1 only once per MaxBurstSize" is correct.  At this point it's
clear
> to me that it is not, because you need to be able to set A=1 at the
> end of the transfer.  The current rule forbids that unless the total
> transfer size is >= MaxBurstSize.
>
> Kevin's proposal is a simple fix to this problem.
>
>                   paul
>
>
>
>