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

From: [email-masked]
Date: Thu, 24 Oct 2002 22:50:55 +0300

Qiaobing,

	I don't want to change the CC state of any other address but the one whose T3 expired... However, the E3) subsection of 6.3.3 leaves completely clear, in my opinion, than only one packet should be sent regarding this retransmission... And it even says that you send the TSN that were in flight when T3 expired, without taking into account that there could be some older TSNs still marked for retransmission due to, for example, fast retransmit...

	I see your point that nothing will stop me later to send more data... Yes, supposing I have two addresses t1 and t2, if T3 for t1 expires, I resend one TSN to t2. If right after that, the user gives me more data to send to t2, of course I will do it as far as cwnd allows...

	However, the statement in that section is really confusing... Well, from my point of view it clearly states a different thing than Qiaobing's interpretation... It says, send "a single packet"... In the normal case with two addresses and using one as primary, if T3 expires on t1 while have a lot of TSN in flight, then what Qiaobing says is that we should send 2*MTU worth of data (assuming t2 is in idle state), i.e., two packets, instead of one...

	The problem in my opinion, is that parts of the RFC are written thinking in a "classical" host (single homed), while some others do really take into account multihoming... This makes that some paragraphs are confusing...

	Is the general opinion here that only cwnd should limit? (this really makes sense for me but it is not what the RFC says).

	Thanks for your comments Daisy and Qiaobing!

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Qiaobing Xie [mailto:[email-masked]]
> Sent: 24. October 2002 22:23
> To: Daisy Chang
> Cc: Arias-Rodriguez Ivan (NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] RE: question regarding retransmission
> 
> 
> 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
> 
> Daisy Chang wrote:
> > 
> > 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
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 24 Oct 2002 15:07:04 -0500

...
>         The problem in my opinion, is that parts of the RFC are 
> written thinking in a "classical" host (single homed), while some 
> others do really take into account multihoming... This makes that 
> some paragraphs are confusing...

This is the key to read the CC rules in RFC2960 correctly. And
everything will start to make sense for you if you keep in mind that the
rules are assuming "the same dest addr is being used for send and
re-send" and a self-contained within a single dest addr. 

But I don't think this is a problem. I remember we talked about this and
considered this is a good strategy to depict SCTP CC rules, because we
wanted to have the rules be easily comparable with those of TCP's and be
easily cross-examined later to ensure the fairness and friendliness
between the two. The catch is that one must read and keep in mind the
assumptions made at the beginning of the chapter.

-Q

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 28 Oct 2002 06:52:26 -0600

Ivan:

I have read all of this thread except Qiaobing's last post... and kept 
quite .. but not
now.

Qiaobing, I also was a large part of this text and I think it IS clear 
here what we
were trying to do.. and we DO NOT send a full cwnd to the new address.

Now I must admit we were NOT thinking of a triple homed endpoint.. but a 
plain
2 address peer... so adding this second time-out is a bit of a twist.

What should happen?

Well using Daisy's scenario:

a1: c1 c3 c4
a2:
a3: c2

Assuming all chunks fit in a single MTU

When a1 expires I get

a1: none
a2: c1
a3: none

c3/c4 marked for retransmission
c2 still awaiting a SACK

Now when a3 expires (assuming after a1)

The implementation gets a choice... as Qiaobing illustrated. It can
do

a1: c2
a2: none
a3: none

c1 pending
c3/c4 marked for retran

OR

a1:none
a2: c2
a3: none

c1 pending
c3/c4 marked for retran

... why..

Well first you can pick any alternate that is up.. this gives us the 
choice. And at ANY single
retransmission we can only send ONE MTU out.. someplace...

So at the retransmission we go to send C2 (the only one to retransmit) 
out...  now we still
must obey the cwnd of any destination.. so if by chance a2 had its 
flight size equal to its
cwnd size.. then we could not send c2 out a2.. but lets assume it was 
higher than that... then
we WOULD send c2 out.

Could we send c3 or c4 ahead of C2? I suppose one could.. but this does 
not help you advance
your cum-ack.. which is the only way you can get cwnd growth..

Basically any time you get a timeout you:

1) mark those pending tsn's for retransmission
2) select an alternate destination... this was our choice a1/a2
3) Once the choice is made you pick the lowest TSN pending 
retransmisison against
    that address and send it... by chance our chunk sent to a3 was lower 
than any other on
   a2 when we went to retransmit. One could also invision where we had

a1: c1 c2 c3
a2: none
a3: c4

in this scenario with the same timeouts then you would at c4's timeout 
retransmit
c2 again out a2... since IT is the lowest (assuming you did not pick 
a1.. which you are
allowed to do).

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)