DataSN when MaxRecvDataSegmentLength changes

[Bill Studenmund <wrstuden@wasabisystems.com>]

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