Subject: iSCSI: changing MaxPDUDataLength

From: Eddy Quicksall <[email-masked]>
Date: Wed, 5 Jun 2002 15:23:58 -0400

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: [email-masked]
Date: Fri, 7 Jun 2002 11:12:30 -0600

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

Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Sat, 8 Jun 2002 15:54:33 -0400

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

Eddy

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 9 Jun 2002 05:16:26 +0300

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.

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

Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 10 Jun 2002 17:32:29 -0400

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

Julo 

06/08/2002 10:54 PM 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Jun 2002 03:05:36 +0300

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

06/11/2002 12:32 AM

        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.

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

Julo 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 10 Jun 2002 21:28:42 -0400

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

Julo 

06/11/2002 12:32 AM 

Julian, 

  
  
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

Julo 

06/08/2002 10:54 PM 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

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

I see a case where the target could still end up sending PDU's of different
lengths for a given command.

It would be much safer if the initiator was required to idle the commands
before sending the new MaxRecvDataSegmentLength. That way there is nothing
for the target to do other than change the size.

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 11:34 AM
To: [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High

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

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

---

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

I think that even the text I suggested is more than it is needed. Quiescing
the connection is not practical - many large box builder will find this
unacceptable and obviously an implementation can go away without it. As I
pointed out for retries you need only the offset at the change point and
anything that happens later require retransmission of everything from the
known point.

Julo

                      Eddy Quicksall                                                                                                       
                      <eddy_quicksall@i        To:       Julian Satran/Haifa/IBM@IBMIL, [email-masked]                                    
                      vivity.com>              cc:                                                                                         
                                               Subject:  RE: iSCSI: changing MaxPDUDataLength                                              
                      06/11/2002 08:56                                                                                                     
                      PM                                                                                                                   
                      Please respond to                                                                                                    
                      Eddy Quicksall                                                                                                       

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 11:34 AM
To: [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High

 Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM -----

                      Julian Satran

                                               To:      Eddy Quicksall

Julo

                      Eddy Quicksall

changing
MaxPDUDataLength
                      06/11/2002 04:28

                      AM

                      Please respond to

                      Eddy Quicksall

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

      Julo

   Eddy Quicksall

      Julian,

      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

      Julo

   Eddy Quicksall

      Thanks,

      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,

      Pat

      -----Original Message-----
      From: Eddy Quicksall [mailto:[email-masked]]
      Sent: Wednesday, June 05, 2002 12:24 PM
      To: [email-masked]
      Subject: iSCSI: changing MaxPDUDataLength

      Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Tue, 11 Jun 2002 19:58:39 -0400

The target would have to quiesc all data-outs anyway before sending the
response (or keep track of PDU sizes which is even worse). I believe this is
easier done at the initiator.

Also, why would one want to do so many PDU size changes that it would really
make a difference?

How are you going to get the offset if the PDU's changed size on you without
keeping track of PDU size changes?

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 5:17 PM
To: Eddy Quicksall
Cc: [email-masked]; Julian Satran
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High

Julo

                      Eddy Quicksall

                      <eddy_quicksall@i        To:       Julian
Satran/Haifa/IBM@IBMIL, [email-masked]                                    
                      vivity.com>              cc:

                      PM

                      Please respond to

                      Eddy Quicksall

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 11:34 AM
To: [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High

 Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM -----

                      Julian Satran

                                               To:      Eddy Quicksall

Julo

                      Eddy Quicksall

                      AM

                      Please respond to

                      Eddy Quicksall

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

      Julo

   Eddy Quicksall

      Julian,

      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

      Julo

   Eddy Quicksall

      Thanks,

      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,

      Pat

      -----Original Message-----
      From: Eddy Quicksall [mailto:[email-masked]]
      Sent: Wednesday, June 05, 2002 12:24 PM
      To: [email-masked]
      Subject: iSCSI: changing MaxPDUDataLength

      Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 12 Jun 2002 03:05:29 -0400

I just noticed something you said way below:

>>You are also implying that targets can declare their changed
>>MaxRecvDataSegmentLength anytime just for writes.

I didn't mean it that way. What I was saying was that when the target
changes his value, there are no messy logic issues involved; and therefore
there are no timing issues about when it changes.

Did you ever think about using an offset and a data length in the SNACK
instead of using PDU counters? That would also simplify things at the
target.

Eddy

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 7:46 PM
To: Mallikarjun C.; Julian Satran
Cc: [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength

Consider the following (using Julian's suggestion):

	-> cmd 1  
	-> req to change to length 2
	-> cmd 2

      <- stat 1
	<- data 2, PDU 0, Length 1

   	-> cmd 3, ack 1 so change the length
	
	<- data 2, PDU 1, Length 2

	-> SNACK data 2, PDU 1

So we have to calculate the offset for Data 2, PDU 1 using old length and
send data after that offset using new length. That means keeping track of
PDU lengths which I would like to avoid.

Or, the target would have to force idling of commands before it gives the
response to the change.

Can you suggest how this would be handled otherwise?

Eddy

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

Eddy,

I am not sure if you're agreeing with me or not... but let me add some
comments.

I don't expect the change in PDU size to happen frequently - no change
in what I earlier said.

You are making an assumption that a target must record the PDU size for
every
PDU  if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength.

As Julian earlier said, you don't have to.  I will not go into
implementation details, but
I believe just the value of the DataSN from which the new size is effective
should 
be all that's needed.  Besides, the spec guarantees that only RunLength=0 is
used 
on any SNACK after the change.

You are also implying that targets can declare their changed
MaxRecvDataSegmentLength
anytime just for writes.  There are two problems with this - a) reads and
writes may both
be active in the typical case on an iSCSI connection, and b) a target can
declare its changed
value only if an initiator is allowed to start the Text Request (and I
thought you were suggesting
that we explicitly disallow that).

Hope that clears it up.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

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

> You are correct and that is exactly how I have had to code it. With fast
> path and slow path code split between processors, it becomes even worse.
> 
> When I read your comments on why the PDU size could change (from way back
in
> March I think), I got did not get the impression that it would happen very
> often and that in fact it may only happen when you are maintaining
> allegiance to another connection.
> 
> If it is something that is not going to happen very often, then it would
be
> so much easier to have the initiator idle the commands first (all it
really
> needs to do is idle the READ commands). If it is going to change so often
> that idling would be degrading, I suspect that just doing the negotiation
> that often would itself be degrading.
> 
> And, be aware that the target will probably idle the R commands.
Otherwise,
> it will have to track PDU sizes and that would be really
> "counter-productive" (especially when there should be no SNACKs on a good
> connection anyway).
> 
> I don't see any problem with the target negotiating its size at any time.
> And the initiator would not have to idle the WRITE or no-data commands.
> 
> Eddy
> 
> From: Mallikarjun C. [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 3: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 -
> 
> "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]
> 
> 
> ----- Original Message ----- 
> From: "Eddy Quicksall" <[email-masked]>
> To: "Julian Satran" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, June 11, 2002 7:56 AM
> > 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
> > 
> > Sent: Tuesday, June 11, 2002 9:11 AM
> > To: Eddy Quicksall
> > 06/11/2002 04:28 AM 
> and

> the
tally
> of
think
outstanding
path

---

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

Rod,

It is clearly missing. I was thinking at something benign like using it an 
indication that target wants to negotiate.
Logout - inititaor is always free to use but it may want to issue a text.

Julo

"Rod Harrison" <[email-masked]>
06/12/2002 02:57 AM
Please respond to "Rod Harrison"

        To:     Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: iSCSI: changing MaxPDUDataLength

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

>  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

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

>                                                To:      Eddy
Quicksall
[email-masked]

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
Satran/Haifa/IBM@IBMIL
>                       vivity.com>              cc:
[email-masked],
[email-masked]
> unless it first idles the commands (at least the ones with the R
bit) or
if
>       after the ack! (no need to keep a tall - the old offsets are
good
up
>                                              cc:
[email-masked],
>       from the DataSN #. And as BegRun can be any value. E.g.,
BegRun=4
and
>       It's not that it can't be done ... it is more that it is messy
and
I
>                                             cc:
[email-masked]
>                                             Subject:        RE:
iSCSI:
>       carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then
if
the

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 12 Jun 2002 17:19:48 -0400

Mallikarjun,

This is not a case of arguing ... we are simply trying to understand each
others point over EMAIL, which is difficult at best. Please try to work with
me instead of against me. I could be wrong but I just need a little more
cooperation instead of using the overworked terms like "if you will just
read ...".

You went into enough detail in one EMAIL to show that it is a messy job.
When a solution is too messy and hard to explain, it is usually a clue that
something needs to be simplified ... and that is what I am after.

So far, I have not been able to catch the reason why we could not simply
specify that the initiator must idle the commands before issuing a new size.
Julian hinted that it would be a performance hit but I don't believe that
will be a performance hit because it should be rare. Please explain why it
would be a performance hit.

I would also like to know why the SNACK just doesn't simply ask for an
offset and a data length because that would simplify everything. Could you
please explain that?

You mention data-out below but I'm not talking about data-out, I'm talking
about data-in.

I don't know what this has to do with a long write. Can you please explain
that?

BTW, I don't have much background in ULPDU so maybe that is the key as to
why the initiator can't idle first. Can you please explain that?

In re-reading your statement below, I am wondering if you understand the
problem ... The problem is that when a SNACK is sent and the PDU sizes have
changed due to MaxPDUDataSegmentLength, then it puts a burden on the target
to compute the proper offset of the BegRun (a.k.a messy).

This is solved by the target in at least two ways:

1) The target can record the last PDU size when the change takes place. But
it would also have to keep track of the number of already completed PDU's
per outstanding command. This is because some commands may have missing
PDU's with the old size and others may have missing PDU's with the new size.
To make matters worse, some commands could have n PDUs already sent and
others could have m PDUs already sent. If you want, I could make up a
diagram of this and send it to you.

2) The target could "force an idle of data-in commands" (by queuing them)
before it responds to the change request. Doing this would probably be no
different than the initiator doing it but it would be easier and less
intrusive for the initiator to do it.

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 2:06 PM
To: Eddy Quicksall; Rod Harrison; Julian Satran
Cc: [email-masked]
Subject: Re: iSCSI: changing MaxPDUDataLength

I am afraid this thread is going in circles, let me respond to this message
before I rest my case on this topic.

> I think you have misunderstood something... I'm not suggesting that you
> mandate "no text negotiation till quiesced". I'm suggesting that only when
> Max length changes and then only for the READS. This suggestion is to
> simplify the logic you point out below.
> 
> What are the harmful effects you mention below?

As I earlier hinted twice, the Data-Out PDUs will not be ULPDU-contained
anymore - and that could mean target would need to spend more memory/bus
bandwidth/computation to deal with those till the long write is done. 

I do not understand your specific proposal yet.  If you're arguing that a
special case
be made for reads, a cogent, clear rationale for the special case, coupled
with the 
specifics of your proposal, would help the WG consider this further.  Based
on 
my current understanding of your position, I currently don't see the need
for the 
special case.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka

> Sent: Tuesday, June 11, 2002 8:54 PM
> I earlier said I will not get into implementation details, I will 
> however provide a generic answer.
> 
> Given that the changed PDU size is not specific to one command,
> I see the history of "past max PDU size(s)" as a connection attribute.  
> All you need on a per-task basis is really the value of one DataSN 
> *where* it had changed.
> 
> We could further debate how to deal with multiple number of PDU size 
> changes during the life of an I/O - but I'm reluctant to be involved in
that
> debate because a) it's most unlikely, and b) there's no hard requirement
> that 
> the target must always satisfy SNACKs under extreme conditions, and
finally
> c) it's too implementation-specific to be discussed on the ips reflector.
> 
> Finally, I'd like to remind you that mandating "no text negotiation till
> quiesced"
> has harmful effects on targets dealing with long writes and wanting ULPDU-
> containment - whose case you may be arguing.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Sent: Tuesday, June 11, 2002 4:45 PM
> > be all that's needed.  Besides, the spec guarantees that only
RunLength=0
> is
bit)
> or
> > > > since it should be rare to change it, it would be of little impact
to
> > > > I said only that when you change length you can ask for all PDUs
after
> from
> > > > there is a solution that will satisfy the design requirements but
keep
> > > > The only problem is when PDU size decreases and then SNACK must be
for
> > all
in
> > FFP
> new

