Subject: RE: question regarding retransmission

From: <[email-masked]>
Date: Wed, 23 Oct 2002 12:17:02 +0300

Hi Daisy and Qiaobing,

	I will comment first Daisy's mail, and then Qiaobing's...

>   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 

	Yes... you could have chosen t2 for the retransmission, but this is perfect as well...

	I also assume that all the TSNs are 1 MTU long, so you cannot retransmit more than one of them...

> 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 

	#1 is not marked for retransmission, so no way you do this...

> or 
>     Transmitted: 
>     t1: (#1, #2, #3) 
>     t2: (#1), #2 
>     t3: (#4) 
>     marked for retransmission:  #3. #4 

	This is what I would do... When t3 expires you mark #4 for retransmission and you issue a retransmission... But it happens that the oldest TSN marked for retransmission in #2, so you retransmit it... As #2 was last sent to t1, you can choose either t2 or t3...

	Again, I'm assuming that 1 TSN = 1 MTU... No matter which is the cwnd of the destination address, when retransmitting you send at most (and you are allowed to send at least) 1 MTU... Otherwise, you could bundle as many as you could in a single MTU of the destination address chosen for the retransmission...

> or 
>     Transmitted: 
>     t1: (#1, #2, #3) 
>     t2: (#1), #4 
>     t3: (#4) 
>     marked for retransmission:  #2, #3 
> or 

	I don't think that this is what you should do for the reasons I said above... Please note that this is just my suggestion (I cannot assure that I'm right :-)).

	(oops! I took a look to the RFC, and it seems that section 6.3.3 E3) says that you should precisely do this... Now I'm as confused as you, Daisy)

	And now about Qiaobing's comments...

> What your scenario depicts is a case of multiple time-outs. I think it
> would be hard (and may not worth the effort) to still try to keep the tx
> order of all the affected chunks under such circumstance (and it would
> also be fruitless even if you try, since it won't mean much to the
> arrival order at the receiver side). IMO, it'd be nice to maintain the
> order in such a case. but if it's too much effort for the impl to do
> that, then why bother...

	Well... yes and not... If the DATA chunks are unordered, there could be a difference... But most probably, if they are unordered, it doesn't matter anyway... :-/

	BR Iván Arias Rodríguez

---

From: Laurent Glaude <[email-masked]>
Date: Wed, 23 Oct 2002 09:26:53 -0400

That's also what I do. When I do retransmits, my first objective is to 
advance the cumulative TSN as fast as possible. I think it is the best 
and simplest approach : advancing the cumulative TSN makes you increase 
your cwnd, and reduces head-of-line blocking in the case where #1, #2, 
#3 and #4 are all on the same stream.

-Laurent

-- 
Laurent Glaude
Software Engineer, Performance Technologies
[email-masked] - http://www.pt.com

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 23 Oct 2002 13:37:58 -0500

Ivan,

In general I think you are interpretation the spec more restrictively
than it intends to be... which is of cause good for the network :-) See
my comments below...

...
> >     marked for retransmission:  #3. #4

First, you can not re-send #2 to t2, because there is no cwnd left on t2
after you re-sent #1 over it, right? 

In fact at the point, your cwnd status should be: t1/1 MTU; t2/none;
t3/1 MTU... You can choose to be conservative and not to use the
remaining 2 MTU quota the network allows you.. This of cause is fine. 

>         Again, I'm assuming that 1 TSN = 1 MTU... No matter which is the cwnd of the destination address, when retransmitting you send at most (and you are allowed to send at least) 1 MTU... Otherw…

This interpretation is very conservative, IMO.

>         (oops! I took a look to the RFC, and it seems that section 6.3.3 E3) says that you should precisely do this... Now I'm as confused as you, Daisy)

Obviously the wording there is not meant to address a double t-o event
like what we are talking about here :-) I probably will go for
re-sending #2 first (i.e. the *overall oldest* TSN marked for re-trans).
That makes better sense to me.

-Qiaobing