ips-bounces@ietf.org wrote on 15/02/2005 16:17:46:

> I've run into a small problem while considering what it would take
to

> implement error recovery level 1 in an iSCSI target. The iSCSI specification

> states in 10.7.2: 

> 

> "The target should use the A bit moderately; it MAY only set
the A bit to 1

> once every MaxBurstLength bytes, or on the last Data-In PDU that concludes

> the entire requested read data transfer for the task from the target's

> perspective, and it MUST NOT do so more frequently." 

> 

> Question: Is it okay for a target to set the A bit multiple times
during the

> transmission of MaxBurstLength bytes as long as it does not have more
than

> one PDU outstanding with the A bit set? For example, lets say that

> MaxBurstLength is 256k and a target sends 32k of read data to an initiator

> with the A bit set. After receiving the SNACK-DataACK the target sends
more

> data with the A bit set again even though MaxBurstLength bytes haven't
been

> sent. I don't see how this behavior would be problematic for an initiator

> implementation but it seems to be disallowed by the statement in 10.7.2.

>
Your are not supposed to set the A bit more than once
for every MaxBurstLength
However you don't have to stop sending data to initiator
if you have an A bit "outstanding".
The A bit mechanism was introduced to limit the amount
of resources a target will commit to hold
buffers that the initiator may require him to retransmit.

> The reason it would be desirable for a target to request multiple
data ACKs

> is that often data on large reads gets pipelined. A small amount of
read

> data is first burst to the initiator followed by larger ones. Lets
say a

> target iSCSI driver first receives 16k, then 32k, then 128k, then
multiple

> 256k bursts from its SCSI layer when responding to a large read. If
the

> target driver can't set the A bit on each burst of data (as long as
the

> burst doesn't exceed MaxBurstLength) then the target may run into
annoying

> complexities and deadlock situations. 

> 
If you want to  pipeline A bits you have to state
a lower MaxBurstLength. I have trouble seeing how you can be deadlocked.

> You might say that the target iSCSI driver could wait for multiple
bursts

> and aggregate them into one burst on the wire of MaxBurstLength. This
seems

> possible but may lead to a target deadlock. If for example the target
driver

> receives a burst of data from its SCSI layer and wont get another
burst

> until buffers are freed up that were used for the first burst. 

> 
The target is not deadlocked - it just works slower
because you decided to
expose MaxBurstLength as the total of your buffer
space.

> Alternatively it might be suggested to limit MaxBurstLength to the
smallest

> burst that the iSCSI target driver will ever get from its SCSI layer.
This

> would solve the problem but might necessitate setting MaxBurstLength
to a

> prohibitively small value. Thus this solution doesn't seem optimal.

> 
MaxBurstLength should take into account you buffer
space and the RTT.

> A final obvious response would be to modify the target SCSI layer
so that it

> gives larger bursts to the iSCSI layer or to actually make the SCSI
layer

> aware of the iSCSI burst length requirements. However this may not
be

> practical for many target implementations whose SCSI layers have been
around

> long before iSCSI existed. These SCSI layers might require extensive

> non-trivial rework. 

> 

> Any input would be appreciated thanks, 

> 

> Bill 

> 

> 

> _______________________________________________

> Ips mailing list

> Ips@ietf.org

> https://www1.ietf.org/mailman/listinfo/ips

ips-bounces@ietf.org=20
  wrote on 15/02/2005 16:17:46:

> I've run into a small =
problem while=20
  considering what it would take to
> implement error recovery =
level 1 in=20
  an iSCSI target. The iSCSI specification
> states in 10.7.2: =

>=20

> "The target should use the A bit moderately; it MAY only set =
the A=20
  bit to 1
> once every MaxBurstLength bytes, or on the last =
Data-In PDU=20
  that concludes
> the entire requested read data transfer for the =
task=20
  from the target's
> perspective, and it MUST NOT do so more =
frequently."=20

> 
> Question: Is it okay for a target to set the A bit =
multiple=20
  times during the
> transmission of MaxBurstLength bytes as long =
as it=20
  does not have more than
> one PDU outstanding with the A bit =
set? For=20
  example, lets say that
> MaxBurstLength is 256k and a target =
sends 32k=20
  of read data to an initiator
> with the A bit set. After =
receiving the=20
  SNACK-DataACK the target sends more
