Subject: reliable multicast congestion control

From: Jeremiah Scholl <[email-masked]>
Date: Fri, 23 Feb 2001 15:44:12 +0100 (MET)

I have recently been looking at the internet drafts available on the web
site for rmt workgroup and have a question regarding the standards that
are currently being developed.  Specifically I am interested in
information about congestion control.  

I noticed that there is currently one document on the site that describes
a congestion control mechanism.  It is titled "Reliable Multicast
Transport Building Block: Layered Congestion Control".  This congestion
control mechanism seems to be taylored specifically for the case where
massive scale is the primary concern and seemed to be created to work
along with LTC.  

I am wondering if there will be additional congestion control "Building
Blocks" created that focus more on other types of applications (like
collabrative workspaces for example).  Does the group plan on creating
one congestion control document for each protocol?  Any information on how
congestion control for reliable multicast will fit into the work on
standardization of reliable multicast would be very helpfull.

Thank you very much,

Jeremiah Scholl

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 23 Feb 2001 15:09:24 +0000

In message <[email-masked]>, Jeremiah 
 
 >>standardization of reliable multicast would be very helpfull.

 Jeremiah 
 
we went round this loop several times - the problem with this is that
we could never get people to poin down the applicationrequirements 
fir cilaborative workspaces that allowed for congestion control -

looking back at this again, let me try to restate where we got to
(some of this happened in the LSMA working group)

1/ a lot of colalborative applications have lowish message rates and
smallish messages (viz, wb, nte, game traffic) - 

2/ they are highly bursty (but not high rate - ) i.e. they are 1
packet or 2, then nothing for ages, per source

3/ many to many: there's no obvious correlation in the rate from one
source and another

4/ there _IS_ a requirement for latency control - this means that
adaption below a minimum rate is not acceptable, and usualy means that
you have to provision, or reserve, for them for them to be usable at
all over any significant distance

5/ when there is a large transfer (e.g. wb loading slides to a new/late
joiner), its 1-many, which is covered by current approaches

6/ in IETF "stakeholder" terms, the recent trend for ISPs technology pull has 
been SSM - which mitigates against simple transport protocols for
multiple sender - typically, for smallish groups, though, yo uhave a
coordination server: "clients" runs unicast  to it - it runs ssm to
clients - them same rules apply...(actually quite nicely for ALC like
protocols, since yo ucan accomodate heterogeneity and asymetric trees
quite elegantly)

for many-to-many large group, large numebr of senders, the claim has
been there aren't "compelling" application demand (at least yet)....

that may sound negative - i dont mean to be - i think there's also an
element of "oh, we think we can solve this case so lets get it done,
then we can go onto the harder case again"

given the data rates involved, we are fairly conveinced that games for
example will appear that are multiplayer but not server based once the
game engines for this are in place - then some sort of "collective
bargaining" congestion control looks like being vital.....

 cheers

   jon

---

From: Jeremiah Scholl <[email-masked]>
Date: Tue, 27 Feb 2001 10:02:06 +0100 (MET)

> bargaining" congestion control looks like being vital.....

Jon,  thanks for the comments! I agree with what you wrote.  

Has any progress at all been made towards forming a consensus on what the
building block will need?  Have the most basic requirements been agreed
upon yet and if so what are they? 

For example, because of the interactivity of users multiple-rate
congestion control does not lend itself well with collabrative
workspaces.  Also, as you mentioned above there is still not "compelling
application demand" for large many -to- many sessions.  This would tend to
make tuning the send rate worst-case receiver a realistic option for the
scheme.   

So, has there at least been an agreement to create a building block for a
single-rate scheme that tunes its sending rate to the worst-case
receiver?

Any information about this or any other congestion control builing blocks
in the works would be very helpfull.

Thanks again!

Jeremiah

---

From: Luigi Rizzo <[email-masked]>
Date: Tue, 27 Feb 2001 11:14:40 +0100 (CET)

> single-rate scheme that tunes its sending rate to the worst-case

i just submitted an I-D on pgmcc, which is a single rate cong.control
scheme. You can find more at http://www.iet.unipi.it/~luigi/pgm.html
or on the sigcomm2000 site

	cheers
	luigi
----------------------------------+-----------------------------------------
 Luigi RIZZO, [email-masked]  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone (510) 666 2927             .
----------------------------------+-----------------------------------------