Subject: Re: iSCSI: changing MaxPDUDataLength

From: "Julian Satran" <[email-masked]>
Date: Wed, 12 Jun 2002 00:28:28 +0300

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."                                                                                                     
                      <[email-masked]>        To:       <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL                                  
                      Sent by:                 cc:                                                                                         
                      [email-masked]        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
[email-masked]

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
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
<[email-masked]>
>                       06/11/2002 04:04         cc:      [email-masked],
[email-masked]

>                       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:       [email-masked],
[email-masked]
>                                                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:[email-masked]]
>       Sent: Monday, June 10, 2002 8:06 PM
>       To: Eddy Quicksall
>       Cc: [email-masked]; [email-masked]
>       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
>    <[email-masked]>              To:        Julian
>                                      Satran/Haifa/IBM@IBMIL
>                                              cc:        [email-masked],
>    06/11/2002 12:32 AM               [email-masked]
>    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:[email-masked]]
>       Sent: Saturday, June 08, 2002 10:16 PM
>       To: Eddy Quicksall
>       Cc: [email-masked]; [email-masked]; [email-masked]
>       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
>    <[email-masked]>             To:
>    Sent by: [email-masked]    [email-masked]
>                                             cc:        [email-masked]
>                                             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: [email-masked] [mailto:[email-masked]]
>       Sent: Friday, June 07, 2002 1:13 PM
>       To: [email-masked]; [email-masked]
>       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:[email-masked]]
>       Sent: Wednesday, June 05, 2002 12:24 PM
>       To: [email-masked]
>       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: [email-masked]
>
>
>
>
>
>
>
>
>
>

---

From: "Rod Harrison" <[email-masked]>
Date: Tue, 11 Jun 2002 18:57:36 -0500

I'm torn, I don't want to make this sort of change late on but I
think it would be a good thing in the long term.

	How about adding the additional async message code and saying upon
receipt the initiator MAY start a negotiation sequence or logout and
re-login the connection immediately without having to wait for the
negotiated timeouts?

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
Sent: Tuesday, June 11, 2002 4:28 PM
To: Mallikarjun C.
Cc: [email-masked]; Julian Satran; [email-masked]
Subject: Re: iSCSI: changing MaxPDUDataLength
Importance: High

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."
                      <[email-masked]>        To:
<[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
                      Sent by:                 cc:
                      [email-masked]        Subject:  Re: iSCSI:
changing MaxPDUDataLength
                      .edu

                      06/11/2002 10:50
                      PM
                      Please respond to
                      "Mallikarjun C."

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

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 11, 2002 8:34 AM
Subject: RE: iSCSI: changing MaxPDUDataLength

Asynch
>                                                To:      Eddy
Quicksall
[email-masked]

Satran/Haifa/IBM@IBMIL
(in
Satran/Haifa/IBM@IBMIL
[email-masked]
if
up
>                                              cc:
[email-masked],
and
I
should
>                                             cc:
[email-masked]
>                                             Subject:        RE:
the

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 11 Jun 2002 18:10:55 -0700

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

---

From: "Rod Harrison" <[email-masked]>
Date: Tue, 11 Jun 2002 18:57:36 -0500

- Rod

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

Mallikarjun,

Julo

                      "Mallikarjun C."
                      <[email-masked]>        To:

                      06/11/2002 10:50
                      PM
                      Please respond to
                      "Mallikarjun C."

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 11, 2002 8:34 AM
Subject: RE: iSCSI: changing MaxPDUDataLength

Asynch
Quicksall
[email-masked]

Satran/Haifa/IBM@IBMIL
(in
Satran/Haifa/IBM@IBMIL
[email-masked]
if
up
[email-masked],
and
I
should
[email-masked]
the

---

From: "Rod Harrison" <[email-masked]>
Date: Tue, 11 Jun 2002 18:57:36 -0500

- Rod

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

Mallikarjun,

Julo

                      "Mallikarjun C."
                      <[email-masked]>        To:

                      06/11/2002 10:50
                      PM
                      Please respond to
                      "Mallikarjun C."

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 11, 2002 8:34 AM
Subject: RE: iSCSI: changing MaxPDUDataLength

Asynch
Quicksall
[email-masked]

Satran/Haifa/IBM@IBMIL
(in
Satran/Haifa/IBM@IBMIL
[email-masked]
if
up
[email-masked],
and
I
should
[email-masked]
the

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 11 Jun 2002 18:10:55 -0700

Julian,

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka