Subject: Re: FW: ssthressh

From: Randall Stewart <[email-masked]>
Date: Tue, 12 Jul 2005 11:43:16 -0400

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.

Soo... if I understand your point here its that:

a) a multi-homed SCTP flow, using both destinations to
    send data to would have two cwnds.. so if these two
    shared a bottleneck they get 2/Nths the b/w if following
    RFC2960 CC.

b) In contrast the other TCP flow gets 1/Nth the b/w since
    it uses the same algorithm but has only one set of
    cwnd parameters..

So, if there are three flows in this bottleneck, one from
a TCP flow, and two from a single SCTP association that
has the shared bottleneck dumb-bell... SCTP would get
as I expected 2/3 of the b/w vs 1/3 for the  TCP flow...

I think it basically centers around the fact that you
are keeping two sets of cwnd variables and applying
CC to each independantly.. now I suppose if you were
to have only ONE cwnd and apply a loss to either
destination as the same... then you would respond
fairly.. but of course you would also do worse where
you did not have the shared bottle neck.. not exactly
what you want :-D
> 
> 
>>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.

Hmmmm.. this rings a bell .. someone did a paper a while
ago that shows that SCTP has the same properties as TCP ... I will
dig around and see if I can turn up the reference.

R

> 
> Also, look up papers from Sally Floyd, Matt Mathis, Jitu Padhye,
> etc. for more on all of this.
> 
> allman
> 
> 
> 

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)