Subject: Re: FW: ssthressh

From: Janardhan Iyengar <[email-masked]>
Date: Thu, 14 Jul 2005 14:18:43 -0400 (EDT)

[Folks on the Cc list: Let me know if I should trim you off the list]

Brian,

I was tied up in other things for a little while, so seem to have missed 
this discussion.

I am not sure what _you mean_ by "CMT". I thought I understood at first, 
but now, I am convinced that I do not. A couple of years ago, we 
introduced the term CMT as Concurrent Multipath Transfer - sending new 
data concurrently to the multiple destination addresses of a multihomed 
receiver.

You have written (several times) about how you schedule data to the 
multiple destination addresses. That is only a part of the CMT-SCTP 
problem, not all of it. Please look at 
http://www.cis.udel.edu/~iyengar/publications for the rest.

The experiments you point to assume several things; a significant one 
being that the bandwidth and delay on the two paths used are the same. 
These results cannot be generalized.

Although I am not entirely clear on its impact, the problem Randy points 
out is a very pertinent problem, which certainly cannot be solved by your 
sending algorithm, because to the extent that I understand your algo, it 
does not really apply to CMT (as I understand CMT).

It would really help if you could present your algo to the list. Even I 
have only a vague memory of what it is. If you are interested, we could 
take the discussion from there.

regards,
jana

On Wed, 13 Jul 2005, Brian F. G. Bidulock wrote:

> Randall,
>
> Not really research: results from testing in the same scenario that you
> describe (multi-homed through a hub, contest with TCP).  I did the
> experimentation a year or two ago when I was performing CMT testing.
>
> The TCP contention results have not been published, only the CMT results
> were published to our website at http://www.openss7.org/sctp_perf.html
>
> But, the approach was the same, using also a 10Mbps hub instead of a
> 100Mbps switch, using iperf in the same manner shown to drive both TCP
> and SCTP at the same time.  In the case of the switch (football), SCTP
> moved out of the way of TCP altogether, and in the case of the hub
> (barbell) SCTP competed fairly with TCP.
>
> I would publish the results to our website, but they were performed on a
> version that was not released and it would be difficult to recreate the
> results.  When I get some time, I will rerun the tests on current
> versions of software and post the results.
>
> But if you'd like to get a jump on that with your own CMT algorithm, or
> want to try an achieve the same results with your own SCTP
> implementation, here's what I think is happening.
>
> Probably the reason that it works this way is closely related to the way
> that stock SCTP works.
>
> The CMT algorithm (sent a number of times) strongly favors the "best"
> path over other paths and, therefore, for the most part is effectively
> running a single congestion window in bottleneck circumstances.  This is
> similar in the way that stock SCTP sends to a primary and only sends to
> an alternate when the primary is considered "failed".
>
> Both situations take otherwise independent congestion algorithms and
> couple them with a constraint.  In stock SCTP the constraint is "only
> send to the alternate once the primary has failed".  For the CMT
> algorithm, the constraint is "only send to a path when in becomes the
> best path".
>
> These are very closely related constraints in that within a given time
> window, SCTP is only sending to a single destination.
>
> Another reason that I believe that it converges to one window is that
> when the destinations share a bottleneck, one of the destinations tends
> to dominate as the "best" and the others fall away in the same manner as
> stock SCTP.  When there is no bottleneck, no destination dominates and
> improved throughput is realized.
>
> Characteristics of the CMT algorithm that might assist with this are as
> follows:
>
> * When I go to transmit, I select the "best" destination based on a
>  weighting that includes available send window considering congestion.
>  This causes lower performing destinations to fall away.
>
> * The weighting also favors the same destination as was last transmitted
>  to if all other weighting factors are equal.  This adds persistence on
>  the same destination.  This is good for limiting gap reports as well
>  as helping with the bottleneck behavior.
>
> * Once I choose the best destination, I send a much data as possible (is
>  available), without checking again.  Again, this is good for gap
>  reports as well as bottleneck behavior.
>
> * When sending to the "best" destination is no longer possible because
>  the send window has closed, I rerun the selection algorithm and go
>  again.  (In the loop consideration is also given for max burst.)
>
> If you adjust your own CMT algorithm to similar characteristics, you
> might very well be able to recreate my bottleneck results with your own
> systems.  It shouldn't be too hard for someone to run an NS-2 simulation
> to figure out just what is happening and the importance of some aspects
> of the algorithm.
>
> --brian
>
>
> On Wed, 13 Jul 2005, Randall Stewart wrote:
>
>> Brian:
>>
>> I happen to have a few cycles extra today and went
>> looking through this thread for CMT literature... at
>> least I thought you said there was research to show
>> your algorithm is TCP friendly...
>>
>> I can't seem to find any paper citation in this email
>> thread... am I missing it or is there any?
>>
>> I saw the citation from 1984 about sliding window theory.. but
>> thats not going to cover any CMT stuff..
>>
>> If you could point me to your research .. or research
>> that you know about on this I think both Mark and I
>> would appreciate it :-D
>>
>> R
>>
>> Brian F. G. Bidulock wrote:
>>> 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
>>
>>
>> --
>> Randall Stewart
>> ITD - Cisco Systems Inc.
>> 803-345-0369 <or> 815-342-5222 (cell)
>
> -- 
> 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 ¦
>

---------------------------------------------------------------
Janardhan R. Iyengar           http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab  --   CIS   --  University Of Delaware
---------------------------------------------------------------
------------=_1121365429-17028-0--