Subject: RE: question regarding retransmission

From: "Mohammed Ashraf" <[email-masked]>
Date: Wed, 23 Oct 2002 09:17:59 +0530

Isn't always better to maintain the order while retransmiting also. Since it
helps to dequeue chunks from the sender Q fastly(otherwise it may result in 
blocking at the sender side )

-----Original Message-----
From:	Qiaobing Xie [mailto:[email-masked]]
Sent:	Wed 10/23/2002 5:20 AM
To:	Daisy Chang
Cc:	[email-masked]
Subject:	Re: question regarding retransmission

....
> Thanks, Qiaobing.  This is very good information for me.
> 
> Based on your answer, may I say that, different chunks might be
> retransmitted at different transport depends on the choices of the
> outgoing transport at the time, and since the choices of the outgoing
> transport for retransmission is up to the implementation, there is
> really not a definite sequence of chunks being mandated by the RFC for
> retransmission? I am not implying anything like retransmitting chunks
> in random order, on the contrary, my case is that we are considering
> retransmitting chunks always in the same order, regardless the choice
> of the transport.

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...

> That is, back to  the example, at the time of t3
> timeout, we will queue #4 behind #2 and #3, and possibly send out #2
> either on t1 or t2, regardless which we end up picking.  This is OK,
> isn't it?

I believe so, as far as you always obey the cwnd rules. Also see below.

> 
> One more thing, in your description,  you said "if you pick t2 (as you
> seem to prefer), you will have to queue #4 behind #2 and #3, since you
> don't have any quato left on t2 since t2 is still under the 'max one
> chunk of upto MTU in flight allowed' mode", could you explain how t2
> got into this mode?  

My mistake, when I wrote that I was thinking wrongly that t2 was the one
that got timed-out. But the fact that you didn't rtx #2 and #3 along
with #1 indicates that you ran out of cwnd on t2. So, if you insist to
picking t2 for rtx #4, you have to queue it after #2 and #3.

You basically have a case where you have more data marked for rtx than
the cwnd of one dest addr allows and at the same time you have other
dest addresses in the association that still have cwnd room available.
My question to you is why keeping yourself from using the available cwnd
on those alternate dest addresses to re-send the rest of the data? I
don't think the spec prohibit that. It's up to the impl.

> If we assume that, this example begins with all
> three transports' cwnd up to, let's say, 4 * MTU at the moment,  do
> you think that t2 would still end up in this mode given the sequence
> of events?
> 
> Best Regards
> Daisy
> 
> >
> > > 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
> 
>

---

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

> blocking at the sender side )

Sure, if the impl feels that is convenient to do..