Subject: Re: FW: ssthressh

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

Mark,

Well, that's hardly "much literature".  RFC2960 congestion control
is actually more conservative than TCP (even TCP+SACK), so I don't
think that there is a comparison there.

--brian

On Tue, 12 Jul 2005, Mark Allman wrote:

> 
> > The algorithm I use for CMT exhibits 1/2 SCTP and 1/2 TCP in this
> > situation.
> 
> Fine.  I have noted that I don't know CMT and my note carefully said
> that if one were to use RFC2960 congestion control then the situation is
> as I have described it.
> 
> > 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).
> 
> Um.... I don't think that hangs together at all.  The cwnds should all
> equalize and see a fairly similar drop rate.  
> 
> If *one* SCTP flow were using a disproportionate amount of the capacity
> (e.g., 2/3 as above) then you'd be right that it would see a higher drop
> rate (roughly speaking) and so it would reduce cwnd more often (and in
> larger steps) than the TCP.  But, we are talking about two independent
> SCTP flows and a TCP flow.  So, a drop on one SCTP flow doesn't have any
> impact on 2/3 of the utilization (the TCP flow and the other SCTP flow).
> 
> In other words, say there were two TCP flows (obviously completely
> independent) and an SCTP flow.  Each flow gets 1/3 of the capacity.  Or,
> if there were 3 SCTP flows then each would get 1/3.  Or, if there were 3
> TCP flows then each would get 1/3.
> 
> > Could you point to some of the literature you mention so that I can
> > see what congestion algorithm they claim to be using?
> 
> The handy example I have is for TCP+SACK and is...
> 
>     Wesley Eddy, Shawn Ostermann, Mark Allman. New Techniques for Making
>     Transport Protocols Robust to Corruption-Based Loss. ACM Computer
>     Communication Review, 34(5), October 2004.
>     http://www.icir.org/mallman/papers/ceten-ccr-oct2004.ps
> 
> It's not about any of this... but, look at the fairness reported in
> figure 6.  Just look at the stock TCP line and you'll see that 10 and 50
> TCP flows all get about the same share the bottleneck (exactly 1/N
> sharing would yield a fairness index of 1.0).
> 
> It's not SCTP.  Maybe someone else can point to SCTP papers on the
> subject.  But, SCTP's congestion control (per 2960) is modeled after
> TCP+SACK.  The same principles apply to each and so the behavior should
> be similar.  There will be subtle differences, but nothing on the order
> of the major discrepancies you paint.
> 
> Also, look up papers from Sally Floyd, Matt Mathis, Jitu Padhye,
> etc. for more on all of this.
> 
> 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 ¦