Subject: Re: FW: ssthressh

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 11 Jul 2005 16:17:56 -0600

Mark,

On Mon, 11 Jul 2005, Mark Allman wrote:

> 
> (catching up; or, trying ...)
> 
> > 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.

> 
> > Perhaps you failed to consider that the multi-homed SCTP association
> > in the examples ramps up at half the rate because it is running two
> > sliding windows and can only send to one at a time.
> 
> If the SCTPs are in fact limited by how fast the endpoint can transmit
> then I'd buy that.  But, that is not generally the case, right?

The rate ramps up at half the rate, all other things being equal.  That is,
both TCP and SCTP senders always have data to send, and can send above the
rate of the available bandwidth.

> 
> > If anything, perhaps CMT SCTP does not back off fast enough, but that
> > could be easily cured by steepening the multiplicative decrease by a
> > factor of the number of destinations.

Actually, I was wrong in that statement.  CMT SCTP already backs off fast
enough because it ramps up at 1/n'th the rate and therefore has already
backed of by a factor of n before the first multiplicative decrease.

> 
> This (and, a like change to the AI factor) would clearly make the SCTP
> flows less aggressive and could again spread out the fairness.  But, I
> guess I don't understand how this works in the absence of some
> algorithmic or parameter change.  (Althought, I'll admit not having any
> knowledge of CMT.)

CMT _is_ and algorithmic change, but SCTP already provides independent
sliding windows for each of its multi-homed association's destinations;
that is already sufficient to spread load.

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