Subject: Re: FW: ssthressh

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 13 Jul 2005 18:43:12 -0600

Randall,

Not really research: results from testing in the same scenario that you
describe (multi-homed through a hub, contest with TCP).  I did the
experimentation a year or two ago when I was performing CMT testing.

The TCP contention results have not been published, only the CMT results
were published to our website at http://www.openss7.org/sctp_perf.html

But, the approach was the same, using also a 10Mbps hub instead of a
100Mbps switch, using iperf in the same manner shown to drive both TCP
and SCTP at the same time.  In the case of the switch (football), SCTP
moved out of the way of TCP altogether, and in the case of the hub
(barbell) SCTP competed fairly with TCP.

I would publish the results to our website, but they were performed on a
version that was not released and it would be difficult to recreate the
results.  When I get some time, I will rerun the tests on current
versions of software and post the results.

But if you'd like to get a jump on that with your own CMT algorithm, or
want to try an achieve the same results with your own SCTP
implementation, here's what I think is happening.

Probably the reason that it works this way is closely related to the way
that stock SCTP works.

The CMT algorithm (sent a number of times) strongly favors the "best"
path over other paths and, therefore, for the most part is effectively
running a single congestion window in bottleneck circumstances.  This is
similar in the way that stock SCTP sends to a primary and only sends to
an alternate when the primary is considered "failed".

Both situations take otherwise independent congestion algorithms and
couple them with a constraint.  In stock SCTP the constraint is "only
send to the alternate once the primary has failed".  For the CMT
algorithm, the constraint is "only send to a path when in becomes the
best path".

These are very closely related constraints in that within a given time
window, SCTP is only sending to a single destination.

Another reason that I believe that it converges to one window is that
when the destinations share a bottleneck, one of the destinations tends
to dominate as the "best" and the others fall away in the same manner as
stock SCTP.  When there is no bottleneck, no destination dominates and
improved throughput is realized.

Characteristics of the CMT algorithm that might assist with this are as
follows:

* When I go to transmit, I select the "best" destination based on a
  weighting that includes available send window considering congestion.
  This causes lower performing destinations to fall away.

* The weighting also favors the same destination as was last transmitted
  to if all other weighting factors are equal.  This adds persistence on
  the same destination.  This is good for limiting gap reports as well
  as helping with the bottleneck behavior.

* Once I choose the best destination, I send a much data as possible (is
  available), without checking again.  Again, this is good for gap
  reports as well as bottleneck behavior.

* When sending to the "best" destination is no longer possible because
  the send window has closed, I rerun the selection algorithm and go
  again.  (In the loop consideration is also given for max burst.)

If you adjust your own CMT algorithm to similar characteristics, you
might very well be able to recreate my bottleneck results with your own
systems.  It shouldn't be too hard for someone to run an NS-2 simulation
to figure out just what is happening and the importance of some aspects
of the algorithm.

--brian

On Wed, 13 Jul 2005, Randall Stewart wrote:

> Brian:
> 
> I happen to have a few cycles extra today and went
> looking through this thread for CMT literature... at
> least I thought you said there was research to show
> your algorithm is TCP friendly...
> 
> I can't seem to find any paper citation in this email
> thread... am I missing it or is there any?
> 
> I saw the citation from 1984 about sliding window theory.. but
> thats not going to cover any CMT stuff..
> 
> If you could point me to your research .. or research
> that you know about on this I think both Mark and I
> would appreciate it :-D
> 
> R
> 
> Brian F. G. Bidulock wrote:
> > Mark,
> > 
> > It might also be due to the CMT algorithm that I am using vs. those that
> > others might be using.  When I go to send, I always choose the destination
> > that has the largest available send window and the lowest RTO, all other
> > things being equal.  That means that if one destination suffers a
> > retransmission, the other is chosen for transmissions.  This make the SCTP
> > CMT flows, dependent upon each other and they do not behave as two independent
> > flows.  The CMT algorithm I use has been published to tsvwg on a number of
> > occasions.
> > 
> > What CMT algorithm does the "much literature' use?
> > 
> > --brian
> 
> 
> -- 
> Randall Stewart
> ITD - Cisco Systems Inc.
> 803-345-0369 <or> 815-342-5222 (cell)

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