> data with the A bit set =
again even=20
  though MaxBurstLength bytes haven't been
> sent. I don't see how =
this=20
  behavior would be problematic for an initiator
> implementation =
but it=20
  seems to be disallowed by the statement in 10.7.2. =

>
Your are not supposed to set the A bit more =
than once=20
  for every MaxBurstLength
However =
you don't=20
  have to stop sending data to initiator if you have an A bit=20
  "outstanding".
The A bit mechanism =
was=20
  introduced to limit the amount of resources a target will commit to=20
  hold
buffers that the initiator may =
require=20
  him to retransmit.

> =
The reason=20
  it would be desirable for a target to request multiple data =
ACKs
> is=20
  that often data on large reads gets pipelined. A small amount of =
read
>=20
  data is first burst to the initiator followed by larger ones. Lets say =

  a
> target iSCSI driver first receives 16k, then 32k, then 128k, =
then=20
  multiple
> 256k bursts from its SCSI layer when responding to a =
large=20
  read. If the
> target driver can't set the A bit on each burst =
of data=20
  (as long as the
> burst doesn't exceed MaxBurstLength) then the =
target=20
  may run into annoying
> complexities and deadlock situations. =

>=20

If you want to  pipeline A =
bits you=20
  have to state a lower MaxBurstLength. I have trouble seeing how you =
can be=20
  deadlocked.

> You might say =
that the=20
  target iSCSI driver could wait for multiple bursts
> and =
aggregate them=20
  into one burst on the wire of MaxBurstLength. This seems
> =
possible but=20
  may lead to a target deadlock. If for example the target =
driver
>=20
  receives a burst of data from its SCSI layer and wont get another=20
  burst
> until buffers are freed up that were used for the first =
burst.=20

> 
The target is not =
deadlocked -=20
  it just works slower because you decided to
expose MaxBurstLength as the total of your buffer=20
  space.

> Alternatively it =
might be=20
  suggested to limit MaxBurstLength to the smallest
> burst that =
the iSCSI=20
  target driver will ever get from its SCSI layer. This
> would =
solve the=20
  problem but might necessitate setting MaxBurstLength to a
>=20
  prohibitively small value. Thus this solution doesn't seem optimal. =

>=20

MaxBurstLength should take into =
account=20
  you buffer space and the RTT.

> A=20
  final obvious response would be to modify the target SCSI layer so =
that=20
  it
> gives larger bursts to the iSCSI layer or to actually make =
the SCSI=20
  layer
> aware of the iSCSI burst length requirements. However =
this may=20
  not be
> practical for many target implementations whose SCSI =
layers=20
  have been around
> long before iSCSI existed. These SCSI layers =
might=20
  require extensive
> non-trivial rework. 
> 
> Any =
input=20
  would be appreciated thanks, 
> 
> Bill 
> 
> =

>=20
  _______________________________________________
> Ips mailing=20
  list
> Ips@ietf.org
>=20
  https://www1.ietf.org/mailman/listinfo/ips

ips-bounces@ietf.org
 wrote=20
  on 15/02/2005 16:17:46:

> I've run into a small problem =
while=20
  considering what it would take to
> implement error recovery =
level 1 in=20
  an iSCSI target. The iSCSI specification
> states in 10.7.2: =

>=20

> "The target should use the A bit moderately; it MAY only set =
the A=20
  bit to 1
> once every MaxBurstLength bytes, or on the last =
Data-In PDU=20
  that concludes
> the entire requested read data transfer for the =
task=20
  from the target's
> perspective, and it MUST NOT do so more =
frequently."=20

> 
> Question: Is it okay for a target to set the A bit =
multiple=20
  times during the
> transmission of MaxBurstLength bytes as long =
as it=20
  does not have more than
> one PDU outstanding with the A bit =
set? For=20
  example, lets say that
> MaxBurstLength is 256k and a target =
sends 32k=20
  of read data to an initiator
> with the A bit set. After =
receiving the=20
  SNACK-DataACK the target sends more
> data with the A bit set =
again even=20
  though MaxBurstLength bytes haven't been
> sent. I don't see how =
this=20
  behavior would be problematic for an initiator
> implementation =
but it=20
  seems to be disallowed by the statement in 10.7.2. =

>

Your are not supposed to =
set the A bit=20
  more than once for every MaxBurstLength

However you don't have to stop sending data to =
initiator if you=20
  have an A bit "outstanding".

The A bit mechanism was introduced to limit the =
amount of=20
  resources a target will commit to hold

buffers that the initiator may require him to=20
  retransmit.

> The=20
  reason it would be desirable for a target to request multiple data=20
  ACKs
> is that often data on large reads gets pipelined. A small =
amount=20
  of read
> data is first burst to the initiator followed by =
larger ones.=20
  Lets say a
> target iSCSI driver first receives 16k, then 32k, =
then=20
  128k, then multiple
> 256k bursts from its SCSI layer when =
responding to=20
  a large read. If the
> target driver can't set the A bit on each =
burst=20
  of data (as long as the
> burst doesn't exceed MaxBurstLength) =
then the=20
  target may run into annoying
> complexities and deadlock =
situations.=20

> 

If you want=20
  to  pipeline A bits you have to state a lower MaxBurstLength. I =
have=20
  trouble seeing how you can be deadlocked.

> You might say that the target =
iSCSI=20
  driver could wait for multiple bursts
> and aggregate them into =
one=20
  burst on the wire of MaxBurstLength. This seems
> possible but =
may lead=20
  to a target deadlock. If for example the target driver
> =
receives a=20
  burst of data from its SCSI layer and wont get another burst
> =
until=20
  buffers are freed up that were used for the first burst. 
>=20

The =
target is not=20
  deadlocked - it just works slower because you decided =
to

expose MaxBurstLength as the =
total of your=20
  buffer space.

>=20
  Alternatively it might be suggested to limit MaxBurstLength to the=20
  smallest
> burst that the iSCSI target driver will ever get from =
its=20
  SCSI layer. This
> would solve the problem but might necessitate =
setting=20
  MaxBurstLength to a
> prohibitively small value. Thus this =
solution=20
  doesn't seem optimal. 
> 

MaxBurstLength should take into account you buffer =
space and=20
  the RTT.

> A final=20
  obvious response would be to modify the target SCSI layer so that =
it
>=20
  gives larger bursts to the iSCSI layer or to actually make the SCSI=20
  layer
> aware of the iSCSI burst length requirements. However =
this may=20
  not be
> practical for many target implementations whose SCSI =
layers=20
  have been around
> long before iSCSI existed. These SCSI layers =
might=20
  require extensive
> non-trivial rework. 
> 
> Any =
input=20
  would be appreciated thanks, 
> 
> Bill 
> 
> =

>=20
  _______________________________________________
> Ips mailing=20
  list
> Ips@ietf.org
>=20
  https://www1.ietf.org/mailman/listinfo/ips

ips-bounces@ietf.org

wrote on 15/02/2005 16:17:46:

> I've run into a small problem while considering what it would take
to

> implement error recovery level 1 in an iSCSI target. The iSCSI specification

> states in 10.7.2: 

> 

> "The target should use the A bit moderately; it MAY only set
the A bit to 1

> once every MaxBurstLength bytes, or on the last Data-In PDU that concludes

> the entire requested read data transfer for the task from the target's

> perspective, and it MUST NOT do so more frequently." 

> 

> Question: Is it okay for a target to set the A bit multiple times
during the

> transmission of MaxBurstLength bytes as long as it does not have more
than

> one PDU outstanding with the A bit set? For example, lets say that

> MaxBurstLength is 256k and a target sends 32k of read data to an initiator

> with the A bit set. After receiving the SNACK-DataACK the target sends
more

> data with the A bit set again even though MaxBurstLength bytes haven't
been

> sent. I don't see how this behavior would be problematic for an initiator

> implementation but it seems to be disallowed by the statement in 10.7.2.

>

Your are not supposed to set the A bit more than once for every MaxBurstLength

However you don't have to stop sending data to initiator if you have an
A bit "outstanding".

The A bit mechanism was introduced to limit the amount of resources a target
will commit to hold

buffers that the initiator may require him to retransmit.

> The reason it would be desirable for a target to request multiple
data ACKs

> is that often data on large reads gets pipelined. A small amount of
read

> data is first burst to the initiator followed by larger ones. Lets
say a

> target iSCSI driver first receives 16k, then 32k, then 128k, then
multiple

> 256k bursts from its SCSI layer when responding to a large read. If
the

> target driver can't set the A bit on each burst of data (as long as
the

> burst doesn't exceed MaxBurstLength) then the target may run into
annoying

> complexities and deadlock situations. 

> 

If you want to  pipeline A bits you have to state a lower MaxBurstLength.
I have trouble seeing how you can be deadlocked.

> You might say that the target iSCSI driver could wait for multiple
bursts

> and aggregate them into one burst on the wire of MaxBurstLength. This
seems

> possible but may lead to a target deadlock. If for example the target
driver

> receives a burst of data from its SCSI layer and wont get another
burst

> until buffers are freed up that were used for the first burst. 

> 

The target is not deadlocked - it just works slower because you decided
to

expose MaxBurstLength as the total of your buffer space.

> Alternatively it might be suggested to limit MaxBurstLength to the
smallest

> burst that the iSCSI target driver will ever get from its SCSI layer.
This

> would solve the problem but might necessitate setting MaxBurstLength
to a

> prohibitively small value. Thus this solution doesn't seem optimal.

> 

MaxBurstLength should take into account you buffer space and the RTT.

> A final obvious response would be to modify the target SCSI layer
so that it

> gives larger bursts to the iSCSI layer or to actually make the SCSI
layer

> aware of the iSCSI burst length requirements. However this may not
be

> practical for many target implementations whose SCSI layers have been
around

> long before iSCSI existed. These SCSI layers might require extensive

> non-trivial rework. 

> 

> Any input would be appreciated thanks, 

> 

> Bill 

> 

> 

> _______________________________________________

> Ips mailing list

> Ips@ietf.org

> https://www1.ietf.org/mailman/listinfo/ips
ips-bounces@ietf.org wrote on 23/02/2005 20:30:03:

> By "application", my example is a piece of code at a higher
level. 

> Perhaps a tape application that is streaming in large blocks ... or

> the application that Bill Sears refers to. In my example, the 

> application is unaware of the transport. So it would have no way to

> communicate MaxBurstLength to the transport.
> 
That is your design choice. MaxBurstLength is there
to be used as "external" indication of capabilities
without requiring an interaction.

> I really don't want to go into a debate on how
applications vs. 

> transports should be written and if an application should be 

> independent of the transport or not. I was simply pointing out a 

> case for the deadlock.
> 
Again the deadlock is a result of a design choice
protocol.
> A point that can be derived from this thread
is that the restriction

> put on the use of the A bit is not really necessary and leads to 

> unnecessary code.
> 
The restriction was put in place to avoid having ACK
requests being requested beyond an initially negotiate rate
MaxBurstLength has not many other uses :-)

> Eddy
> ----- Original Message ----- 
> From: Julian Satran 
> To: Eddy Quicksall 
> Cc: ips@ietf.org ; ips-bounces@ietf.org ; Sears_Bill@emc.com

> Sent: Wednesday, February 23, 2005 11:56 AM
> Subject: Re: [Ips] iSCSI question about positive
data acknowledgement
> 

> 

> Eddy, 

> 

> I am bit unsure of what you say. I will assume that the 

> "application" is the target function. 

> If that is the case why did the target accept a MaxBurstLength of

> 256K? ( it should have set it to at most 128k and optimally to 64k

> to allow for some pipelining). 

> 

> Julo 

> 

> 

> 

> 

> "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

> 23/02/2005 16:46 
> 

> To
> 

> <Sears_Bill@emc.com>, Julian Satran/Haifa/IBM@IBMIL 
> 

> cc
> 

> <ips@ietf.org>, <ips-bounces@ietf.org> 
> 

> Subject
> 

> Re: [Ips] iSCSI question about positive data acknowledgement
> 

> 

> 

> 

> Regarding the limitation put on the use of the A bit, there is a 

> case for a deadlock with regards to a session. Consider the following:

>   

> 1) the application uses double buffering 

