Subject: A question about RFC2960.

From: [email-masked]
Date: Fri, 5 Sep 2003 11:36:13 +0800

Hi,
 
I have a question about RFC2960. Could you help me?
 
In the section "6.3.3 Handle T3-rtx Expiration" of RFC2960, there are the following words:
 
   Note: Any DATA chunks that were sent to the address for which the
   T3-rtx timer expired but did not fit in one MTU (rule E3 above),
   should be marked for retransmission and sent as soon as cwnd allows
   (normally when a SACK arrives).
 
What's the meaning of "normally when a SACK arrives"? Must sctp obey this rule?
 
To my point of view, sctp should send packets as much as CWND allows.
 
Because this rule will block a path. And this rule will cause a big problem in multi-home situation.
 
Suppose that we two pathes (path A and path B) between endpoint E1 and endpoint E2 in multi-home situation.
 
If path A was broken and T3-rtx timer expired, a retransmitted packet will be sent in path B and then path B will be blocked waiting for a SACK according to this rule.
 
It means that no packets can be sent between E1 and E2 until a SACK is received or T3-rtx timer expires again.
 
I think this rule will affect the efficiency of SCTP and we should remove this words.
 
What do you think?
 
Brs,
Wei Fusheng

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 4 Sep 2003 22:56:57 -0600

Fusheng.Wei,

>    What's  the  meaning of "normally when a SACK arrives"? Must sctp obey

Because in rule E1 you set cwnd <- MTU.  Becaue of this, for a single homed
association, it will take a SACK to increase cwnd and any messages that would
not fit in the retransmitted packet will normally have to wait for a SACK.

>    To my point of view, sctp should send packets as much as CWND allows.

It does.  In this case, in the single-homed case, cwnd is 1 MTU.

>    problem in multi-home situation.

Quoted above is a note.  E1) is a rule.  cwnd <- MTU on T3-rtx expiry.  The
path is only blocked if there was greater than 1 MTU of data to retransmit.
This blocking is a natural consequence of congestion control.

>    If path A  was broken and T3-rtx timer expired, a retransmitted packet
>    will  be  sent in path B and then path B will be blocked waiting for a
>    SACK according to this rule.

No it will not.  Rule E1 says you set cwnd <- MTU on path A.  This is very
clear:

   E1) For the destination address for which the timer expires, adjust
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       its ssthresh with rules defined in Section 7.2.3 and set the cwnd
       <- MTU.

T3-rtx did not expire to destination B in your example and therefore it might
very well have a cwnd > MTU and be allowed to send more data.  But as
mentioned in the note, typically it will not.  This is because while A was
used as the primary, B was not carrying traffic and its cwnd should have
fallen to 1 MTU under normal conditions anyway.

>    received or T3-rtx timer expires again.

No it does not.  You read too much into a parenthesized comment.

>    I  think  this  rule  will affect the efficiency of SCTP and we should

It is not a rule, it is a note.  It contains the RFC keywords "should", but
only pertaining to sending the outstanding TSN as soon as possible given cwnd
consideration which is reasonable.

If anything, it says that you SHOULD send all the packets you can on B given
its cwnd, which is what you want to do anyway, is it not?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 08 Sep 2003 08:18:12 -0500

Ok, after reading through this thread.. and realizing things
are degrading into something else :-0 I will answer this and ignore
the other noise... I have said enough on it :>

> What's the meaning of "normally when a SACK arrives"? Must sctp obey 

As pointed out the above is NOT a rule... it is informative.. If you are
singly-homed you send one packet out... and the next event that
will get anything out the door is a SACK.. that is the point of the ()

Now in a multi-homed situation.. yes you still only send 1 packet out
to the alternate.. and as Ivan as said this may mean you don't send
2 packets (where most likely the alternate is parked at aka the initial
2 MTU's on the destination)...

Now in the above case.. aka multi-homed.. any oppurtunity to send would
be probably a better choice of wording.. so if ..

1) The user did another send call.. you might send more
2) The peer sent in a HB.. you might send more
or
3) A sack arrives..

When Vern wrote this section I know we went back through it
a couple of times to try to "non-singly home it" but we were not
always sucessful .. so maybe the words should not say "normally
a SACK" but instead "next oppurtunity to send" .. but on the other
hand.. it does not rule out sending in case 1/2 above... and if you are
singly homed.. you can't send anyway .. most likely (as Brian correctly 
points out
since your MTU has collapsed).

Now whats behind all this???

The idea is to limit what is sent even though the paths may be 
completely diverse which
in the big-I is not as likely as say a private network. So it is 
probably the correct
conservative thing to do..

Now after saying all that I want to make a note.. that I just 
realized... and no
I don't think we should do anything about what I am about to say...

There is NO MUST in doing 6.3.3. For that matter the "SHOULD" Brian
pointed out is in lower case.. which means it is not even a key word.

So since there is no MUST or SHOULD one does not have to follow these rules
at all.. I am not advising this.. since I do think these rules are the 
right thing
to do...

So for the Ivan and others that want to send the full cwnd's worth of 
retranmissions (if
there are that many) to the alternate destination.. there is no 
violation of the RFC
to do this... You may be causing trouble for yourself... but you would 
discover
that anyway if the two paths have a shared bottleneck that is 
congested... aka
both destinations will soon be in a 1MTU locked state..

R

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