RE: iSCSI: Use of the A bit

["Amir Shalit" <amir@astutenetworks.com>]

Successful delivery of last burst is implicitly acknowledged by 
ExpStatSN therefore we may want to discourage setting
the A bit on last burst.

Amir

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


  >  -----Original Message-----
  >  From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
  >  Sent: Saturday, March 16, 2002 4:15 PM
  >  To: Rod Harrison; Mallikarjun C.; ips@ece.cmu.edu
  >  Cc: Julian_Satran@il.ibm.com
  >  Subject: RE: iSCSI: Use of the A bit
  >
  >
  >  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).
  >

Since the SCSI status ends the task and therefore the lifetime of the
initiator task tag the problem I mentioned was specifically caused by
allowing the A bit to be set with the F bit when there is piggyback
status. But you are right, the problem was actually always there since
if the SCSI transfer length was an exact multiple of MaxBurstSize the
A and F bits would be valid together. In fact I now see there are
several other ways this combination would be valid.

Anyway, removing the requirement for the initiator to send the ITT in
the data SNACK solves the problem.

  >  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
  >  >
  >  >
  >  >
  >  >