Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ?

From: Santosh Rao <[email-masked]>
Date: Tue, 05 Feb 2002 11:55:35 -0800

Hello,

Can someone clarify if the login key FirstBurstSize is valid when :
InitialR2T=yes  and ImmediateData=yes ?

i.e. if immediate data is enabled and un-solicited data is disabled
during login negotiation, is the value of FirstBurstSize received in the
login response to be interpreted ?

My current understanding is that FirstBurstSize is inclusive of the
immediate data portion, and so, if immediate data is enabled, but
un-solicited data is disabled, then, FirstBurstSize *must* be valid and
must be <= DataPDULength. (after rev 09, it would be <=
(MaxRecvPDULength - the header components size)).

For example, a target implementation may offer a FirstBurstSize <
DataPDULength, in which case, the immediate data size is the
MIN(DataPDULength, FirstBurstSize, bytes_to_send).

Can someone clarify if this is a correct interpretation or set me right
on this ?

Thanks,
Santosh

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 6 Feb 2002 12:46:45 -0500

That is how I am interpreting it.

BTW: How about this one ...

I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no

If the target does not support InitialR2T=no, how should it respond to
FirstBurstSize?

Should the target do this (for draft >= 9)?

T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no

Eddy

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Tuesday, February 05, 2002 2:56 PM
To: IPS Reflector
Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Hello,

Thanks,
Santosh

---

From: "Martin, Nick" <[email-masked]>
Date: Wed, 6 Feb 2002 16:06:08 -0600

Santosh,

One clarification is that MaxRecvPDULength (formerly DataPDULength),
FirstBurstSize, and MaxBurstSize limit the size of the data segment or
payload portion of the PDU.  The header and digests are not counted
within these lengths.  (Also note that these are now in bytes now all
512 byte chunks.)  Their ranges are 512 to (2**24)-1.  The upper bound
corresponding to the max value which can be expressed in the 24-bit
field DataSegmentLength.  If the value is 1024, it means 1024 bytes of
data, not 1024 minus 48-byte header, minus up to two 4-byte digests.  

Compute your own overhead before negotiating the value.  One may want to
make sure all iSCSI PDUs fit within MTU.  If the MTU, the overhead of
the protocols below iSCSI, and the overhead of iSCSI are known, the
number of iSCSI data bytes that will fit in a MTU size packet can be
computed and negotiated.  It does not need to be a power of 2 nor a
multiple of 512.  A multiple of 4 is expected.

As has been pointed out some values may become unused or meaningless due
to the setting of other values.  The responder may reply with
key=irrelevant.  However I see no harm in accepting a numeric value,
although it may not be used.  The intention of the initiator may be to
replace the default value in case part or all of the negotiation for
no-unsolicited data is rejected.

It is not invalid to have FirstBurstSize less than MaxRecvPDULength and
ImmediateData=yes and InitialR2T=no.  In this case InitialR2T=no cause
no different behavior from InitialR2T=yes, since the FirstBurstSize will
always be satisfied with immediate data.  I do not think it would be
appropriate to reply InitialR2T=Irrelevant.

I think key=Irrelevant should be used when the responder is required to
reply, but can not construct a reply that makes sense.  This could be
due to something else making the key meaningless.  Examples might be a
prior FMarker=no making RFMarkInt=Irrelevant, or a prior AuthMethod=SRP
causing CHAP_A=Irrelevant.  Key=Reject may fit such cases as well or
better, if the other end should already know the prior result.

Thanks,
Nick

> Sent: Tuesday, February 05, 2002 1:56 PM
> To: IPS Reflector

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 7 Feb 2002 06:39:10 +0200

Why should we?  The way it is the parameters can be checked without
relation one to another.
The is no logical flaw in having FirstBurstSize <> 0 and no use for it.

Julo

                    Santosh Rao                                                              
                    <santoshr@cup.       To:     Eddy Quicksall <[email-masked]> 
                    hp.com>              cc:     IPS Reflector <[email-masked]>             
                    Sent by:             Subject:     Re: ips : Is FirstBurstSize valid when 
                    owner-ips@ece.        InitialR2T=yes ?                                   
                    cmu.edu                                                                  

                    06-02-02 23:32                                                           

