SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI - changes - PDULength and related



    Excerpt of message (sent 21 October 2001) by Julian Satran:
    > Some framing mechanisms (defined by other standards) work well with PDU
    > length not exceeding path MTU.
    > This may be suboptimal (and I assume will be seldomness in use) but may
    > help get things going.
    
    I don't see how that is relevant.
    
    Path MTUs below 512 have always been extremely rare and certainly are
    completely nonexistent for high speed networks.  It makes no sense at
    all to add complexity to all implementations for the sake of
    supporting unreasonable path MTU values.  Especially if the only
    effect is that the framing doesn't work as efficiently -- but still
    works.  After all, if your path MTU is tiny, nothing works
    efficiently, and any optimization is a complete waste of effort.
    
    There is another issue here as well: it is not appropriate for such
    changes to be made without discussion.  I don't see a reason for the
    change, but if the consensus is that the change is desirable, then it
    should be made.  But it should NOT be made without discussion, as an
    obscure side effect of an unrelated change!  That way you cannot
    arrive at a stable spec.
    
           paul
    
    >                     Paul Koning
    >                     <pkoning@jlc.n       To:     Julian Satran/Haifa/IBM@IBMIL
    >
    > Excerpt of message (sent 12 October 2001) by Julian Satran:
    > > ...
    > > In addition text request and response key+value strings are not required
    > to
    > > be confined to a single PDU (as we PDULength can be a low as 64 bytes!)
    > >
    > > Comments?
    >
    > Why change the minimum value of PDULength (and the two burstsize
    > parameters)?  It used to be 512, which makes more sense, although even
    > that is rather small.  Allowing the length to be set to such tiny
    > values (like 64) adds a lot of complexity to the implementation to no
    > useful purpose.
    >
    > I'd prefer to see a minimum around 1500, but if not, at least it
    > should not be reduced from the existing value of 512.
    >
    >        paul
    >
    > > ...
    > > 23 MaxRecvPDULength
    > >
    > > Use: All
    > > Who can send: Initiator and Target
    > >
    > > MaxRecvPDULength=<0|number-64-to-2**24>
    > > ...
    > > 24 MaxBurstSize
    > >
    > > Use: LO
    > > Who can send: Initiator and Target
    > >
    > > MaxBurstSize=<0|number-64-to-2**24>
    > >
    > > Default is 256 Kbytes.
    > >
    > > Initiator and target negotiate maximum SCSI data payload in bytes
    > > ...
    > > 25 FirstBurstSize
    > >
    > > Use: LO
    > > Who can send: Initiator and Target
    > >
    > > FirstBurstSize=<0|number-64-to-2**24>
    >
    >
    > ----- Forwarded by Julian Satran/Haifa/IBM on 20-10-01 23:58 -----
    >
    >                     Paul Koning
    >                     <ni1d@arrl.net       To:     ips@ece.cmu.edu
    >                     >                    cc:
    >                     Sent by:             Subject:     Re: iSCSI - changes - PDULength
    >                     owner-ips@ece.        and related
    >                     cmu.edu
    >
    >
    >                     18-10-01 17:54
    >                     Please respond
    >                     to Paul Koning
    >
    >
    >
    >
    >
    > (((resending this, since the previous copy seems to have gone AWOL)))
    >
    > Excerpt of message (sent 12 October 2001) by Julian Satran:
    > > ...
    > > In addition text request and response key+value strings are not required
    > to
    > > be confined to a single PDU (as we PDULength can be a low as 64 bytes!)
    > >
    > > Comments?
    >
    > Why change the minimum value of PDULength (and the two burstsize
    > parameters)?  It used to be 512, which makes more sense, although even
    > that is rather small.  Allowing the length to be set to such tiny
    > values (like 64) adds a lot of complexity to the implementation to no
    > useful purpose.
    >
    > I'd prefer to see a minimum around 1500, but if not, at least it
    > should not be reduced from the existing value of 512.
    >
    >        paul
    >
    > > ...
    > > 23 MaxRecvPDULength
    > >
    > > Use: All
    > > Who can send: Initiator and Target
    > >
    > > MaxRecvPDULength=<0|number-64-to-2**24>
    > > ...
    > > 24 MaxBurstSize
    > >
    > > Use: LO
    > > Who can send: Initiator and Target
    > >
    > > MaxBurstSize=<0|number-64-to-2**24>
    > >
    > > Default is 256 Kbytes.
    > >
    > > Initiator and target negotiate maximum SCSI data payload in bytes
    > > ...
    > > 25 FirstBurstSize
    > >
    > > Use: LO
    > > Who can send: Initiator and Target
    > >
    > > FirstBurstSize=<0|number-64-to-2**24>
    >
    >
    >
    
    


Home

Last updated: Mon Oct 22 15:17:28 2001
7329 messages in chronological order