SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Target record not to span PDUs?



    Julian,
    
    Not to be pedantic, but, again, the arbitrary decision to avoid the
    concatenation adds burden to the target side and restricts the future
    capability of key=values that exceed the max text PDU length.
    
    Again, the host side will need to buffer the input until it has all arrived
    anyway.  Is there a stronger technical reason for this other than the
    avoidance of concatenation?
    
    The approach you propose adds processing burden to every action on a target
    side to put a key=action into a PDU.  I envision the target side having
    contiguous memory to formulate the entire text response, and it then sends
    this in sequential PDUs.  Having to search for where a key=value pair spans
    the PDU boundary is work.
    
    Furthermore, being able to span PDUs facilitates a simpler specification.
    
    Maybe Tow can explain the burden of concatenation.  If Tow really doesn't
    care, can we go back to allowing the records to span PDUs?
    
    Does anyone else care about this?
    
    Stephen
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Thursday, August 23, 2001 2:01 PM
    To: ips@ece.cmu.edu
    Subject: RE: Target record not to span PDUs?
    
    
    
    Bob,
    
    The record in question is a key=value pair. What Tow was asking is a about
    a way to avoid having to "concatenate
    strings" from two Text responses that carry the SendTargets answers one
    after another and we have stated that
    explicitly now.
    
    Julo
    
    Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18
    
    Please respond to Robert Snively <rsnively@Brocade.COM>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
    cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
    Subject:  RE: Target record not to span PDUs?
    
    
    
    It sounds like there may be some confusion between "physical
    data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
    (the messaging unit for iSCSI).  I cannot see where Tom's
    problem arises, since Protocol Data Units are very well
    behaved and should not have the problems he is discussing.
    You cannot complete Protocol Data Unit processing until you
    know you have all of them and that useful information does not
    span them.  The assembly of protocol data units into useful
    complete messages should be done at a layer below that where
    you interpret the contiguous bytes of data in the context of
    the complete messages.  I think as a general rule that any
    iSCSI action should be able to span PDUs, including the
    Target Record.
    
    Bob
    
    > -----Original Message-----
    > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
    > Sent: Tuesday, August 21, 2001 7:07 PM
    > To: 'Julian Satran'
    > Cc: 'ips@ece.cmu.edu'
    > Subject: Target record not to span PDUs?
    >
    >
    > Julian (and all):
    >
    > Hello. This is regarding draft 07; could we require that
    > target records NOT span across
    > PDU's if a text response for SendTargets is very long? Upon
    > reading appendix E, it seems
    > that a response (of 4096 bytes in length) could end with:
    >
    > [Begin data segment]
    > ...
    > TargetName=I.got.chopped.4096
    > TargetAddress=10.1.1.45
    > [End data segment]
    >
    > In the above case, one could not determine whether the
    > address is IP V4 or V6. Even if it
    > had had enough space to put in the whole address, port and
    > group tag, one cannot parse and
    > process the record until inspecting the data segment of the
    > next text response PDU, and
    > this would involve cumulative buffering, back-parsing, etc. I
    > think the above complexity
    > could be avoided, as I can't imagine any single record
    > exceeding 4096 bytes in length.
    >
    > Tow Wang
    >
    >
    
    
    


Home

Last updated: Tue Sep 04 01:03:55 2001
6315 messages in chronological order