> 2) the application buffers are 64K each 

> 3) the application needs to send READ data in buffered bursts 

> 4) the application has >128K to send 

> 5) the iSCSI layer uses 256K MaxBurstLength 

>   

> As each buffer is filled by the application, the application layer

> uses the transport to send that "buffer burst". As each
burst is 

> finished, the application layer then re-uses the completed buffer
to

> request more data from its environment. 

>   

> To support this, the iSCSI layer uses the A bit so it can inform the

> application layer when each send is complete. 

>   

> In the example above, the iSCSI layer will not be able to set the
A 

> bit and hence a dead lock for the session. 

>   

> Eddy 

> ----- Original Message ----- 

> From: Julian Satran 

> To: Sears_Bill@emc.com 

> Cc: ips@ietf.org ; ips-bounces@ietf.org 

> Sent: Tuesday, February 15, 2005 6:36 PM 

> Subject: Re: [Ips] iSCSI question about positive data acknowledgement

> 

> 

> Bill, 

> 

> Some answers in text. 

> 

> ips-bounces@ietf.org wrote on 15/02/2005 16:17:46:

> 

> > I've run into a small problem while considering what it would
take to

> > implement error recovery level 1 in an iSCSI target. The iSCSI
specification

> > states in 10.7.2: 

> > 

