Re: iSCSI: changing MaxPDUDataLength

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

I knew that the question was general, but I couldn't find any other
key whose redeclaration/renegotiation is important during the life of
a connection - and the proposed didn't look very useful for this key.
Consequently, I don't see a strong reason for the addition except
for completeness.

Regards.
--
Mallikarjun

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


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: <ips@ece.cmu.edu>; "Julian Satran" <Julian_Satran@il.ibm.com>; <owner-ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 2:28 PM
Subject: Re: iSCSI: changing MaxPDUDataLength


>
> Mallikarjun,
>
> The question was general and not specific to MaxRecv....
> Although we say that negotiation is symmetric we don't have any mechanism
> through which a target can say it wants to start negotiation something
> (sort of similar but not as strong as a the "request logout" - "request to
> negotiate" that will require the initiator to issue a text request and
> kick-off a negotiation.
>
> Julo
>
>
>
>                       "Mallikarjun C."
>                       <cbm@rose.hp.com>        To:       <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
>                       Sent by:                 cc:
>                       owner-ips@ece.cmu        Subject:  Re: iSCSI: changing MaxPDUDataLength
>                       .edu
>
>
>                       06/11/2002 10:50
>                       PM
>                       Please respond to
>                       "Mallikarjun C."
>
>
>
>
>
> >  I also realized that we don't have "negotiation prompt" from the target.
> >  I am not sure that we need one.
>
> I am not sure about it either.
>
> My preference is not to add this.  It appears to me that a target does have
> the option of dropping the connection today if it can't work with
> non-ULPDU-contained
> segments for too long.  I suspect that the target would do the same if (we
> introduced the "negotiation prompt" and) the initiator doesn't/couldn't
> honor the
> "negotiation prompt".
>
> Thanks.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
>
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Tuesday, June 11, 2002 8:34 AM
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> > I suggest the following text in 11.13
> >
> >        A change of MaxRecvDataSegmentLength by an initiator or target
> >        becomes effective after all commands preceding the negotiation
> >        end-ing request have been processed by the target and their status
> >        is acknowledged.
> >
> >  I also realized that we don't have "negotiation prompt" from the target.
> >  I am not sure that we need one.
> >  If some of you think we need we may want one additional code in the
> Asynch
> >  Message.
> >  Please comment TODAY.
> >
> >  Julo
> > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM -----
> >
> >                       Julian Satran
> >                                                To:      Eddy Quicksall
> <eddy_quicksall@ivivity.com>
> >                       06/11/2002 04:04         cc:      ips@ece.cmu.edu,
> pat_thaler@agilent.com
>
> >                       PM                       From:    Julian
> Satran/Haifa/IBM@IBMIL
> >                                                Subject: RE: iSCSI:
> changing MaxPDUDataLength(Document link:
> Julian Satran - Mail)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > That is a fair request - we may slip in a recommendation to that effect
> (in
> > chapter 11?)
> >
> > Julo
> >
> >
> >
> >                       Eddy Quicksall
> >                       <eddy_quicksall@i        To:       Julian
> Satran/Haifa/IBM@IBMIL
> >                       vivity.com>              cc:       ips@ece.cmu.edu,
> pat_thaler@agilent.com
> >                                                Subject:  RE: iSCSI:
> changing MaxPDUDataLength
> >                       06/11/2002 04:28
> >                       AM
> >                       Please respond to
> >                       Eddy Quicksall
> >
> >
> >
> >
> >
> > 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>              To:        Julian
> >                                      Satran/Haifa/IBM@IBMIL
> >                                              cc:        ips@ece.cmu.edu,
> >    06/11/2002 12:32 AM               pat_thaler@agilent.com
> >    Please respond to Eddy Quicksall          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>             To:
> >    Sent by: owner-ips@ece.cmu.edu    pat_thaler@agilent.com
> >                                             cc:        ips@ece.cmu.edu
> >                                             Subject:        RE: iSCSI:
> >    06/08/2002 10:54 PM               changing MaxPDUDataLength
> >    Please respond to Eddy Quicksall
> >
> >
> >
> >
> >
> >
> >
> >       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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>