Subject: tcp-friendliness

From: Jeremiah Scholl <[email-masked]>
Date: Mon, 2 Apr 2001 13:31:10 +0200 (MET DST)

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

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 02 Apr 2001 14:15:27 +0100

i thought it was that you have 1 equation in two variables, (
rate as a function of loss average and rtt) so you can
define an infinite number of different fairness models depending
whether you want to be fair to rtt (proportional) or loss (max min)?

In message <[email-masked]>, Luigi Rizzo typed:

 >>the issue there is that when you have a bunch of receivers behind
 >>the same bottleneck and different RTTs with the source, you
 >>have different values from the TCP formula for the different
 >>receivers. If only one of the receivers in the set -- any of them
 >>-- was active, then the rate associated with that receiver would
 >>certainly be TCP-friendly (PGMCC with one receiver is just TCP).
 >>The presence of other receivers in the group which do not cause
 >>additional traffic through the bottleneck should reasonably not
 >>change the judgement, but then it means that any rate in the set
 >>is equally good.
 >>
 >>
 >>	cheers
 >>	luigi
 >>

 cheers

   jon

---

From: Luigi Rizzo <[email-masked]>
Date: Mon, 2 Apr 2001 15:07:04 +0200 (CEST)

cheers
	luigi

---

From: Luigi Rizzo <[email-masked]>
Date: Mon, 2 Apr 2001 15:49:36 +0200 (CEST)

> whether you want to be fair to rtt (proportional) or loss (max min)?

It is an orthogonal problem. Even if you [can] choose the working
point, you still do not know which receiver's data to
plug in the equation.

	cheers
	luigi

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 02 Apr 2001 16:49:22 +0100

luigi

asuming i can solve the insoluble (getting feedback on RTT and loss
rate on all the edges of the tree) then
for proportional fairness, i can define a rule for combining
the  edges based on axiomatic tree weighting rules - for max min, i
dont have to since its just the bottleneck that matters

but in practice, you're right (of course

 cheers

   jon

---

From: "Karim Seada" <[email-masked]>
Date: Mon, 2 Apr 2001 11:23:43 -0700

But even in the simple case, where all receivers share the same bottleneck link,
but have different RTTs. If the rate is not associated with the receiver with
the highest RTT, it is not clear that TCP-friendliness would be achieved with
other competing TCP flows with high RTT (their rate according to the formula
will be less).

Karim Seada

---

From: Luigi Rizzo <[email-masked]>
Date: Mon, 2 Apr 2001 20:31:05 +0200 (CEST)

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> other competing TCP flows with high RTT (their rate according to the formula

and vice-versa. However you choose the representative, you make a
mistake when comparing with unicast TCP sessions with a different RTT.

	cheers
	luigi

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 02 Apr 2001 15:29:22 -0400

> standardize the definitions of TCP-fair or TCP-friendly with regards to

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

---

From: Shivkumar Kalyanaraman <[email-masked]>
Date: Wed, 4 Apr 2001 13:57:48 -0400 (EDT)

In a recent work, we decouple the measurement and use of loss rate and
RTT. This allows simple source-based implementation assuming
loss-indications are the only thing fed back... It does not seem to be too
bad as it would seem... No drop-to-zero, no beat down of competing TCP 
flows+reasonably equivalent rate sharing...

http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#mult

-Shiv
===
Shivkumar Kalyanaraman   
Asst. Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Room JEC 6003, Troy NY 12180-3590
Ph: 518 276 8979   Fax: 518 276 2433
WWW: http://www.ecse.rpi.edu/Homepages/shivkuma

A goal is a dream with a deadline -C. Knight

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 04 Apr 2001 14:44:19 -0400

> A goal is a dream with a deadline -C. Knight

Thanks ! I'll read these papers. Have you tried the same thing for receiver based CC ?

BTW, is RPI multicast enabled ?

--
                                 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]
http://www.on-the-i.com
Test your network for multicast : http://www.multicasttech.com/mt/

---

From: Jeremiah Scholl <[email-masked]>
Date: Fri, 6 Apr 2001 10:40:04 +0200 (MET DST)

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

---

From: Puneet Thapliyal <[email-masked]>
Date: Fri, 6 Apr 2001 06:53:39 -0400 (EDT)

> 3150 kb of data and still be TCP friendly. 

If the source rate is maintained at 100kbps with the "worst" receiver in
the receiver set having a b/w of 5kbps, it would be doing no good for
congestion control. 

Cheers,
Puneet Thapliyal
----------------------
Networks Research Lab,
RPI.
----------------------

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 6 Apr 2001 13:26:27 +0200

Jeremiah,

the definition of multicast TCP-friendliness definitely is certainly
governed by that famous Douglas Adams quote -- once somebody figures it out,
the universe is replaced by something even more bizarre and unexplicable.
The main problem with any new specific hard definition is that somebody will
immediately come up with

