Subject: Re: [eagle 00635] Fw: [Rmt] pim-sm and layered multicast

From: "T.H.Nguyen" <[email-masked]>
Date: Wed, 13 Feb 2002 18:00:45 +0900

>  From: Jon Crowcroft <[email-masked]>
>  To: Fethi Filali <[email-masked]>
>  Cc: [email-masked], [email-masked]
>  Date: Tue, 12 Feb 2002 10:34:20 +0000
>  Subject: Re: [Rmt] pim-sm and layered multicast 
> --
> 
> 
> In message <[email-masked]>, Fethi Filali typed:
> 
>  >>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 ?
> 
> hypothtically, sure
> 
>  >>2. If so, are there any works on these pbs?
>  
> i guess

These problems were described in the following paper:
"Rendezvous Points based Layered Multicast", IEICE Trans.
Commun., Vol. E84-B, No. 12, Dec. 2001.

Abstract and PDF file are available at this URL:
http://search.ieice.org/2001/files/e000b12.htm#e84-b,12,3133

> 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./..
>  >>PS: the same problem may be hold if we use a QoS-based multicast routing 
>  >>protocols (no deployable one exist) !!
>  
> spose so

-- 
Tran Ha Nguyen
Aoyama Morikawa Laboratory
Department of Information and Communication Engineering
School of Engineering, The University of Tokyo
Tel: +81-3-5841-6710, FAX: +81-3-5841-6776
Email: [email-masked]

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

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 14 Feb 2002 09:35:38 +0000

>>http://search.ieice.org/2001/files/e000b12.htm#e84-b,12,3133

cool - neat paper

note that one reason for  hashing to different RPs is to load balance

so there are two problems with layered coded schemes and this
1/ if yo uhave 2 flowss with potentuialyl 2 layers, and 2 RPs, then instead of getting
1 layer for each flow on each RP, you could end up with the each layer of 1 flow on each
RP, and none of the second flow - this is clearly unfair, 

2/is loss at an RP really correlated with bottlenecks ? in the UK national and MAN nets,
RPs are in overprovisoned palces, and loss is typically in the leaf/site networks (we
think, and others seem to agree)...if we could say use ECN, then the RP could monitor
ECN rate per group...which might then be a really cute way of extendign your idea

cheers
jon