Subject: RE: question regarding retransmission

From: <[email-masked]>
Date: Thu, 24 Oct 2002 15:11:21 +0300

Aha... alright, now I'm completely lost... :-)

	I have always thought exactly this "why putting a limitation in the number of packets after a retransmission, other than the cwnd of the new destination address (and rwnd)?"... I simply didn't understand why... And I have always gotten the answer "we are dealing with multihomed peers, something new in the internet, and we have to be conservative. Besides, depending on your configuration, it is likely that even if the destination address is different, most of the network path is shared"... :-0

	And now, what?

	If the idea is as Qiaobing says, then definitely the RFC is wrong. Because it clearly states that you send "one and only one" no matter where to... And this is what I have always done (internally thinking at the same time that it wasn't the best option, but...), because it has been what people have told me to do... :-/ And actually it was much easier coding it the other way (Qiaobing's)...

	Any more comments from some more people?

	I think this is not really something internal to the implementation but really an SCTP issue... I will send it also to the TSVWG (however, lacking the previous mails I don't know if they are going to understand much)...

	Thanks!

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Qiaobing Xie [mailto:[email-masked]]
> Sent: 23. October 2002 21:38
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: question regarding retransmission
> 
> 
> 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...
> 
> ...
> > >     Transmitted:
> > >     t1: (#1, #2, #3)
> > >     t2: (#1), #2
> > >     t3: (#4)
> > >     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... Otherwise, you could bundle as many as you 
> could in a single MTU of the destination address chosen for 
> the retransmission...
> > 
> 
> This interpretation is very conservative, IMO.
> 
> > > 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)
> > 
> 
> 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
> 
>