1) a protocol that is clearly TCP-friendly in all aspects but does not fit
the definition,
2) another protocol that manages to comply to the definition while not being
TCP-friendly at all.

On the other hand, the whole thing is really simple:
The whole point of the TCP-friendliness discussion is not to do damage.
In particular, you should not encourage destructive behavior:
If a multicast stream gets better bandwidth than a unicast stream, people
will move unicast traffic to multicast, even if there is only one receiver.
(If a multicast stream does not get better bandwidth than the corresponding
set of unicast streams, you remove a major incentive to move to multicast.)

In your example 2, assuming the bottleneck is a low-statmux link, clearly
you are damaging traffic on the links that are being severely overloaded.
This is not TCP-friendly by any stretch of the imagination.

The situation is slightly more murky on high-statmux links.
There is an argument that one multicast stream is better than the equivalent
multiple unicast streams, so you are entitled to a higher share of the
high-statmux link.
If that is granted, you might be allowed to push back TCP traffic more than
a single TCP stream would, but not more than the equivalent collection of
unicast streams would (note that, until we get infinite-bandwidth links,
this is quite different from saying "n times the throughout of a single
unicast stream").
Unfortunately, this borders on discussions of ISP business models, so there
is no *technical* argument that can bring this discussion to a conclusion.
Also, of course, the endpoints have a hard time finding out whether the
losses they see are from low-statmux bottlenecks or not.
The restricted-worst-edge model championed by Brian Whetten is an example
that has been influenced by this kind of thinking.

Gruesse, Carsten

PS.: And we are cheating by treating Multicast Congestion Control as an L3
problem.
With today's L2 networks, you may be severely overloading L2 links although
all receivers are happy.
This is a real-world problem!
Also, there are failure modes where a receiver does get the multicast
packets but does not manage to return congestion information.
In a world full of middleboxes, this is becoming more prevalent every day.

---

From: Joerg Widmer <[email-masked]>
Date: Fri, 06 Apr 2001 13:57:51 +0200

> lifetime of the transfer.

To me this seems to be directly related to the form of multicast
transmission. If it is a single-rate multicast distribution, only 1)
will ensure that competing TCP traffic is treated fairly, while
multi-rate multicast transmission can get away with an average rate of
2) and still be TCP-friendly. (So 1) is ok in either case.)

  Joerg

-- 
Joerg Widmer
Praktische Informatik IV, University of Mannheim
L15,16, 68131 Mannheim, Germany
Tel: +49 621 181 2605, Fax: +49 621 181 2601
http://www.informatik.uni-mannheim.de/informatik/pi4/people/widmer.html

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 06 Apr 2001 14:10:22 +0100

In message <[email-masked]>, Jere

 >>lifetime of the transfer.

the problem with "TCP friendliness" is that there are several levels
of "friendly" and usually peopel start to talk about fairness and
the whole area is bound up with a range of dilemmas ranging from
i) the specifics of implementation of a given TCP (and a given RMT)
and
ii) ideas of utility 
and 
iii) ideas of network efficiency (e.g. user v. provider optimality)

the definitons abouve are cute, but while 1/ is elegant its not
achievable - an instantaenous equivalent to the TCP rate of a
"worst-case" receiver (we.g. on a packet or single RTT timescale) is
not scalable, and usually ends up being covergent to zero rate
anyhow

2/ is subject to weird games peopel can play esp. aroudn the phase
shif at the diurnal (9am/5pm) times....

I would prefer we move to some sort of symptomatic (measurable.verifiable)
definiton of TCP co-existence behaviour and do it o na case by case
basis - e.g.  define the timescales over which an RMT adapts to a
set of TCPs that share a set of bottlnecks define the goal seeking
model it uses and the asymptotic behaviour maybe only a some sort of
last resrt....

the reason i would say thuis is that i beleive the jury is STILL OUT
on what users and providers actually WANT in terms of utility (and
relative utility of an RMT and a TCP) so we dont want to define any
single operating regime, but rather, just set some broad rules (e.g.
Asimov's 3 laws of Robotic multicast:

i) an RMT mustnt drive TCP to zero on any given bottleneck, over any
reasonable (RTT raealted?, or TCP lifetimes) timescale
ii) an RMT or let itself be driven to zero by any reasonable mix with TCP
over any comparable timescale  (e.g. to TCP flow lifes)
iii) the feedback or other contrl traffic (igmp for multirate)
for an RMT will always be bounded to some reasonable fraction of the
actual data traffic

for example..

cheers
jon

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 06 Apr 2001 09:42:12 -0400

> over any comparable timescale  (e.g. to TCP flow lifes)

Jon;

  ii) seems to be garbled - did you mean to say
an RMT must NOT let itself be driven to zero... ?

Or something else ?

If that's what you meant, I think that these 3 guidelines are
a good starting point.

Marshall

T.M. Eubanks