Subject: Re: FW: ssthressh

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Jun 2005 05:55:40 -0600

Randall,

On Thu, 30 Jun 2005, Randall Stewart wrote:

> Brian F. G. Bidulock wrote:
> 
> >>Once the shared bottleneck detection algorithms are fully
> >>worked out ... then we can actuall do it as a standard thing :-D
> > 
> > 
> > Works fine with or without a shared bottleneck.
> > 
> > What problems do you envisage?
> > 
> The problem is NOT for the SCTP sender.. its for
> the rest of the internet. The basic goal of CC is to
> make sure a particular sender does on harm to the network
> and yet gets its fair share of the bandwidth... with
> a design goal of 1/Nth of the bandwidth where
> N is the number of competing users.
> 
> So in this situation:
> 
>           ----IP-a<------Inet-a-Path------> IP-x
>          /                                       \
> sender                                             receiver
>         \                                        /
>          ----IP-b<-------Inet-b-Path------> IP-y
> 
> which is a typical sigtran for example.. CMT (conncurent
> multipath transfer) does no harm.. providing that you do
> fix the problem with Fast Retransmits (with similar algorithms
> to what Jana is working on at the U-of-Deleware)... No problem.
> 
> 
> However if you have this:
> 
> 
>           ----IP-a<--           -----> IP-x
>          /          \          /      \
> sender               -bottle-          receiver
>         \           /         \        /
>          ----IP-b<--           -------> IP-y
> 
> You now have sender getting 2/Nths of the bandwidth of
> the bottleneck.. which gives the sender more bandwidth
> of the bottleneck then it is entitled to.
> 
> If you can detect the shared bottleneck (which I know
> there is several research studies going on in this
> area.. then you can compensate for this).
> 
> I add Mark on... he might want to comment futher :-D
> 
> Mark? any thoughts :-D
> 

When using a load sharing CMT algorithm (such at the one I have posted
on several occasions), this is not what happens when competing with a
TCP connection.

In the football situation above, if there is 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 fully load path IP-a to IP-x and
allow the TCP connection to fully load path IP-b to IP-y.  SCTP takes
1/2 of the bandwidth and allows TCP to take 1/2 of the bandwidth.

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.

The same occurs if CMT SCTP is single-homed on one end multi-homed on
the other.

Not only does this occur in the steady state, but also works for
transient behavior: as TCP ramps up its congestion window (additive
increase), SCTP moves out of the way smoothly (multiplicative decrease).

This is not only theoretically correct (sliding window theory[1]) but
has been experimentally verified.  Sliding window congestion control
algorithms do not depend on whether the network is a football or a
barbell.

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

Also note that it does not matter if the sender is CMT and the receiver
is not, because it is the sender that runs the congestion algorithm.

I would go so far as to say that multi-homed, load sharing CMT SCTP
increases network efficiency by utilizing bandwidth unavailable to TCP
(unavailable only because of TCP's restrictive single-homed view of the
network).  It is certainly not harmful.

I trust that any further research will bear out the same conclusions.

--brian

[1] "Modeling and Analysis of Computer Communications Networks,"
Jeremiah F. Hayes, Concordia University, Montreal, Quebec, Canada,
1984.  ISBN 0-306-41782-0  Section 11.3.2 Window Flow Control: A
Closed-Network Model.

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