Re: [secdir] secdir review of draft-ietf-mmusic-delayed-duplication

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Radia,

On Sep 18, 2013, at 9:20 AM, Radia Perlman <[e-mail]> wrote:

> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> This document is about allowing a sender of a multicast stream to advertise that it will be sending duplicate streams offset in time, so that receivers can receive multiple copies...so that if packets are lost they will hopefully receive it from the later stream(s).
> 
> From a security point of view, there's no reason to complain.  However, I'm really dubious about what this will be used for, and whether this is the best way to solve the problem.  How does one cope with loss?  For instance...
> a) request retransmissions of specific missing pieces, perhaps not from the original source, but from a redistribution point (e.g., zillions of scalable reliable multicast protocols that were talked about/published years ago)
> b) send forward error correction so that the data can be reconstructed (e.g., Digital Fountain)
> c) cope with glitches on your video when in rare cases, e.g., network topology changes, some data gets lost

You are right, there are several different ways to deal with packet loss for both multicast and unicast. Retransmission, FEC, error concealment are all options. But the main use case for duplication is when there is a network outage for a period of time (i.e., bursty packet losses) like a route failure, hardware failure, etc. and all the packets transmitted during the outage will likely get lost until the route is repaired (could be 50 ms or 1 s or longer). Ret, FEC cannot deal with such outages. Concealment is not an option in most critical video apps, either. Duplication is a simple alternative. It has been deployed, it works and it is proven for this use case.

> 
> I'm not sure multicast is used so much anyway.  What are the applications today?  It seems like most video is individual on-demand rather than multicast.  

heard IPTV?

> And if there were some sort of multicast thing (like a sporting event), it seems like any combination of a), b), and c) above would be preferable to multicasting everything multiple times.

We deployed all options you listed above as well as duplication. As I said, they provide resiliency in different use cases.

> 
> A specific comment:  In the security considerations section it says "the SDP description needs to be integrity protected..."  Is this MUST be?  SHOULD be?

I dont think it deserves a 2119 keyword, there. Unless you have a strong objection, I prefer to keep it as it is.

many thanks.
-acbegen

> 
> Radia