> > "The target should use the A bit moderately; it MAY only
set the A bit to 1

> > once every MaxBurstLength bytes, or on the last Data-In PDU that
concludes

> > the entire requested read data transfer for the task from the
target's

> > perspective, and it MUST NOT do so more frequently." 

> > 

> > Question: Is it okay for a target to set the A bit multiple times
during the

> > transmission of MaxBurstLength bytes as long as it does not have
more than

> > one PDU outstanding with the A bit set? For example, lets say
that

> > MaxBurstLength is 256k and a target sends 32k of read data to
an initiator

> > with the A bit set. After receiving the SNACK-DataACK the target
sends more

> > data with the A bit set again even though MaxBurstLength bytes
haven't been

> > sent. I don't see how this behavior would be problematic for
an initiator

> > implementation but it seems to be disallowed by the statement
in 10.7.2. 

> > 

> 

> Your are not supposed to set the A bit more than once for every MaxBurstLength

> However you don't have to stop sending data to initiator if you have

> an A bit "outstanding". 

> The A bit mechanism was introduced to limit the amount of resources

> a target will commit to hold 

> buffers that the initiator may require him to retransmit. 

> 

> > The reason it would be desirable for a target to request multiple
data ACKs

> > is that often data on large reads gets pipelined. A small amount
of read

