Subject: [Fwd: question regarding retransmission]

From: Daisy Chang <[email-masked]>
Date: Tue, 22 Oct 2002 15:14:24 -0500

Hi,
    Sorry to post this again. I would like to update my illustrations,
hopefully, to make the question clearer for you. The scenario is the
same, but I would like to show the sequence of outgoing chunks, per
transport/path, a little better by putting the previously transmitted
chunks in (), followed by newly transmitted chunks as a result of the
events described in the scenario.

So, we begin with
  Transmitted:
    t1: #1, #2, #3
    t2: nothing
    t3: #4

If t1 times out, we expect
  Transmitted:
    t1: (#1, #2, #3)
    t2: #1
    t3: (#4)
    marked for retransmission: #2, #3

Now, if t3 times out next, which one is expected to happen?
Transmitted:
    t1: (#1. #2, #3)
    t2: (#1), #1
    t3: (#4)
    marked for retransmission: #2, #3. #4
or
    Transmitted:
    t1: (#1, #2, #3)
    t2: (#1), #2
    t3: (#4)
    marked for retransmission:  #3. #4
or
    Transmitted:
    t1: (#1, #2, #3)
    t2: (#1), #4
    t3: (#4)
    marked for retransmission:  #2, #3
or
    something else???

    Any of your responses is greatly appreciated!

Best Regards,
Daisy

Daisy Chang wrote:

>  Hi,
>     I was looking to fix a problem in our SCTP retransmission code and
> had a confusion on the following scenario. I would like to clear it up
> and make sure that we will do it right.  The confusion is about
> retransmission under the circumstances of outstanding chunks eligible
> for retransmit (residuals from previous T3rtx timeout) and data on
> multiple transports in an association.
>
>     The scenario:
>     If there are 3 transports - t1, t2, t3. Where t1 is the primary
> path, and t2 is the first choice for doing any retransmission with.
> Assuming that chunks with TSN #1, #2, and #3 have been transmitted
> thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER
> flag on and destined to be sent thru t3.   Also, assuming that t1, t2,
> t3 have the same MTU sizes, and that each chunk would fit in the MTU
> just right.  So,
>   Transmitted:
>     t1: #1, #2, #3
>     t2: nothing
>     t3: #4
>
> With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked
> for retramission but only #1 would be sent out due to the MTU
> constraint (RFC 2960 6.3 E3).  So we will end up with
>     Transmitted:
>     t1: nothing
>     t2: #1
>     t3: #4
>     marked for retransmission: #2, #3
>
> Next, if t3's T3-rtx timer pops, a retransmission needs to be made
> again thru t2, which chunk should be sent out?   Is it #1, or #2 or
> even #4?  In other words, which one of the following would be the
> result of this timeout? Is it
>
>     Transmitted:
>     t1: nothing
>     t2: #1 (again)
>     t3: nothing
>     marked for retransmission: #2, #3. #4
> or
>     Transmitted:
>     t1: nothing
>     t2: #1, #2
>     t3: nothing
>     marked for retransmission:  #3. #4
> or
>     Transmitted:
>     t1: nothing
>     t2: #1, #4
>     t3: nothing
>     marked for retransmission:  #2, #3
>
>
>
> --
>
> Thanks,
> Daisy
>
> +--------------------------------------------------------------------------+
> Daisy Chang                     IBM Linux Technology Center
> e-mail: [email-masked]
> Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663
> 11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
>
>

--

Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center
e-mail: [email-masked]
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493