Subject: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-00

From: Magnus Westerlund <[email-masked]>
Date: Sat, 26 Mar 2011 10:47:15 +0100

Hi,

I did a review of draft-ietf-avtext-multicast-acq-rtcp-xr-00 and I am
well aware of this document has already gone through WG last call but I
think I should bring these up to discussion. My personal view is that
they should be addressed prior to requsting publication of them.

1: General: The document appears to be missing any recommendations on
when the block should be used within an RTP session.

First, it hints to that after an acquisition is the right time. However,
to me it looks like you could do partial reporting of some fields when
certain events part way through acquisition of a complete session.

Secondly, there appears to be no recommendations if one should transmit
the same XR report several times, and what are the criteria for stop
sending it?

Thirdly, does one need to make it clearer that these should be only be
sent part of regular compound packets?

M2: Section 6:
I am missing an analysis of the potential information leakage from the
data reported. What are the risks of not having this encrypted? I think
there should be some words on that aspect of the report.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 26 Mar 2011 13:34:46 +0100

Thanks Magnus. 

> certain events part way through acquisition of a complete session.

Partial reporting is of little use. Since this data is useful for longer-term purposes. That is, it is not used to make immediate changes in the system. Thus I think the report should be reported once everything is complete. 
> the same XR report several times, and what are the criteria for stop

Once. I don't see much point in redundancy here.we can mention this. 
> sent part of regular compound packets?
Yes. 

> there should be some words on that aspect of the report.

The information reported in the report could be stolen as any other rtcp report data if not encrypted properly. I don't see increased risk here. If one is concerned about any leakage and they protect their regular rtcp reports, they should protect this xr as well. Beyond that, there is not much to offer IMO. 

-acbegen

> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 26 Mar 2011 14:00:58 +0100

See inline

Ali C. Begen (abegen) skrev 2011-03-26 13:34:
>> I did a review of draft-ietf-avtext-multicast-acq-rtcp-xr-00 and I
>> am well aware of this document has already gone through WG last
>> call but I think I should bring these up to discussion. My personal
>> view is that they should be addressed prior to requsting
>> publication of them.
>> 
>> 1: General: The document appears to be missing any recommendations
>> on when the block should be used within an RTP session.
>> 
>> First, it hints to that after an acquisition is the right time.
>> However, to me it looks like you could do partial reporting of some
>> fields when certain events part way through acquisition of a
>> complete session.
> 
> Partial reporting is of little use. Since this data is useful for
> longer-term purposes. That is, it is not used to make immediate
> changes in the system. Thus I think the report should be reported
> once everything is complete.
>> 
>> Secondly, there appears to be no recommendations if one should
>> transmit the same XR report several times, and what are the
>> criteria for stop sending it?
> 

Please mention it. I could see a point of transmitting it 3 times for
improved resiliency. But, possible then there should be a signalling
parameter for the number of retransmissions.

However, I don't have a strong view on this. My only concern is if the
ones monitoring the system are fine with basically losing packet loss
rate worth of reports. This might be significant if there is correlation
between the packet loss rate and the reason for failing acquisitions. In
this case one wouldn't learn about these.

> 
>> 
>> Thirdly, does one need to make it clearer that these should be only
>> be sent part of regular compound packets?
>> 
> Yes.
> 
>> M2: Section 6: I am missing an analysis of the potential
>> information leakage from the data reported. What are the risks of
>> not having this encrypted? I think there should be some words on
>> that aspect of the report.
> 
> The information reported in the report could be stolen as any other
> rtcp report data if not encrypted properly. I don't see increased
> risk here. If one is concerned about any leakage and they protect
> their regular rtcp reports, they should protect this xr as well.
> Beyond that, there is not much to offer IMO.

Ok, then I think such a statement should be part of the security
section. That is to show that the information leakage has been
considered but that there is nothing especially dangerous here from a
confidentiality point.

Cheers

Magnus Westerlund

---

From: Eric Friedrich <[email-masked]>
Date: Mon, 28 Mar 2011 11:31:49 -0400

Hi Magnus,
   Thank you for your review and the comments.

On Mar 26, 2011, at 5:47 AM, Magnus Westerlund wrote:

> However,
Our current implementation waits until all information included in the  
report is collected before sending the report. As the timeliness of  
receiving this report is not very important, it is included as part of  
the next regularly scheduled RR. If the viewer should happen to  
terminate the RAMS burst or the entire RTP session before the XR MA  
block is sent, the XR MA is included in the BYE. We don't recommend  
partial reporting because it increases the complexity of processing  
the MA report for no gain in functionality.

> transmit
Yes, with the exception that they may be sent as part of a packet  
containing a BYE as described above to ensure that at least 1 MA  
report is sent per RAMS request. Reading over the draft again, I think  
we also need to state that the XR MA packet should be sent on the  
primary RTP session and not the retransmission session.

Thanks,
Eric