I think this needs changing then. There's no reason the following
should'nt be allowed :

I -> T :
           InitialR2T=no
           ImmediateData=yes
           FirstBurstSize=65536

T -> I :
           InitialR2T=yes
           ImmediateData=no
           FirstBurstSize=0

Julian :
Can we change the allowed valid range for FirstBurstSize from :

FirstBurstSize=<number-512-to-(2**24-1)>

to :

FirstBurstSize=<number-0-to-(2**24-1)>

- Santosh

Eddy Quicksall wrote:
>
> Draft 10 says:
>
> FirstBurstSize=<number-512-to-(2**24-1)>
>
> So that means you can't send a 0, doesn't it?
>
> Eddy
>
> Sent: Wednesday, February 06, 2002 3:01 PM
> To: Fischer, Michael
> Cc: 'Eddy Quicksall'; IPS Reflector
> Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?
>
> IMO, the FirstBurstSize key value negotiated during login is a don't
> care if *BOTH* immediate data and un-solicited data have been disabled.
>
> However, if the target knows up-front that it does not support either
> immediate or un-solcited and it receives the key FirstBurstSize during
> login negotiation, it should return a 0 value as the result of the
> negotiation for FirstBurstSize.
>
> (Note that the special semantics of 0 implying no limit is no longer
> true for FirstBurstSize and hence, the target can just return 0 iff both
> immediata data and un-solicited data are disabled in login negotiation.)
>
> - Santosh
>
> "Fischer, Michael" wrote:
> >
> > What if the sequence is as follows:
> >
> > I->T    FirstBurstSize=512; T=0; NSG=CSG;
> > T->I    FirstBurstSize=512; T=0; NSG=CSG;
> > I->T    InitialR2T=no, ImmediateData=no; T=1; NSG=FULL
> >
> > If the target does not support InitialR2T=no..  Does login now fail?
> There
> > does not seem to be a way for the target to say that it requires R2T.
Why
> > did the Initiator send FirstBurstSize if it was setting InitialR2T to
no?
> > There is no negotiation with an AND function.
> >
> > Michael Fischer
> >
> > From: Eddy Quicksall [mailto:[email-masked]]
> > Sent: Wednesday, February 06, 2002 9:47 AM
> > To: Santosh Rao; IPS Reflector
> > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?
> >

---

From: Eddy Quicksall <[email-masked]>
Date: Thu, 7 Feb 2002 06:56:17 -0500

Given that the target can't do immediate or unsolicited, should it give
"Irrelevant" as the answer? I.e.:

T->I FirstBurstSize=Irrelevant, InitialR2T=yes, ImmediateData=no

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 11:39 PM
To: [email-masked]
Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Julo

                    Santosh Rao

                    <santoshr@cup.       To:     Eddy Quicksall
<[email-masked]>
                    hp.com>              cc:     IPS Reflector
<[email-masked]>            
                    Sent by:             Subject:     Re: ips : Is
FirstBurstSize valid when
                    owner-ips@ece.        InitialR2T=yes ?

                    cmu.edu

                    06-02-02 23:32

I -> T :
           InitialR2T=no
           ImmediateData=yes
           FirstBurstSize=65536

T -> I :
           InitialR2T=yes
           ImmediateData=no
           FirstBurstSize=0

Julian :

to :

- Santosh

Why
no?

---

From: Eddy Quicksall <[email-masked]>
Date: Thu, 7 Feb 2002 07:33:50 -0500

Nick,

Given your last paragraph below, do you agree this would be correct (draft
10) (InitialR2T=yes and ImmediateData=no make FirstBurstSize meaningless):

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 5:06 PM
To: Santosh Rao; IPS Reflector
Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Santosh,

Thanks,
Nick

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 8 Feb 2002 01:00:01 +0200

