Subject: [Rmt] pim-sm and layered multicast

From: Fethi Filali <[email-masked]>
Date: Tue, 12 Feb 2002 11:20:54 +0100

Hi all,

Suppose that we use PIM-SM as multicast routing protocol and the 
multicast source uses a layered multicast congestion control protocol 
(RLM, FLID-DL, ...) to send data to the receivers. Each layer uses a 
different multicast group address. These addresses may be mapped to 
different RP using the bootstrap mechanism of PIM-SM (which allow only 4 
  group adresses to be mapped to the same RP).

Suppose that we do not switch immediatly to the SPT (we van use a 
*private* mechanism to decide the switching rather than the rate-based 
one given as example in pim-sm draft).

The problem is that a multicast receiver may receive layers from 
different paths (because of using different RP per layer), the 
congestion may occur in lower layers paths but not in higher layer 
paths. Two problems hold:

1. the receiver take more time to detect the congestion because it 
leaves layer by layer and estimate again the loss rate.

2. the receiver will leave higher layer, while it follows 
un-congestioned paths !!

My questions are:

1. Do you agree with me ?
2. If so, are there any works on these pbs?

Fethi.

PS: the same problem may be hold if we use a QoS-based multicast routing 
protocols (no deployable one exist) !!

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 12 Feb 2002 10:34:20 +0000

>>1. Do you agree with me ?

hypothtically, sure

 >>2. If so, are there any works on these pbs?
 
i guess

also note that a source that actually is multiple sources to different grouops could
fall foul of MSDP timers too - if the layer increase/decrease stuff was sufficiently
infrequemt./..
 >>protocols (no deployable one exist) !!
 
spose so

 cheers

   jon

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 12 Feb 2002 08:31:11 -0500

On Tue, 12 Feb 2002 11:20:54 +0100
>   group adresses to be mapped to the same RP).

You are referring to RFC 2362 Section 3.7. This is set by
the hash mask :

        1 For RP addresses in the RP-Set, whose Group-prefix
covers
        G, select the RPs with the highest priority (i.e.
lowest
        `Priority' value), and compute a value:

   Value(G,M,C(i))=
   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) +
12345) mod 2^31

        where C_i is the RP address and M is a hash-mask
included in
        Bootstrap messages.  The hash-mask allows a small
number of
        consecutive groups (e.g., 4) to always hash to the
same RP. For
        instance, hierarchically-encoded data can be sent on
consecutive
        group addresses to get the same delay and
fate-sharing
        characteristics.

The intent as I read it is not that _only_ four group
members be assigned to each RP, but that _at least_ four
consecutive group addresses be assigned to each RP. In many
domains, one RP handles all groups.

This was probably written before GLOP. Also, I know of no
specificiation or recommendation for the hash-mask M.
Given the relative success of GLOP, maybe a hash value of
0.0.0.255 be used - so that an entire GLOP would be handled
by one RP by default.

> one given as example in pim-sm draft).

I have a feeling that ASM may move to a "never switch to the
SPT" as SSM takes off and ASM is used mostly for
teleconference type applications, so this seems germaine.

Regards
Marshall Eubanks

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 12 Feb 2002 06:04:09 -0800 (PST)

>  >>1. Do you agree with me ?

Okay, sure in theory 'yes'. BUT, if this content is using layered-cc, then
I would assume its all coming from the same network if not the same
source. Though I've seen some pretty shocking configs/deploys, I can't
imagine why a content owner would devide their groups space (I'm assuming
a content owner would be using GLOP addressing) across multiple RPs then
intentionaly cross RP boundaries with layered-cc content. But,
I've seen worse things, received complaints about performance,
then helped them do it right. Networks don't kill people; people kill
people.

In addition, true the redundant RP's will have different paths to the
receiver, but in the real world, a content owner's network would devide RP
services in some balanced fassion (most likely using Anycast-RP, NOT BSR,
but..) meaning that the paths may be different but negligibly different.
The source of ~most congestion is the last mile. And if the content owner
had a congestion problem due to their network topo or content load
balancing, they will fix the problem or loose business.

> fall foul of MSDP timers too - if the layer increase/decrease stuff was sufficiently

Hmm, I don't follow this. The source(s) are sending to all used groups all
the time therefore the MSDP timers are never an issue. The periodicity is on
the receiver end.

Greg

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 12 Feb 2002 06:34:08 -0800 (PST)

> domains, one RP handles all groups.

A content owner/provider has spoken-up. Thanks!

> teleconference type applications, so this seems germaine.

This is off the thread a bit, but I don't agree here. ASM will always have
S,G trees from the reciever RPs to the sources. If it were to move to
"never switch to SPT" the only place where this would have an affect is in
the receiver networks - at the tail end of the trees.

Greg

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 12 Feb 2002 14:49:38 +0000

>>I would assume its all coming from the same network if not the same

you're right - though there are reasons for sourceing different layers from different
sources (liegitimate - e.g. load blaancing, late join to different qos levels etc)

 cheers

   jon

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 12 Feb 2002 11:59:54 -0500

On Tue, 12 Feb 2002 08:31:11 -0500
 "Marshall Eubanks" <[email-masked]> wrote:
> > Suppose that we use PIM-SM as multicast routing
> protocol
> > and the 
> > different multicast group address. These addresses may
> be
> > mapped to 
> 0.0.0.255 be used - so that an entire GLOP would be

Just for the record :

Of course, I flipped the bits here - the suitable mask would
be 255.255.255.0

Thats what I get for placing e-mail before coffee.

Marshall 

> handled