Subject: Re: tcp-friendliness

From: Dah Ming Chiu - Sun Microsystems <[email-masked]>
Date: Fri, 6 Apr 2001 11:39:02 -0400 (EDT)

We had a lot of discussion on this topic (in the RMRG) a couple of
years ago.  I think there was a lot of support of using your first
definition as a guideline.  Of course in reality, "at all times"
is subject to interpretation.  There is also limits as to how fast
each flow can react to congestion, and thus how strict fairness
can be maintained dynamically.

I agree with Jon Crowcroft's last email.  Requiring RMT to be TCP
friendly is dictating certain way of allocating network resources
between unicast and multicast traffic.  This is a rather complex
issue. In the long run, the correct solution may very well be
governed by the economics/pricing models of the Internet, rather
than purely by the transport mechanisms.  In the mean time, we
should concentrate on the effectiveness of controlling/avoiding
congestion, and be more liberal with how we mandate fairness.

In thinking about these issues, we have written a couple of papers
you might find useful:

1) "Some observations on Fairness of Bandwidth Sharing"
   http://research.sun.com/techrep/1999/abstract-80.html
   We discuss the meaning of different fairness criteria, and some
   issues when applying them to multicast

2) "Pruning Algorithms for Multicast Flow Control"
   http://www.cs.ucsb.edu/ngc2000/program/117.ps
   This paper deal with the case when you have n receivers who can
   receive at 100KB/s and one at 5KB/s, how you might want to "prune"
   the slow receiver.  It also discusses the TCP-friendliness issue
   with doing that.

Regards
Dah Ming Chiu
Sun Labs

	X-Authentication-Warning: listserv.lbl.gov: majordom set sender to 
[email-masked] using -f
	From: Jeremiah Scholl <[email-masked]>
	To: Marshall Eubanks <[email-masked]>
	cc: Jeremiah Scholl <[email-masked]>, [email-masked], Peter Parnes 
<[email-masked]>
	Subject: Re: tcp-friendliness
	MIME-Version: 1.0
	
	All the responses I received have clarified the meaning of the
	statement in the context of the PGMCC article.  However, I am still
	curious if there is a standard way to define TCP-friendliness in a
	multicast setting.  The way I see it there are two possible ways to 
define
	TCP-friendliness for a multicast flow over its liftime.
	
	1)The flow rate if the scheme was adjusted to the TCP-rate of
	the worst-case receiver at all times.
	
	2)The flow rate if the scheme was adjusted to the worst-case flow over 
the
	lifetime of the transfer.
	
	Here is a simple example of how these two definitions could give you
	different acceptable rates.
	
	Suppose we multicast to two receivers for a period of 1 minute,
	receiver X and and receiver Y.  For the first 30 seconds receiver X is
	in a congested state a has a "TCP-friendly" bandwidth of 5 kb/s.  
Receiver
	Y on the other hand is not congested and can receive 100 kb/s.  Half
	way through the life of our transfer the situation for the two receivers
	is switched and for the final 30 seconds reciever X can recieve 100
	kb/s and receiver Y can receive 5 kb/s.
	
	Using definition 1 for TCP-friendliness our acceptable send rate would 
be
	5 kb/s for the first half of the transfer and 5 kb/s for the second half
	of the transfer.  So, we would be able to transfer:
	
	5 kb/s  * 60 s = 300 kb of data and still be TCP friendly.
	
	However, if we use definition 2 for TCP-friendiness from above then our
	acceptable send rate would be the TCP-friendly rate for either flow
	throughout the entire minute (since in this case there is not a
	worst-case flow).  So, we would be able to transfer:
	
	(100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us
	
	3150 kb of data and still be TCP friendly. 
	
	So, I suppose what I am wondering is if there is in fact a generaly
	accepted definition for TCP-friendliness for a multicast flow.  If so,
	what is it.
	
	Thanks!
	
	Jeremiah

	On Mon, 2 Apr 2001, Marshall Eubanks wrote:
	
	> Jeremiah Scholl wrote:
	> 
	> > Can anyone tell me if there is any generaly accepted definition for
	> > TCP-friendliness regarding reliable multicast.  The reason I am 
asking is
	> > that the PGMCC paper (the version that was presented at SIGCOMM) has 
the
	> > following statement near the end of section 4.4
	> >
	> > "in the presence of multiple receivers, there is no clear definition 
of a
	> > TCP-fair rate."
	> >
	> > Can anyone help clarify this for me?  Does the IETF have any plans 
to
	> > standardize the definitions of TCP-fair or TCP-friendly with regards 
to
	> > reliable multicast?
	> >
	> > Thanks!
	> >
	> > Jeremiah
	> 
	> My personal, and unpopular, opinion is that this is not a well-posed 
problem.
	> 
	> 
	>                                   Regards
	>                                  Marshall Eubanks
	> 
	> 
	> T.M. Eubanks
	> Multicast Technologies, Inc
	> 10301 Democracy Lane, Suite 410
	> Fairfax, Virginia 22030
	> Phone : 703-293-9624
	> Fax     : 703-293-9609
	> e-mail : [email-masked]     [email-masked]
	> 
	> http://www.on-the-i.com http://www.buzzwaves.com
	> 
	> 
	>