Subject: Congestion Control BBs

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 13 Jun 2001 16:46:26 -0700

Hi,

given the progress made on the CC BBs and the need to
move forward with them, I'd like to reopen the discussion
on the process to do this.

At the last IETF I proposed to try and reach consensus on a
"reference simulations" document to be used as a base for
discussion in the evaluation of CC algorithms. I also proposed
to submit CC BBs as Experimental RFC *first* and move them to
standard track only after we have acquired some deployment
experience in the network.

Anyone has any opinion about this?

As for the "reference simulations" document, we could
use the attached document as a starting point. It comes
from the notes of a meeting attended by some of us and its based on
Mark's original notes.  The document was edited by John Byers.

	thanks,
	Lorenzo

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Jun 2001 09:31:38 +0100

a LOT of problems exist in the inter-domain groups

i think we should also specifiy what an CC BB does in the case of
receivers in other domains and broken or poorly behaving inter-domain
multicast (because it is actually an unfortuantell common case.
In message <[email-masked]>, Lorenzo Vicisano type

 >>Mark's original notes.  The document was edited by John Byers.

 cheers

   jon

---

From: Luigi Rizzo <[email-masked]>
Date: Thu, 14 Jun 2001 11:08:57 +0200 (CEST)

> multicast (because it is actually an unfortuantell common case.

but... isn't this the wrong layer to approach the problem ?
broken interdomain routing requiring patches in the transport
protocol ?

[that reminds me... in the PicoBSD floppy image for
pgmcc, i rate-limited the sender to avoid ethernet capture
effect that you could see on some hardware...]

	cheers
	luigi

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Jun 2001 10:14:57 +0100

>>broken interdomain routing requiring patches in the transport

well, TCP works in the presence of BGP poor convergence, so....

 >>effect that you could see on some hardware...]
 
cool

 cheers

   jon

---

From: Luigi Rizzo <[email-masked]>
Date: Thu, 14 Jun 2001 11:36:23 +0200 (CEST)

> well, TCP works in the presence of BGP poor convergence, so....

i would say "happens to work", not because of specific countermeasures,
but because with only one receiver, any breakage is going to hit in
the right place.

But in absence of group membership info, you cannot do much anywyas.

	cheers
	luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, [email-masked]  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Jun 2001 11:10:15 +0100

>>But in absence of group membership info, you cannot do much anywyas.

i guess what i am after is the fact that some of the itner-domain
routes lead to big steps in delays for some receivers and possibly big
steps in reported loss every now and then - we may wany yo specify
smart filters at single rate based  senders, or in layer joins in
receivers, in the same way that TCP has all the dupack threshold type
mechanisms...

 cheers

   jon

---

From: Lorenzo Vicisano <[email-masked]>
Date: Thu, 14 Jun 2001 10:53:09 -0700

An important point seemed to have emerged from this thread
(and from some private emails): simulations will not be able
to test many issues present in real-networks.

My suggestion of proceeding by steps (first experimental and then
standard track) addresses this somewhat.. however it does not seem
sufficient. Other possible actions are:

 a) add a disclaimer in the simulation document
 b) add recommendations for designers, to cope with known real-network
   issues (we could start making a list by putting together our experiences)
 c) encourage real-network tests.. (large scale test are always hard
   to setup, 'though).

My opinion about the specific inter-domain issue, is that it
would probably be very hard to design for some current inter-domain
pathologies (e.g. those caused by msdp). I'm not sure if we should
ignore the problem --and hope they will disappear when RMT protocols
start being deployed inter-domain (SSM should help)-- or spend a lot
of efforts in trying to cope with this. For sure I would *not mandate*
that CC algorithms work in the presence of these inter-domain anomalies.

	Lorenzo

In message <[email-masked]>,