---

From: [email-masked]
Date: Wed, 12 Jun 2002 15:14:50 -0600

Julian,

It is equally likely that a Target could run into a reason to change PDUsize
as for an Initiator. Therefore, I agree that there should be a way for the
target to request that the initiator open a FFP negotiation and an Async
message code is a good way to do that.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 2: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

[email-masked]

Satran/Haifa/IBM@IBMIL
Satran/Haifa/IBM@IBMIL
[email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Jun 2002 03:05:36 +0300

Julo

Julian,

 
 
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

Julo 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

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

Rod,

Julo

                 - 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

Quicksall
[email-masked]

Satran/Haifa/IBM@IBMIL
effect
(in
Satran/Haifa/IBM@IBMIL
[email-masked],
[email-masked]
bit) or
if
good
up
[email-masked],
BegRun=4
and
and
I
[email-masked]
if
the

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 10 Jun 2002 17:32:29 -0400

Julian,

 
 
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

Julo 

06/08/2002 10:54 PM 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

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

Mallikarjun,

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

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

[email-masked]

Satran/Haifa/IBM@IBMIL
Satran/Haifa/IBM@IBMIL
[email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 13 Jun 2002 22:08:48 +0300

Mallikarjun pointed that to me - so - using offset in SNACK is not a 
practical proposition because the offset is not known.
The initiator misses something - it does not know what; it knows only that 
it missed a number.

keeping track of any byte sent (scoreboarding) is not something easily 
doable in SCSI - where the target is the "transfer master".
I am a bit obscure but I assume that Eddy understands already.

Julo

"Mallikarjun C." <[email-masked]>
06/13/2002 09:57 PM
Please respond to "Mallikarjun C."

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc: 
        Subject:        Fw: iSCSI: changing MaxPDUDataLength

----- Original Message ----- 
From: "Eddy Quicksall" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>
Sent: Thursday, June 13, 2002 4:51 AM
Subject: RE: iSCSI: changing MaxPDUDataLength

> I thought I always said that data-in was the issue. If I didn't make 
that
> clear, I apologize.
> 
> If there is no reason other than making a point and keeping consistency, 
can
> you please talk over the likelihood of using an offset and data length
> instead of BegRun and RunLength? If that were done, the target would not
> have any issues to deal with.
> 
> 
> Yes, this is one thing I've been driving at. If hardware is 
independently
> handling the transmission, it is likely in a loop sending PDU's with
> MaxPDUDataSegmentLength. The firmware would have to pause the hardware; 
then
> go to each TCB and record the current DataSN; then inform the hardware 
of
> the new Length; then unpause the hardware. On most pieces of hardware 
I've
> seen in the past with a pause feature, there has always been some sort 
of
> oversight and a lot of ugly work around code had to be written.
> 
> If there are different processors used (one for the fast path and one 
for
> the slow path), then coordination between the processors has to take 
place
> also.
> 
> In hardware, it is not uncommon to keep the TCBs in very fast memory. 
That
> type of design usually has a limit on memory because it is usually on 
chip.
> Now, to ask for an extra DWORD in every TCB for something that is 99% of 
the
> time unused is almost unheard of. If that DWORD were in external memory 
then
> there would likely have to be code that touches that memory each time a 
TCB
> is started (or finished).
> 
> You're pseudo code below has a slight flaw. Since, in a single TCB, some
> PDU's may have been transmitted with the old size and some with the new 
size
> and then a BegRun is some number of PDU's into the new size, you have to
> also use the new size and number of PDU's into the new size in your
> calculation. Not difficult code but just adds to the messiness that I 
would
> like to avoid.
> 
> I've mentioned four things here that account for why I said it is messy. 
I
> never tried to say its not doable or conceptually simple.
> 
> Can you please consider using an offset?
> 
> 
> 
> Eddy
> 
> From: Mallikarjun C. [  <mailto:[email-masked]> mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 9:03 PM
> To: Eddy Quicksall
> Comments inline, I think it's best to take it off the list (at least for 
a
> while).
> 
> Caveat: I am *still* not clear on the specifics you have in mind.  You
> talked
> about quiescing the commands, then data, then only read commands....
> 
> I have to apologize, but I am afraid I can't spend my cycles any further 
on
> this thread.
> To: "Mallikarjun C." <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 12, 2002 2:19 PM
> > others point over EMAIL, which is difficult at best. Please try to 
work
> with
> > me instead of against me.
> 
> I am fairly oblivious to the person arguing an issue, it's the issue and 
its
> consequences that matter to me.
> 
> >I could be wrong but I just need a little more
> Which I didn't say...
> I can't explain what others said, but my point is that changing the PDU 
size
> in the middle of the I/O *does not have to* cause the explosion of 
metadata
> that you were fearing.
> I think to make the point that data retransmission requests can only be 
made
> at the PDU level, and also to be consistent with other types of SNACK
> (status,
> data ACK).
> 
> >
> But they may be related!  Here's what I said earlier -
>  "a) reads and writes may both be active in the typical case on an iSCSI
> connection,"
> I thought you were coming up with a rule that affects initiator iSCSI
> layer's ability to quickly
> react to PMTU changes.  If so, it would impact both reads and writes.
> 
> >
> ULPDU means "ULP PDU" - ULP from the perspective of the framing layer.
> Please refer TUF draft for details.
> 
> >
> I already explained this.....
>  " As I earlier hinted twice, the Data-Out PDUs will not be 
ULPDU-contained
>   bandwidth/computation to deal with those till the long write is done. 
"
> > problem ...
> Yes, I do.
> >The problem is that when a SNACK is sent and the PDU sizes have
> > 1) The target can record the last PDU size when the change takes 
place.
> But
> Not necessary.  I assume you're referring to read commands.  I already
> answered this - "Given that the changed PDU size is not specific to one
> command, I see the history of "past max PDU size(s)" as a connection
> attribute.  All you need on a per-task basis is really the value of one
> DataSN
> *where* it had changed." [ Assume that this is a TCB element called
> "PDU_size_changed_at". ]
> 
> Thinking about all permutations could be distracting.  All you want is
> "given a
> DataSN, translate it to a data offset without maintaining 
DataSN->PDU_size
> records for each past PDU you had earlier sent".  That should be quite
> doable
> with what I described
> 
> if (TCB.PDU_size_changed_at is invalid) {
>              Offset = SNACK.BegRun*Connection.PDU_size;
> } else {
>              Compute the offset based on whether BegRun is before or 
after
>              TCB.PDU_size_changed_at.  Use Connection.Previous_PDU_size.
> }
> 
>  The "if" condition computes to "true" 99% of the time.
> 
> This is as explicit as I can be.....
> 
> >

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 10 Jun 2002 17:32:29 -0400