> > data is first burst to the initiator followed by larger ones.
Lets say a

> > target iSCSI driver first receives 16k, then 32k, then 128k,
then multiple

> > 256k bursts from its SCSI layer when responding to a large read.
If the

> > target driver can't set the A bit on each burst of data (as long
as the

> > burst doesn't exceed MaxBurstLength) then the target may run
into annoying

> > complexities and deadlock situations. 

> > 

> 

> If you want to  pipeline A bits you have to state a lower 

> MaxBurstLength. I have trouble seeing how you can be deadlocked. 

> 

> > You might say that the target iSCSI driver could wait for multiple
bursts

> > and aggregate them into one burst on the wire of MaxBurstLength.
This seems

> > possible but may lead to a target deadlock. If for example the
target driver

> > receives a burst of data from its SCSI layer and wont get another
burst

> > until buffers are freed up that were used for the first burst.

> > 

> 

> The target is not deadlocked - it just works slower because you decided
to 

> expose MaxBurstLength as the total of your buffer space. 

> 

> > Alternatively it might be suggested to limit MaxBurstLength to
the smallest

> > burst that the iSCSI target driver will ever get from its SCSI
layer. This

> > would solve the problem but might necessitate setting MaxBurstLength
to a

> > prohibitively small value. Thus this solution doesn't seem optimal.

> > 

> 

> MaxBurstLength should take into account you buffer space and the RTT.

> 

> > A final obvious response would be to modify the target SCSI layer
so that it

> > gives larger bursts to the iSCSI layer or to actually make the
SCSI layer

> > aware of the iSCSI burst length requirements. However this may
not be

> > practical for many target implementations whose SCSI layers have
been around

> > long before iSCSI existed. These SCSI layers might require extensive

> > non-trivial rework. 

> > 

> > Any input would be appreciated thanks, 

> > 

> > Bill 

> > 

> > 

> > _______________________________________________

> > Ips mailing list

> > Ips@ietf.org

> > https://www1.ietf.org/mailman/listinfo/ips 
> 

> _______________________________________________

> Ips mailing list

> Ips@ietf.org

