Subject: Re: FW: ssthressh

From: Janardhan Iyengar <[email-masked]>
Date: Fri, 15 Jul 2005 14:20:37 -0400 (EDT)

Brian,

>> 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.
>
> Well, if you want to define CMT as something else, go ahead.  But, what
> I'm doing is transmitting to multiple destinations to achieve efficient
> load balancing over multiple destinations in contrast to the stock
> RFC 2960 primary/alternate approach.

That is what we had intended when we introduced the term "CMT". Glad to 
see that you use the term in the same sense.

> Yes, I looked at these last year.  It has taken your research some time
> to catch up with practice.

What practice? I do not understand what you mean by this comment - I 
certainly do not know of any CMT using SCTP in practice. You claim to do 
CMT in your code. I do not know how you do it.. I have asked you 
repeatedly, in vain, to share your algos in the past. I see that you have 
given more info in the email to Randy - comments below.

> Look at my last note to Randall to see the two little other things that 
> I do to get rid of those effects.

I did see your note. And I have a couple of comments. So, I'll copy and 
paste from the other email:

> If you place some persistence on the "best" destination into the
> algorithm, you might not only find the bottleneck behavior similar to
> what I report, but you should find that the gap report generation at the
> receiver reduced.

I still do not understand how your sending algo works. When do you stop 
sending to "the best destination" and when do you start sending to others?

> You could also try my two tricks for gap reports on CMT:
>
> 1. When the sender gets a gap report, I only perform FR steps when the
>   receiver is not "making progress".  The receiver is "making progress"
>   when it is contigiuosly filling a gap.  That is, a gap is shrinking.
>   This is far simpler that trying to run a multiple queuing model.
>   This trick does not break the rules: one is allowed to be more
>   conservative than the FR rules allow, per RFC 2960.  I don't think
>   one really has to even do FR, however, it has great benefits.

I'm guessing that you are assuming a certain sending mechanism. Unless you 
work with a multiple queueing model, IMHO, you cannot handle any sender 
scheduling mechanisms. In any case, a multiple queueing model, IMHO, is 
not complicated at all. The code to implement it is quite simple and 
requires delta changes.

>> 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.
>
> As I said, tests were also performed in competition with TCP, which results
> in paths that do not have the same bandwidth-delay product.  The same
> performance is achieved.

>> 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.
>
> Check with Armando, I have sent it to him many times, starting in 2001.  I
> have been sending it to you for 4 years now...

You sent it *once* to Armando four years ago.

In any case, I do remember looking at what you sent, and it was just a 
destination selection algorithm based on cwnd, RTT, among other things. I 
did not, and still do not understand what it does, and why it is the 
panacea for all CMT concerns.

Armando is currently on vacation, and will be for a little while longer. 
Maybe you could repost what you sent, this time *to the list* ?

Brian, I have pointed out the papers that present CMT concerns, and how we 
deal with them. I am trying to discern what you do from your quizzical 
responses. If you think it is important to you, and if you would like to 
share your ideas with the community at large, I would really appreciate a 
simple document that clearly talks about what you do. A simple outline 
would contain your sending algo, algo to deal with reordering, and a 
simple analysis describing how these algos work, and show why the shared 
bottleneck problem does not exist. Maybe some experimental results even.

Until then, if I said anything else, I would probably be repeating myself.

regards,
jana

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