It can give any legal value. Why should we add rules?  Is something wrong
having a value that is not used?

Julo

                    Eddy Quicksall                                                               
                    <Eddy_Quicksall@iv       To:     Julian Satran/Haifa/IBM@IBMIL,              
                    ivity.com>                [email-masked]                                    
                                             cc:                                                 
                    07-02-02 13:56           Subject:     RE: ips : Is FirstBurstSize valid when 
                                              InitialR2T=yes ?                                   

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 11:39 PM
To: [email-masked]
Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Julo

                    Santosh Rao

                    cmu.edu

                    06-02-02 23:32

I -> T :
           InitialR2T=no
           ImmediateData=yes
           FirstBurstSize=65536

T -> I :
           InitialR2T=yes
           ImmediateData=no
           FirstBurstSize=0

Julian :

to :

- Santosh

Why
no?

---

From: "Martin, Nick" <[email-masked]>
Date: Thu, 7 Feb 2002 19:37:41 -0600

Eddy,

Regarding your example exchange below.

First, I would have parsed the incoming buffer from left to right so I
would have constructed my response for FirstBurstSize before recognizing
that it would not be used.  Second, I am confident that
FirstBurstSize=512 is a sensible response, even given that the initiator
will not be allowed to send a first burst due to the other settings
(soon to be in effect), and also presuming that FirstBurstSize=512 had
been listed last in the buffer.  The target and initiator would each
have a new value for FirstBurstSize.  

However, I suppose I must admit that this may not be an invalid
response.  The originator must treat the response as negotiation failure
for FirstBurstSize.  The value previously in effect (probably the
default) is unchanged for both originator and responder.
If the initiator is parsing from left to right (as I presume it should),
it will not yet know why the value Irrelevant was returned by the
target.  (It might over-react and close the connection.)

I think the value Irrelevant should be used sparingly.  In this case,
the values 512, Irrelevant, and Reject will have the same effect on
subsequent packets on the wire unless and until ImmediateData or
InitialR2T are negotiated again.  At that time the current value of
FirstBurstSize again becomes useful.  There is some rule about least
surprise which I can not quote at the moment, but given that these three
possible return values produce the same result, I would send the 512
since that will be least surprising to the initiator.

Remember that Irrelevant does not mean forgotten.  There is still a
current value in effect, even if the target chooses not to re-negotiate
it at this time.  I would not choose to refuse to accept the new value
for FirstBurstSize.  However if I wanted to so choose, I think I would
use Reject.

If the target does not support unsolicited nor immediate data and will
never use the value FirstBurstSize, it could still keep a current value
for the field.  In doing so it will be less likely to force an initiator
down a seldom trodden path.  

Thanks,
Nick

> Sent: Thursday, February 07, 2002 6:34 AM
> To: Martin, Nick
> Cc: Santosh Rao; IPS Reflector

---

From: Eddy Quicksall <[email-masked]>
Date: Fri, 8 Feb 2002 10:42:07 -0500

I actually use 512 in my code because I know it won't be used. I gave this
example because the current definition of Irrelevant implied that it was
acceptable.

I think the definition for Irrelevant should be improved. But, if everyone
else is fine with it, I'll accept that.

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 6:00 PM
To: Eddy Quicksall
Cc: [email-masked]; Julian Satran
Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Julo

                    Eddy Quicksall

                    <Eddy_Quicksall@iv       To:     Julian
Satran/Haifa/IBM@IBMIL,             
                    ivity.com>                [email-masked]

                                             cc:

                    07-02-02 13:56           Subject:     RE: ips : Is
FirstBurstSize valid when
                                              InitialR2T=yes ?

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 11:39 PM
To: [email-masked]
Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Julo

                    Santosh Rao

                    cmu.edu

                    06-02-02 23:32

I -> T :
           InitialR2T=no
           ImmediateData=yes
           FirstBurstSize=65536

T -> I :
           InitialR2T=yes
           ImmediateData=no
           FirstBurstSize=0

Julian :

to :

- Santosh

Why
no?