Julian,

 
 
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

Julo 

06/08/2002 10:54 PM 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

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

Julo 

06/11/2002 04:28 AM 

  

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

Julo 

06/11/2002 12:32 AM 

Julian, 

 
 
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

Julo 

06/08/2002 10:54 PM 

Thanks,

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,

Pat

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
Subject: iSCSI: changing MaxPDUDataLength

Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Tue, 11 Jun 2002 19:45:31 -0400

-> cmd 1  

      <- stat 1

	-> SNACK data 2, PDU 1

Eddy

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

Eddy,

Hope that clears it up.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message ----- 
From: "Eddy Quicksall" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>; "Julian Satran"

in
be
really
Otherwise,
particular).
idle

tally
think
outstanding
path

---

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

Julo

                      Eddy Quicksall                                                                                                       

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 11:34 AM
To: [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High

 Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM -----

                      Julian Satran

                                               To:      Eddy Quicksall

Julo

                      Eddy Quicksall

                      AM

                      Please respond to

                      Eddy Quicksall

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

      Julo

   Eddy Quicksall

      Julian,

      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

      Julo

   Eddy Quicksall

      Thanks,

      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,

      Pat

      -----Original Message-----
      From: Eddy Quicksall [mailto:[email-masked]]
      Sent: Wednesday, June 05, 2002 12:24 PM
      To: [email-masked]
      Subject: iSCSI: changing MaxPDUDataLength

      Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Tue, 11 Jun 2002 18:18:00 -0400

When I read your comments on why the PDU size could change (from way back in
March I think), I got did not get the impression that it would happen very
often and that in fact it may only happen when you are maintaining
allegiance to another connection.

If it is something that is not going to happen very often, then it would be
so much easier to have the initiator idle the commands first (all it really
needs to do is idle the READ commands). If it is going to change so often
that idling would be degrading, I suspect that just doing the negotiation
that often would itself be degrading.

And, be aware that the target will probably idle the R commands. Otherwise,
it will have to track PDU sizes and that would be really
"counter-productive" (especially when there should be no SNACKs on a good
connection anyway).

Eddy

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

Eddy,

degradation in the presence of long-running commands (writes in particular).

Mallikarjun Chadalapaka

----- Original Message ----- 
From: "Eddy Quicksall" <[email-masked]>
To: "Julian Satran" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 11, 2002 7:56 AM
Subject: RE: iSCSI: changing MaxPDUDataLength

and
the
of
because
segments
path

---

From: Eddy Quicksall <[email-masked]>
Date: Tue, 11 Jun 2002 19:45:31 -0400

-> cmd 1  

      <- stat 1

	-> SNACK data 2, PDU 1

Eddy

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

Eddy,

Hope that clears it up.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message ----- 
From: "Eddy Quicksall" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>; "Julian Satran"

in
be
really
Otherwise,
particular).
idle

tally
think
outstanding
path

---

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

Julo

                      Eddy Quicksall                                                                                                       

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 11:34 AM
To: [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High

 Julo
----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM -----

                      Julian Satran

                                               To:      Eddy Quicksall

Julo

                      Eddy Quicksall

                      AM

                      Please respond to

                      Eddy Quicksall

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

      Julo

   Eddy Quicksall

      Julian,

      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

      Julo

   Eddy Quicksall

      Thanks,

      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,

      Pat

      -----Original Message-----
      From: Eddy Quicksall [mailto:[email-masked]]
      Sent: Wednesday, June 05, 2002 12:24 PM
      To: [email-masked]
      Subject: iSCSI: changing MaxPDUDataLength

      Eddy

---

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

Mallikarjun,

Julo

                      "Mallikarjun C."                                                                                                     

                      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

[email-masked]

Satran/Haifa/IBM@IBMIL
Satran/Haifa/IBM@IBMIL
[email-masked]