SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: DataSN when MaxRecvDataSegmentLength changes



    I figured DataSN would start at 16 for both Q1 and Q2. Also, the target must
    transfer all of the remaining data, not just the sequence.
    
    To add another twist, if the MaxRecvDataSegmentLength went into effect
    (i.e., when you gave the response) before DataSN 16, then the
    re-transmission is not the "2nd 128k", it is something more than that.
    
    Eddy
    
    -----Original Message-----
    From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
    Sent: Friday, June 21, 2002 7:23 PM
    To: ips@ece.cmu.edu
    Subject: DataSN when MaxRecvDataSegmentLength changes
    
    
    I have a question about SNACK data retransmits in this case.
    
    As I understand it, the initiator isn't supposed to ask for specific PDUs
    (run count != 0) if MaxRecvDataSegmentLength has changed, as it's not
    certain to be feasable to transmit them again (i.e. they won't fit inside
    MaxRecvDataSegmentLength anymore). It can though ask for them by a
    specific number.
    
    My question is what DataSN should the target give to these new packets?
    
    Here's the scenario:
    
    MaxBurstLength is 256k, MaxRecvDataSegmentLength starts at 8k. I send a
    burst. I give it DataSN 0 through 31. I send the packets.
    
    Then I notice that the Initiator has negotiated (declared)
    MaxRecvDataSegmentLength down to 4k. Ok.
    
    At some point after it negotiated the size down, the initiator figured out
    it missed DataSN 16.
    
    ** Q1: Because the intitiator changed MaxRecvDataSegmentLength, whether or
    not it gets DataSN 17 doesn't matter. It has to ask for from 16 on.
    Correct?
    
    So now I know the initiator wants the second 128k again. What DataSNs do I
    use? 32 through 63? 32 is the next one I have available and it'll take 32
    PDUs to cover it.
    
    ** Q2: Let's make the case a little sicker.
    
    I sent the first MaxBurstSize burst (DataSN 0 -> 31), noted the
    MaxRecvDataSegmentLength change, then sent another burst with DataSN 32
    ->95. Only *then* did I notice that DataSN 16 needs to be resent. This
    might happen with a large time-bandwidth-product connection.
    
    So then I have to send the 128k from the first burst and the full 256 from
    the second burst all over, don't I? And I'll need DataSN 96->195, corect?
    
    Thanks!
    
    Take care,
    
    Bill
    


Home

Last updated: Mon Jun 24 15:18:53 2002
10960 messages in chronological order