Subject: Re: FW: ssthressh

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 12 Jul 2005 07:22:37 -0600

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

On Tue, 12 Jul 2005, Brian F. G. Bidulock wrote:

> Mark,
> 
> On Tue, 12 Jul 2005, Mark Allman wrote:
> 
> > 
> > Brian-
> > 
> > > > > In the barbell situation above, if there is, again, a multi-homed
> > > > > SCTP connection from IP-a,IP-b to IP-x,IP-y and a TCP connection
> > > > > from IP-b to IP-y, the CMT SCTP association will load path IP-a to
> > > > > IP-x as well as path IP-b to IP-x and allow the TCP connection to
> > > > > load path IP-b to IP-y.  SCTP takes 1/2 of the bandwidth (1/4 each
> > > > > from IP-a to IP-x and IP-b to IP-x in competition with itself) and
> > > > > allows TCP to take 1/2 of the bandwidth.
> > > > 
> > > > Why do the SCTP flows only take 1/4?  In stock SCTP then they'd end
> > > > up getting about 1/3 - leaving the TCP with 1/3.
> > > 
> > > No, in the stock SCTP, if both the SCTP primary path and the TCP
> > > connection are the shared, the SCTP primary path takes 1/2 and the
> > > alternate path is idle, leaving TCP with 1/2.  If the alternate path
> > > happens to be unshared, 1/2 of the total available bandwidth is
> > > wasted, 1/2 is wasted for SCTP, and 1/2 is wasted for TCP.
> > 
> > I do not disagree with what you sketched above.  However, you are
> > talking about a different situation than the one to which I was
> > responding.  I.e., the situation that Randall posted did not involve any
> > unshared path.
> > 
> > The diagram that Randall posted was ...
> > 
> >           ----IP-a<--           -----> IP-x
> >          /          \          /      \
> > sender               -bottle-          receiver
> >         \           /         \        /
> >          ----IP-b<--           -------> IP-y
> > 
> > In this case, the primary and the alternate share a bottleneck as *all*
> > traffic between the sender and receiver shares a bottleneck.  
> > 
> > If SCTP is using both the primary and alternate destinations at the same
> > time, SCTP is using the stock congestion control in RFC2960 and a third
> > TCP flow is active between the host pair then TCP will get roughly 1/3
> > of the bottleneck capacity and each SCTP flow will get approximately 1/3
> > of the bottleneck capacity.  There is much literature that supports this
> > assertion ... it is not some sort of novel insight.  
> 
> The algorithm I use for CMT exhibits 1/2 SCTP and 1/2 TCP in this situation.
> 
> cwnd for each SCTP destination only grows to 1/4 of the available
> bandwidth, TCP cwnd grows to 1/2.  So that's 1/4 + 1/4 = 1/2 for SCTP,
> and 1/2 for TCP, not 1/3 + 1/3 = 2/3 for SCTP and 1/3 for TCP as you
> describe.
> 
> Think about it: if SCTP were to take 1/3 + 1/3 and TCP 1/3, then SCTP
> would be twice as likely to suffer a retransmission as TCP and therefore
> its combined cwnd's should fall until it is only as likely as TCP to
> suffer a retransmission (that is, until it is using only 1/2 of the
> shared bandwidth).  Anything other than 1/4+1/4 and 1/2 and the SCTP
> cwnd algorithm cannot be per RFC2960.
> 
> I don't just say this either, it have been verified by experiment (not
> just simulation).
> 
> Could you point to some of the literature you mention so that I can see
> what congestion algorithm they claim to be using?
> 
> 
> > 
> > And, I tend to agree with Randall that this means that SCTP is gobbling
> > more than its share of the resources.
> 
> But it doesn't.  Not when congestion and CMT are performed correctly.
> 
> --brian
> 
> > 
> > allman
> > 
> > 
> > 
> 
> 
> 
> -- 
> 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 ¦

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