RE: iSCSI: changing MaxPDUDataLength

["Rod Harrison" <rod.harrison@windriver.com>]

Mallikarjun ,

	The current wording doesn't appear to prevent the initiator from
staging new commands whilst the negotiation is in process and
therefore the target may never find a "good time" to end the
negotiation sequence.

	I don't think idling the connection would be a big issue in the event
of  PMTU change since the worst case is that existing commands have to
run to completion using the inefficient PMTU. The initiator also has
the options of aborting and restarting the commands if they can't
complete with the old PMTU, or better, open another connection with
the appropriate MaxPDUDataLength and change the command allegiance.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mallikarjun C.
Sent: Tuesday, June 11, 2002 2:35 PM
To: Eddy Quicksall; Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: changing MaxPDUDataLength


Eddy,

I am not clear on why you think the target code becomes messy on
a PDU size change.  The last para in section 4.4 states the
following -

"Parameters negotiated by a text exchange negotiation sequence become
effective only after the negotiation sequence is completed."

Since the target gets to complete a text negotiation with a Text
Response
PDU, it can time the applicability of a changed
MaxRecvDataSegmentLength.

Requiring that an initiator must idle the connection before changing
this
parameter, IMHO, is counter-productive when there's a dynamic PMTU
degradation in the presence of long-running commands (writes in
particular).
Once the initiator starts the renegotiation, target would ideally want
to quickly
renegotiate its receive size as well to receive ULPDU-contained
segments.

In short, seems to me that the draft is saying what you would like.
--
Mallikarjun

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


----- Original Message -----
From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 7:56 AM
Subject: RE: iSCSI: changing MaxPDUDataLength


> I think it should be a requirement because if it is not, all target
code
> will have to have the messy code. Or, we could say that if it is not
idle
> commands, then the target may reject it.
>
> Eddy
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Tuesday, June 11, 2002 9:11 AM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
>
> That is a fair request - we may slip in a recommendation to that
effect (in
> chapter 11?)
>
> Julo
>
>
>
> Eddy Quicksall <eddy_quicksall@ivivity.com>
>
>
> 06/11/2002 04:28 AM
> Please respond to Eddy Quicksall
>
>
>
>         To:        Julian Satran/Haifa/IBM@IBMIL
>         cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
>         Subject:        RE: iSCSI: changing MaxPDUDataLength
>
>
>
>
> How about if we say that an initiator must not change the
MaxPDUDataSize
> unless it first idles the commands (at least the ones with the R
bit) or if
> ErrorRecoveryLevel==0?
>
> That would simplify target code greatly and would meet the design
goals; and
> since it should be rare to change it, it would be of little impact
to idle
> the commands for a split second.
>
>
> Eddy
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, June 10, 2002 8:06 PM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> I said only that when you change length you can ask for all PDUs
after the
> ack! (no need to keep a tall - the old offsets are good up to the
hole).
>
> Julo
>
>
> Eddy Quicksall <eddy_quicksall@ivivity.com>
>
>
> 06/11/2002 12:32 AM
> Please respond to Eddy Quicksall
>
>
>        To:        Julian Satran/Haifa/IBM@IBMIL
>        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
>        Subject:        RE: iSCSI: changing MaxPDUDataLength
>
>
>
>
>
> Julian,
>
> Another problem here is that the target has to calculate the offset
from the
> DataSN #. And as BegRun can be any value. E.g., BegRun=4 and
RunLngth=0
> means starting DataSN=4, send all the data for that sequence.
>
> I think it would be a performance hit and waist of memory to keep a
tally of
> all PDU sizes just for an occasional SNACK.
>
> It's not that it can't be done ... it is more that it is messy and I
think
> there is a solution that will satisfy the design requirements but
keep the
> software simpler.
>
> Eddy
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, June 08, 2002 10:16 PM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> That is not completely accurate.
> The only problem is when PDU size decreases and then SNACK must be
for all
> data.
> Target can also keep a mapping of numbers/to offsets (the list
should be
> small and if it gets long ask for ack (A-bit).
>
> Julo
>
> Eddy Quicksall <eddy_quicksall@ivivity.com>
> Sent by: owner-ips@ece.cmu.edu
>
>
> 06/08/2002 10:54 PM
> Please respond to Eddy Quicksall
>
>
>       To:        pat_thaler@agilent.com
>       cc:        ips@ece.cmu.edu
>       Subject:        RE: iSCSI: changing MaxPDUDataLength
>
>
>
>
>
>
> Thanks,
>
> As a target, I won't be able to let it change until all of the
outstanding
> commands are finished (running with ErrorRecoveryLevel>=1). This is
because
> I must use the PDU size to compute the offset from a SNACK's
> BegRun/RunLength.
>
> So, I plan to not give the text response for a MaxPDURecvDataLength
in FFP
> until I get back an ExpStatSN == next StatSN.
>
> This will cause a delay of unknown time before the PDU size can
actually
> change ... do you see any problem with this?
>
> Eddy
>
> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Friday, June 07, 2002 1:13 PM
> To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> Eddy,
>
> If one uses a message sync and steering that relys on the transport
segments
> carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if
the path
> MTU changes one would want to change the PDU data length to fit the
new path
> MTU.
>
> Pat
>
> -----Original Message-----
> From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
> Sent: Wednesday, June 05, 2002 12:24 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: changing MaxPDUDataLength
>
>
> Does anybody know a case where it is necessary to support a new PDU
data
> length during full feature phase?
>
> Eddy
> mailto: Eddy_Quicksall@iVivity.com
>
>
>
>
>
>
>
>