RE: iSCSI: changing MaxPDUDataLength

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

Mallikarjun,

	I had tracked your earlier comments, I was just responding to Eddy's
concern that there is a need for a "good time" from the target's
perspective and saying I don't believe quiescing the connection would
be an issue from an initiator's perspective. I still don't, I think
the imitator has enough tools to avoid quiescing a connection if it
believes that to be a bad thing.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mallikarjun C.
Sent: Wednesday, June 12, 2002 12:58 PM
To: Rod Harrison
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: changing MaxPDUDataLength


Rod,

If you had tracked my earlier comments, you'd notice that
I'm arguing that there's no specific reason for a "good time".
Certain hardware implementations may choose to effect the
change only on Data-In sequence boundaries, but the basic
nature of text negotiation allows for that flexibility.

Yes, as you suggest, we have a variety of other options including
dropping the I/Os, or the connection etc.  But the point in allowing
dynamic redeclaration of this key is to make iSCSI adapt to
but not be impacted by, lower-level dynamics - similar to TCP.
--
Mallikarjun

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


----- Original Message -----
From: "Rod Harrison" <rod.harrison@windriver.com>
To: "Mallikarjun C." <cbm@rose.hp.com>; "Eddy Quicksall"
<eddy_quicksall@ivivity.com>; "Julian Satran"
<Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 4:15 PM
Subject: RE: iSCSI: changing MaxPDUDataLength


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