Subject: Re: [Tsvwg] RE: question regarding retransmission

From: "Daisy Chang" <[email-masked]>
Date: Thu, 24 Oct 2002 11:14:25 -0500

Ivan,
      I definitely would say that the RFC could be clearer on this.   The
wording in
RFC2960  6.3.3 (E3) is very misleading:

"E3) Determine how many of the earliest (i.e., lowest TSN) outstanding

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       DATA chunks for the address for which the T3-rtx has expired will
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       fit into a single packet, subject to the MTU constraint for the
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       path corresponding to the destination transport address to which
       the retransmission is being sent (this may be different from the
       address for which the timer expires [see Section 6.4]).  Call
       this value K.  Bundle and retransmit those K DATA chunks in a
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       single packet to the destination endpoint."
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      From Qiaobing's answers to my question, I drew these conclusions myself,
1.  The definition of "the earliest (i.e., lowest TSN) outstanding DATA chunks for the address
for which T3-rtx has expired" is up to the implementation.  With multiple transports, if the earliest
outstanding DATA chunks were marked for retransmission due to timer expirations for other
transports, they are certainly eligible to be taken into consideration.
2.  The retransmission size is not limited to one packet (1 MTU). Implementations could
retransmit up to what the cwnd of the outgoing transport would allow.

      If I didn't interpret Qiaobing's answers wrongly, I believe that this probably merits an
amendment  to implementator's guide to prevent people from having the same confusions
that I have.

Thanks,
Daisy Chang
IBM Linux Technology Center
[email-masked]
Tel: (512)-838-4194    T/L: 678-4194
FAX: (512)-838-4663

[email-masked]@ietf.org on 10/24/2002 07:11:21 AM

Sent by:    [email-masked]

To:    <[email-masked]>
cc:    [email-masked], <[email-masked]>,
       <[email-masked]>
Subject:    [Tsvwg] RE: question regarding retransmission

             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
>
>
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Oct 2002 14:22:52 -0500

Hi, Ivan and Daisy,

I disagree with you here. I think the RFC is well written. What you
might have not paid enough attention to is the text above the rules you
are now focusing on. 

When reading the detailed CC rules in chapter 7, one MUST keep in mind
the assumptions made in 7.1 (Lixia and Vern please correct me if my
memory is faulty here, you two are the owner of the text in 7). 

In particular: 

     "The sender usually uses the same destination address..." 
and 
     "The sender keeps a separate congestion control parameter set 
     for each of the destination addresses..." 

**The CC rules that follow are narrated under this "same dest addr"
assumptions** 

And multi-homed peer is dealt with in the first bullet in 7.1: 
      "...(keep using the same dest addr) until being instructed 
      by the upper layer otherwise; however, SCTP may change
      to an alternate destination in the event an address is marked
      inactive (see Section 8.2).  Also, SCTP may retransmit to a
      different transport address than the original transmission"

This lays out the three cases where a diff dest addr may become
involved. And the second assumption in 7.1 makes it perfectly clear that
this second dest addr, when becoming involved, will bring its **own** CC
param and (implied) status.

Now, to answer Ivan's question, let me ask you a question, when your
dest addr t3 timed out and its CC status changed accordingly, why do you
want to modify t2 and t1's CC status as well? (remember, applying "no
more than one packet in-flight" globally constitutes a change of CC
status of every dest address)

-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Oct 2002 14:48:27 -0500

....
> status of every dest address)

BTW, as I said before, there is nothing wrong if an impl chooses to
apply "no more than one packet in-flight" globally after a t-o on any
dest addr. This is just be more conservative and the RFC specifically
says in 7 that:

   IMPLEMENTATION NOTE: As far as its specific performance requirements
   are met, an implementation is always allowed to adopt a more
   conservative congestion control algorithm than the one defined below.

So the comments you heard before that this is the right thing to do is
always valid.

-Qiaobing