RE: iscsi : DataPDULength can differ in each direction.

["Julian Satran" <Julian_Satran@il.ibm.com>]

Rod,

Actually you bring up a valid point.  The length different in the two directions is perhaps the less important feature in the floated proposal.  However it stressed (once again) that we need a more flexible PDUlength scheme:

• that should allow dynamic changes (some of the framing schemes proposed will require that)
• that can be different on different connections
  
  
  Having it different on the two directions is a slight side effect that can be beneficial and comes at zero price once you have done the former.
  
  And the I think that it can be done with minimal disruption (very little code and this only if you implement ErrorLevel 1 and 2).
  
  Julo
  
  
  

  "Rod Harrison" <rod.harrison@windriver.com> Sent by: owner-ips@ece.cmu.edu 07-10-01 22:22 Please respond to "Rod Harrison"

  To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>         cc:                 Subject:        RE: iscsi : DataPDULength can differ in each direction.

  
  
  Julian and all,
  
     Before you go ahead and spend time and energy on this I would just
  like to re-iterate my concerns that in practice few, if any,
  implementations will support asymmetric PDU sizes.
  
                  If, for example, a software initiator indicates a max PDU size of
  128k and a hardware target indicates 8k, do we really think the target
  will ever send a 128k PDU? I don't believe it will. The supporting
  argument seems to be predicated on the fact that the buffer management
  changes needed to make this happen are trivial. However, if an
  implementation can chain buffers together on transmit to build PDUs
  larger than the maximum size offered why can't it do so on receive?
  And if it can do so on receive why would it ever offer a maximum lower
  than the real maximum it can support?
  
                  As an aside, I think this change might create something of a headache
  for sniffers since they now have to buffer the larger of the offered
  sizes instead of the smaller.
  
                  I agree that asymmetric PDU sizes seem beneficial but I have a very
  hard time believing we'll see any implementations that can take
  advantage of this feature. I also think the benefit might be
  relatively small and is probably not worth the level of spec change at
  this late stage.
  
                  - Rod
  
  
  -----Original Message-----
  From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
  Julian Satran
  Sent: Saturday, October 06, 2001 8:04 PM
  To: ips@ece.cmu.edu
  Subject: RE: iscsi : DataPDULength can differ in each direction.
  
  
  
  As I said this requested change has value and we are going to do our
  best to incorporate it in 09.
  
  Fortunately PDUlength has few dependencies in the protocol.
  
  Unfortunately (as I said already) we would like PDUlength to a be a
  per connection parameter as it is it closely related to the Path MTU.
  
  This later assumption may require some changes in the recovery
  mechanism (the current recovery mechanism assumes that any PDU can be
  "replayed" as it was on every connection and this assumption won't
  hold anymore).
  
  Mallikarjun and myself will attempt to get a better understanding of
  the things required and will keep you updated.
  
  I think we have enough information to work on it and we will keep the
  list updated on what we think can be done and how.
  
  We have several alternatives and would appreciate some timeout on this
  thread.
  
  Julo