> https://www1.ietf.org/mailman/listinfo/ips 

> _______________________________________________

> Ips mailing list

> Ips@ietf.org

> https://www1.ietf.org/mailman/listinfo/ips

When would an iSCSI target have extra data to be transferred
beyond

the initiator's Expected Data Transfer Length? What is the initiator

supposed to do if the overflow bit is set?

Thanks,

Smitha

_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips =
mailing=20
  =
list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0004_01C51D86.1C9B7360--

--===============1063479941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1063479941==--

From ips-bounces@ietf.org  Mon Feb 28 13:00:43 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16411
	for ; Mon, 28 Feb 2005 13:00:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1D5pD5-0004iC-12
	for ips-web-archive@ietf.org; Mon, 28 Feb 2005 13:01:35 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1D5pBe-0003bC-RR; Mon, 28 Feb 2005 13:00:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pBc-0003au-Uz
	for ips@megatron.ietf.org; Mon, 28 Feb 2005 13:00:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16376
	for ; Mon, 28 Feb 2005 13:00:02 -0500 (EST)
Received: from mtagate3.de.ibm.com ([195.212.29.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pCP-0004gD-6v
	for ips@ietf.org; Mon, 28 Feb 2005 13:00:54 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j1SHxsFa094148
	for ; Mon, 28 Feb 2005 17:59:54 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j1SHxrEl147440 for ; Mon, 28 Feb 2005 18:59:53 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	j1SHxro4030103 for ; Mon, 28 Feb 2005 18:59:53 +0100
Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com
	[9.149.166.138])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	j1SHxr3X030097 for ; Mon, 28 Feb 2005 18:59:53 +0100
In-Reply-To: <000701c51db0$064a9d50$0303a8c0@ivivity.com>
To: "Eddy Quicksall" 
Subject: Re: [Ips] iSCSI - StatSN in a reinstatement
MIME-Version: 1.0
X-Mailer: IBM Lotus Notes Build V70_02012005 February 01, 2005
From: Julian Satran 
Message-ID: 
Date: Mon, 28 Feb 2005 19:59:50 +0200
X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5,
	2004) at 28/02/2005 19:59:53,
	Serialize complete at 28/02/2005 19:59:53
X-Spam-Score: 0.6 (/)
X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0067832990=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: e5bfa71b340354e384155def5e70b13b

This is a multipart message in MIME format.
--===============0067832990==
Content-Type: multipart/alternative;
	boundary="=_alternative 0061152CC2256FB6_="

This is a multipart message in MIME format.
--=_alternative 0061152CC2256FB6_=
Content-Type: text/plain; charset="US-ASCII"

It is not strictly required (the text does not say it is) and you could 
start a new sequence in the login response but it is not forbidden either.
And I assume that this is the path of least resistance - as the initial 
StatSN is arbitrary anyhow.

Julo

"Eddy Quicksall"  
28/02/2005 18:10

To
Julian Satran/Haifa/IBM@IBMIL
cc

Subject
Re: [Ips] iSCSI - StatSN in a reinstatement

That is correct but what I was asking is if the paragraphs were implying 
that the first login response of a reinstated connection was supposed to 
use the ExpStatSN for the value of StatSN. I think not.

Eddy
----- Original Message ----- 
From: Julian Satran 
To: Eddy Quicksall 
Cc: ips@ietf.org 
Sent: Saturday, February 26, 2005 8:36 AM
Subject: Re: [Ips] iSCSI - StatSN in a reinstatement

Eddy, 

Responses don't carry ExpStatSN. The first Login Request must carry the 
ExpStatSN of the old connection on a reinstated connection to indicate the 
target what Responses where received and processed by the initiator before 
logout. 

Julo 

"Eddy Quicksall"  
Sent by: ips-bounces@ietf.org 
25/02/2005 23:11 

To

cc

Subject
[Ips] iSCSI - StatSN in a reinstatement

10.12.9.  ExpStatSN 

   For the first Login Request on a connection this is ExpStatSN for the 
   old connection and this field is only valid if the Login Request 
   restarts a connection (see Section 5.3.4 Connection Reinstatement). 

   For subsequent Login Requests it is used to acknowledge the Login 
   Responses with their increasing StatSN values. 

