Subject: [AVT] Commments on draft-ietf-avt-post-repair-xr-01

From: "Alan Clark" <[email-masked]>
Date: Mon, 13 Oct 2008 11:51:04 -0400

Technical comments:

1. Assume that RTP is being used to encapsulate a multiprogram transport
stream or a higher rate video stream - giving (say) a packet rate of 5k pps
or higher.  In this case the RTP sequence number wraps every 13 seconds -
which either means that there needs to be a report every 13 seconds or there
is potential ambiguity on the interpretation of the ending sequence number
in the report; this may also lead to a high reporting volume in multicast
systems as there may be around N/10 .. N/50 reports per second.

2. Does this draft need to specify how it is applied in multicast systems,
which would seem to be a primary application area.  The report would be
identifiable from the SSRC in the report block and the (NAT'd) source IP
address of the report sender (RTP destination) - presumably this could be
used to correlate reports from multiple endpoints to identify where the
issue is in the multicast tree?

Text comments:

3. In "3. Post-Repair Loss RLE Report Block"

The Post-[R]epair Loss RLE Report Block is similar to the Loss RLE Report
Block defined in [RFC3611 <http://tools.ietf.org/html/rfc3611> ].  [The
report format is shown below in Figure 1.]
 
   o  begin_seq:  16 bits
 
      The first [RTP] sequence number [to which this Report refers].
 
   o  end_seq:  16 bits
 
      The last [RTP] sequence number [to which this Report refers plus one].
 
4. In "6. IANA Considerations"
 
   Block type value 10 in the IANA RTCP XR Block Type Registry to
"Post-repair Loss RLE Report Block." has been (provisionally) assigned to
this Report. The SDP [RFC4566 <http://tools.ietf.org/html/rfc4566> ]
"rtcp-xr" parameter "post-repair-loss-rle" has been (provisionally) assigned
to this Report in the IANA RTCP XR SDP Parameters Registry.
 
5. RFC2119 keywords
 
The draft refers to RFC2119 keywords but does not use any of them - are
there any elements of the draft that would benefit from SHOULD/MAY.?  

Alan Clark

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 13 Oct 2008 12:58:09 -0700

Hi Alan,
 
Thanks for the comments. I will look at the text-related comments.
Regarding other comments:
 
1- This is a common problem with sending RTCP reports for all
high-bandwidth RTP flows. There is nothing specific to this XR report,
is there? One suggestion here could be that the post-repair XR reports
could only be requested from (or sent by) the receivers that are
experiencing problems despite the loss-repair functionality. In other
words, it could be used as a diagnostics tools rather than a regular
tool, if the report bandwidth consumption is a concern.
 
2- Multicast is certainly a use case, of course, but it is not the only
use case for this XR report. Identifying the problematic area(s) in
multicast distribution is also important and could be achieved through
processing of the regular receiver reports or other extended reports. Is
there any specific implication on the post-repair reports?
 
IMO explaining how fault isolation in multicast distribution is out of
scope, here. Any comments?
 
-acbegen

________________________________

	From: Alan Clark [mailto:[email-masked]] 
	Sent: Monday, October 13, 2008 8:51 AM
	To: Ali C. Begen (abegen)
	Cc: [email-masked]
	Subject: Commments on draft-ietf-avt-post-repair-xr-01

	Technical comments:

	1. Assume that RTP is being used to encapsulate a multiprogram
transport stream or a higher rate video stream - giving (say) a packet
rate of 5k pps or higher.  In this case the RTP sequence number wraps
every 13 seconds - which either means that there needs to be a report
every 13 seconds or there is potential ambiguity on the interpretation
of the ending sequence number in the report; this may also lead to a
high reporting volume in multicast systems as there may be around N/10
.. N/50 reports per second.

	2. Does this draft need to specify how it is applied in
multicast systems, which would seem to be a primary application area.
The report would be identifiable from the SSRC in the report block and
the (NAT'd) source IP address of the report sender (RTP destination) -
presumably this could be used to correlate reports from multiple
endpoints to identify where the issue is in the multicast tree?

	Text comments:

	The Post-[R]epair Loss RLE Report Block is similar to the Loss
RLE Report Block defined in [RFC3611
<http://tools.ietf.org/html/rfc3611> ].  [The report format is shown
below in Figure 1.]
	 
	   o  begin_seq:  16 bits
	 
	      The first [RTP] sequence number [to which this Report
refers].
	 
	   o  end_seq:  16 bits
	 
	      The last [RTP] sequence number [to which this Report
refers plus one].

	   Block type value 10 in the IANA RTCP XR Block Type Registry
to "Post-repair Loss RLE Report Block." has been (provisionally)
assigned to this Report. The SDP [RFC4566
<http://tools.ietf.org/html/rfc4566> ] "rtcp-xr" parameter
"post-repair-loss-rle" has been (provisionally) assigned to this Report
in the IANA RTCP XR SDP Parameters Registry.
	 
	5. RFC2119 keywords
	 
	The draft refers to RFC2119 keywords but does not use any of
them - are there any elements of the draft that would benefit from
SHOULD/MAY...?  

	Alan Clark

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Oct 2008 09:53:12 +0200

> tool, if the report bandwidth consumption is a concern.

Although it is a re-occurring problem, in most cases where there has
been a clear issue one has dealt with it by using extended sequence
number space. Considering the application of this XR packet and the fact
that they report post FEC I think changing begin_seq and end_seq to 32
bit extended sequence number fields seems motivated. That way it is
possible to be clear on what one reports on even if there are 30 seconds
or more between RTCP packets and there are more than one loss in this
interval. However, I do notice that for long enough distances between
the losses using individual XR report blocks becomes more efficient. But
you need the extended sequence number to indicate where in the sequence
the report blocks belong. So some note on this might also be beneficial.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Oct 2008 11:54:11 -0700

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Tuesday, October 14, 2008 12:53 AM
> Cc: Alan Clark; [email-masked]
> Subject: Re: [AVT] Commments on draft-ietf-avt-post-repair-xr-01
> 
> Although it is a re-occurring problem, in most cases where 
> there has been a clear issue one has dealt with it by using 
> extended sequence number space. Considering the application 
> of this XR packet and the fact that they report post FEC I 
> think changing begin_seq and end_seq to 32 bit extended 
> sequence number fields seems motivated. That way it is 
> possible to be clear on what one reports on even if there are 
> 30 seconds or more between RTCP packets and there are more 
> than one loss in this interval. However, I do notice that for 
> long enough distances between the losses using individual XR 
> report blocks becomes more efficient. But you need the 
> extended sequence number to indicate where in the sequence 

Hi Magnus,

We have a design choice here. The current proposal is largely intended to be used with the existing loss RLE defined in 3611. Having the same format makes everybody's life easier in the implementation. Comparing the pre and pos-repair loss RLEs will be much easier when we have identical report formats. Do you think using extended seqnums and changing the format is worth it?

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 Oct 2008 22:54:48 +0100

On 16 Oct 2008, at 19:54, Ali C. Begen (abegen) wrote:
...
> We have a design choice here. The current proposal is largely  
> intended to be used with the existing loss RLE defined in 3611.  
> Having the same format makes everybody's life easier in the  
> implementation. Comparing the pre and pos-repair loss RLEs will be  
> much easier when we have identical report formats. Do you think  
> using extended seqnums and changing the format is worth it?

I'd say it's more important that this uses the same format as the RFC  
3611 loss RLE blocks, since that makes it simple to compare pre- and  
post-repair values. If there are limitations of the RFC 3611 format,  
then new XR report blocks can be defined, both pre- and post-repair,  
but that's separate to this draft.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 Oct 2008 23:12:00 +0100

On 13 Oct 2008, at 16:51, Alan Clark wrote:
...
> Text comments:
>
>
>
> 3. In “3. Post-Repair Loss RLE Report Block”
>
>
>
> The Post-[R]epair Loss RLE Report Block is similar to the Loss RLE  
> Report Block defined in [RFC3611].  [The report format is shown  
> below in Figure 1.]
>
>    o  begin_seq:  16 bits
>

The current text matches RFC 3611. I understand the aim of the  
clarification, but think consistency between the specifications more  
important than fine-tuning the wording.

> 4. In “6. IANA Considerations”
>
> "Post-repair Loss RLE Report Block." has been (provisionally)  
> assigned to this Report. The SDP [RFC4566] “rtcp-xr” parameter  
> "post-repair-loss-rle" has been (provisionally) assigned to this  
> Report in the IANA RTCP XR SDP Parameters Registry.

I'm not sure why "(provisionally)" is being added here. This draft is  
instructing IANA to make the assignment, not documenting a  
provisional assignment.

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Oct 2008 17:42:46 +0200

> We have a design choice here. The current proposal is largely intended to be used with the existing loss RLE defined in 3611. Having the same format makes everybody's life easier in the implementat…

My suggestion was only to extend the start and stop sequence number
spaces. That way you will now for what time period the report is, even
if there are wraps going on. Then you can write some recommendation
about when it is suitable to use multiple report blocks rather than
filling in the no loss run-length encoding chunks to cover the distance.

That way at least the issue of where the data belong for high packet
rate applications becomes moot.

Cheers

Magnus Westerlund