Subject: RE: iSCSI: changing MaxPDUDataLength

From: Eddy Quicksall <[email-masked]>
Date: Tue, 11 Jun 2002 10:56:21 -0400

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:[email-masked]]
Sent: Tuesday, June 11, 2002 9:11 AM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]
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 <[email-masked]> 

06/11/2002 04:28 AM 
Please respond to Eddy Quicksall 

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

06/11/2002 12:32 AM 
Please respond to Eddy Quicksall 

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

06/08/2002 10:54 PM 
Please respond to Eddy Quicksall 

      To:        [email-masked] 
      cc:        [email-masked] 
      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: [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: "Mallikarjun C." <[email-masked]>
Date: Tue, 11 Jun 2002 12:35:27 -0700

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
[email-masked]

---

From: "Amir Shalit" <[email-masked]>
Date: Tue, 11 Jun 2002 13:51:08 -0700

Mallikarjun,

The initiator can wait for all outstanding sequences to get acknowledged
prior to negotiating MaxPDUDataLength change. That will work well for
long-running commands and simplify target management.

Amir

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

Eddy,

Once the initiator starts the renegotiation, target would ideally want to
quickly

Mallikarjun Chadalapaka

---

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

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Mallikarjun C.
Sent: Tuesday, June 11, 2002 2:35 PM
To: Eddy Quicksall; Julian Satran
Cc: [email-masked]
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 -

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.

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 12 Jun 2002 10:57:34 -0700

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

----- Original Message -----
From: "Rod Harrison" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>; "Eddy Quicksall" <[email-masked]>; "Julian Satran"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 11, 2002 4:15 PM
Subject: RE: iSCSI: changing MaxPDUDataLength

---

From: "Rod Harrison" <[email-masked]>
Date: Wed, 12 Jun 2002 14:35:58 -0500

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Mallikarjun C.
Sent: Wednesday, June 12, 2002 12:58 PM
To: Rod Harrison
Cc: [email-masked]
Subject: Re: iSCSI: changing MaxPDUDataLength

Rod,

Mallikarjun Chadalapaka

----- Original Message -----
From: "Rod Harrison" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>; "Eddy Quicksall"
<[email-masked]>; "Julian Satran"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 11, 2002 4:15 PM
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
> > Another problem here is that the target has to calculate the
offset
> from the
> > I think it would be a performance hit and waist of memory to keep
a
> tally of
> > It's not that it can't be done ... it is more that it is messy and
I
> think
> > commands are finished (running with ErrorRecoveryLevel>=1). This
is
> because
> > So, I plan to not give the text response for a
MaxPDURecvDataLength
> in FFP
> > If one uses a message sync and steering that relys on the
transport
> segments
> > MTU changes one would want to change the PDU data length to fit
the
> new path
> > Does anybody know a case where it is necessary to support a new
PDU
> data

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 11 Jun 2002 12:35:27 -0700

Eddy,

Mallikarjun Chadalapaka

---

From: "Amir Shalit" <[email-masked]>
Date: Tue, 11 Jun 2002 13:51:08 -0700

Mallikarjun,

Amir

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

Eddy,

Mallikarjun Chadalapaka

---

From: "Amir Shalit" <[email-masked]>
Date: Tue, 11 Jun 2002 13:51:08 -0700

Mallikarjun,

Amir

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

Eddy,

Mallikarjun Chadalapaka