10.13.4.  StatSN 

   For the first Login Response (the response to the first Login 
   Request), this is the starting status Sequence Number for the 
   connection.  The next response of any kind, including the next Login 
   Response, if any, in the same Login Phase, will carry this number + 
   1.  This field is only valid if the Status-Class is 0. 

I want to know if I understand correctly ... can you please confirm or 
contradict: 
I don't think this is saying a login which reinstates a connection must 
use ExpStatSN in the first login response. 

Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0061152CC2256FB6_=
Content-Type: text/html; charset="US-ASCII"

It is not strictly required (the text
does not say it is) and you could start a new sequence in the login response
but it is not forbidden either.

And I assume that this is the path of
least resistance - as the initial StatSN is arbitrary anyhow.

Julo

"Eddy Quicksall"
<eddy_quicksall_iVivity_iSCSI@comcast.net> 
28/02/2005 18:10

To
Julian Satran/Haifa/IBM@IBMIL

cc
<ips@ietf.org>

Subject
Re: [Ips] iSCSI - StatSN in a reinstatement

That is correct but what I was asking is if the paragraphs
were implying that the first login response of a reinstated connection
was supposed to use the ExpStatSN for the value of StatSN. I think not.

Eddy

----- Original Message ----- 

From: Julian
Satran 

To: Eddy
Quicksall 

Cc: ips@ietf.org

Sent: Saturday, February 26, 2005 8:36 AM

Subject: Re: [Ips] iSCSI - StatSN in a reinstatement

Eddy, 

Responses don't carry ExpStatSN. The first Login Request must carry the
ExpStatSN of the old connection on a reinstated connection to indicate
the target what Responses where received and processed by the initiator
before logout. 

Julo 

"Eddy Quicksall"
<eddy_quicksall_iVivity_iSCSI@comcast.net>

Sent by: ips-bounces@ietf.org

25/02/2005 23:11

To
<ips@ietf.org>

cc

Subject
[Ips] iSCSI - StatSN in a reinstatement

10.12.9.  ExpStatSN 

   For the first Login Request on a connection this is ExpStatSN for
the 

   old connection and this field is only valid if the Login Request

   restarts a connection (see Section 5.3.4 Connection Reinstatement).

   For subsequent Login Requests it is used to acknowledge the Login

   Responses with their increasing StatSN values.

10.13.4.  StatSN 

   For the first Login Response (the response to the first Login

   Request), this is the starting status Sequence Number for the

   connection.  The next response of any kind, including the
next Login 

   Response, if any, in the same Login Phase, will carry this number
+ 

   1.  This field is only valid if the Status-Class is 0.

I want to know if I understand correctly ... can you please confirm or
contradict: 

I don't think this is saying a login which reinstates a connection must

use ExpStatSN in the first login response. 

Eddy_______________________________________________

Ips mailing list

Ips@ietf.org

https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0061152CC2256FB6_=--

--===============0067832990==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0067832990==--

From ips-bounces@ietf.org  Mon Feb 28 13:50:35 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21359
	for ; Mon, 28 Feb 2005 13:50:35 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1D5pzJ-0005ti-Lq
	for ips-web-archive@ietf.org; Mon, 28 Feb 2005 13:51:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1D5pyO-0000xv-MH; Mon, 28 Feb 2005 13:50:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pyN-0000vW-5W
	for ips@megatron.ietf.org; Mon, 28 Feb 2005 13:50:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21331
	for ; Mon, 28 Feb 2005 13:50:11 -0500 (EST)
Received: from sccrmhc11.comcast.net ([204.127.202.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pyt-0005sy-MV
	for ips@ietf.org; Mon, 28 Feb 2005 13:51:01 -0500
Received: from ivvt2dxrc11
	(c-66-177-46-174.se.client2.attbi.com[66.177.46.174])
	by comcast.net (sccrmhc11) with SMTP
	id <2005022818495501100t2uc8e>; Mon, 28 Feb 2005 18:49:55 +0000
Message-ID: <000f01c51dc6$4b9a7130$0303a8c0@ivivity.com>
From: "Eddy Quicksall" 
To: 
Date: Mon, 28 Feb 2005 13:49:54 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Subject: [Ips] iSCSI: proper response if no targets available
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1802144844=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8

This is a multi-part message in MIME format.

--===============1802144844==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C51D9C.6226F0B0"

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C51D9C.6226F0B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   A SendTargets response MUST NOT contain target names if there are no

   targets for the requesting initiator to access.

Does this mean the response would be:

"TargetName=3D"

or

No Data Segment?

Eddy

------=_NextPart_000_000C_01C51D9C.6226F0B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   =
A=20
SendTargets response MUST NOT contain target names if there are=20
no
   =
targets=20
for the requesting initiator to access.

Does this mean the response would =
be:

"TargetName=3D"

or

No Data Segment?

Eddy

------=_NextPart_000_000C_01C51D9C.6226F0B0--

--===============1802144844==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1802144844==--

From ips-bounces@ietf.org  Mon Feb 28 18:38:34 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21775
	for ; Mon, 28 Feb 2005 18:38:34 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1D5uU3-0003xy-SI
	for ips-web-archive@ietf.org; Mon, 28 Feb 2005 18:39:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1D5uRH-0005Fc-RL; Mon, 28 Feb 2005 18:36:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uRG-0005FP-3R
	for ips@megatron.ietf.org; Mon, 28 Feb 2005 18:36:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21573
	for ; Mon, 28 Feb 2005 18:36:31 -0500 (EST)
Received: from email.crossroads.com ([65.68.235.6])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5uS3-0003uY-NX
	for ips@ietf.org; Mon, 28 Feb 2005 18:37:26 -0500
Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by
	email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); 
	Mon, 28 Feb 2005 17:36:21 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] iSCSI: proper response if no targets available
Date: Mon, 28 Feb 2005 17:36:21 -0600
Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006C87@mailnode1.commstor.crossroads.com>
Thread-Topic: [Ips] iSCSI: proper response if no targets available
Thread-Index: AcUdxraJImidQ/fhTjasU9G9NsLw4gAAJfsQ
From: "Buck Landry" 
To: "Eddy Quicksall" ,

X-OriginalArrivalTime: 28 Feb 2005 23:36:21.0706 (UTC)
	FILETIME=[4F2342A0:01C51DEE]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============2141834449=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41

This is a multi-part message in MIME format.

--===============2141834449==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C51DEE.4EEDA4E3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C51DEE.4EEDA4E3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Appendix D. also says
=20
>>>
... Each target is returned as a target record.  A target record begins =
with the TargetName text key, followed by a list of TargetAddress text =
keys, and bounded by the end of the text response or the next TargetName =
key, which begins a new record. ...
<<<
=20
If each target takes the form of a target record, and you have zero =
targets, then you should have zero "target records", and therefore zero =
instances of "TargetName"/"TargetAddress".
=20
So, I believe you should return no data segment.
=20
--buck

-----Original Message-----
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of =
Eddy Quicksall
Sent: Monday, February 28, 2005 12:50 PM
To: ips@ietf.org
Subject: [Ips] iSCSI: proper response if no targets available

   A SendTargets response MUST NOT contain target names if there are no

   targets for the requesting initiator to access.

=20

Does this mean the response would be:

=20

"TargetName=3D"

=20

or

=20

No Data Segment?

=20

Eddy

------_=_NextPart_001_01C51DEE.4EEDA4E3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Appendix D. also says

>>>
...=20
Each target is returned as a target record.  A target record begins =
with=20
the TargetName text key, followed by a list of TargetAddress text keys, =
and=20
bounded by the end of the text response or the next TargetName key, =
which begins=20
a new record. ...
<<<

If=20
each target takes the form of a target record, and you have zero =
targets, then=20
you should have zero "target records", and therefore zero instances of=20
"TargetName"/"TargetAddress".

So, I believe you should return no data =
segment.

--buck

  -----Original Message-----
From: =
ips-bounces@ietf.org=20
  [mailto:ips-bounces@ietf.org]On Behalf Of Eddy=20
  Quicksall
Sent: Monday, February 28, 2005 12:50 =
PM
To:=20
  ips@ietf.org
Subject: [Ips] iSCSI: proper response if no =
targets=20
  available

     =
A=20
  SendTargets response MUST NOT contain target names if there are=20
  no
     =
targets=20
  for the requesting initiator to access.

  Does this mean the response would =
be:

  "TargetName=3D"

  or

  No Data Segment?

  Eddy

------_=_NextPart_001_01C51DEE.4EEDA4E3--

--===============2141834449==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============2141834449==--