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

From: <[email-masked]>
Date: Mon, 13 Oct 2008 17:46:40 +0100

Hi Ali, All,

Two comments on draft-ietf-avt-post-repair-rtcp-xr-01 following the
extension of the WGLC. I think these are both areas where an implementer
would be uncertain what to code, on the basis of the current draft.

1) The new block defines its reporting window with fields begin_seq and
end_seq but for both of the repair techniques mentioned (RFC4588 and
RFC5109) there is ambiguity about what values to put in these fields.
For example, for RFC4588, at the instant the block is generated a packet
might have been identified as missing from the original stream and a
retransmission requested, but it is not yet known whether the
retransmission will successfully recover the missing packet. For RFC5109
(even with only a single level of protection), at the instant the block
is generated a media packet could have been identified as missing, but
the receiver has not yet seen all the (media and FEC) packets associated
with that media packet for protection purposes, so it is not yet certain
whether it will be recoverable. For a metric which just *counts*
irrecoverably lost packets, this problem might be solved in a simple way
by counting those packets which the receiver finally gave up hope on, in
the stated interval. For a detailed RLE report it's more difficult - you
could have some later packets known to have been received correctly, but
earlier ones where the status is still unknown. In other words, how do
the begin and end packets of the reported chunk data relate to the
reported begin_seq and end_seq?

2) The draft assumes a packet is either lost/broken, or repaired, at
packet granularity. However some repair techniques including RFC5109
allow partial repair of packets - a selling point of RFC5109 is better
repair of earlier data in each packet where codecs typically place "more
important" data, loss of which is more detrimental to the user
experience. This might be by protecting only the first few octets, or
protecting the first few octets more strongly than the rest of the
packet. How should the new block type report a partially repaired
packet?

Best regards
Geoff

Geoff Hunt 
BT Design

Tel: 01473 608325
Email: [email-masked]
Web: www.bt.com
This email contains BT information, which may be privileged or
confidential.
It is meant only for the individual(s) or entity named above. If you are
not the intended
recipient, note that disclosing, copying, distributing or using this
information
is prohibited. If you have received this email in error, please let me
know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

_______________________________________________
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 13:09:18 -0700

Hi Geoff,

> Hi Ali, All,
> 
> Two comments on draft-ietf-avt-post-repair-rtcp-xr-01 
> following the extension of the WGLC. I think these are both 
> areas where an implementer would be uncertain what to code, 
> on the basis of the current draft.

Thanks for the comments.

> 1) The new block defines its reporting window with fields 
> begin_seq and end_seq but for both of the repair techniques 
> mentioned (RFC4588 and
> For example, for RFC4588, at the instant the block is 
> generated a packet might have been identified as missing from 
> the original stream and a retransmission requested, but it is 
> not yet known whether the retransmission will successfully 
> recover the missing packet. For RFC5109 (even with only a 
> single level of protection), at the instant the block is 
> generated a media packet could have been identified as 
> missing, but the receiver has not yet seen all the (media and 
> FEC) packets associated with that media packet for protection 
> purposes, so it is not yet certain whether it will be 
> recoverable. For a metric which just *counts* irrecoverably 
> lost packets, this problem might be solved in a simple way by 
> counting those packets which the receiver finally gave up 
> hope on, in the stated interval. For a detailed RLE report 
> it's more difficult - you could have some later packets known 
> to have been received correctly, but earlier ones where the 
> status is still unknown. In other words, how do the begin and 
> end packets of the reported chunk data relate to the reported 
> begin_seq and end_seq?

The implementation should choose to generate these reports for the media
packets that the receiver has lost all the recovery hopes. The purpose
of this RLE is to show the repair performance after "all" repair is
done. In other words, if there is still some repairing in progress,
sending this report would not make much sense as it would include wrong
information.

If you think it is a good idea, we can add some text around this. We
should probably use "SHOULD" or "RECOMMENDED" to avoid the
implementation confusions.

> 
> 2) The draft assumes a packet is either lost/broken, or 
> repaired, at packet granularity. However some repair 
> techniques including RFC5109 allow partial repair of packets 
> - a selling point of RFC5109 is better repair of earlier data 
> in each packet where codecs typically place "more important" 
> data, loss of which is more detrimental to the user 
> experience. This might be by protecting only the first few 
> octets, or protecting the first few octets more strongly than 
> the rest of the packet. How should the new block type report 
> a partially repaired packet?

I am not aware of any 5109 implementations or any other one that uses
partial recovery at the packet level. There may be some now or in the
future and I believe your concern is valid. However, this is an XR
report like the previous ones that work on the packet level and RTP does
not readily have any method to identify sub-packet components so there
is not much RTCP can do here.

If 5109-like implementations gain importance in the future, then we can
probably develop a new reporting mechanism. Such a mechanism will be
very different from what we have for post-repair RLE and will deserve to
be registered as a separate report block type.

BR,
-acbegen

> 
> Best regards
> Geoff
> 
> Geoff Hunt
> BT Design
> 
> Tel: 01473 608325
> Email: [email-masked]
> Web: www.bt.com
> This email contains BT information, which may be privileged 
> or confidential.
> It is meant only for the individual(s) or entity named above. 
> If you are not the intended recipient, note that disclosing, 
> copying, distributing or using this information is 
> prohibited. If you have received this email in error, please 
> let me know immediately on the email address above. Thank you.

---

From: <[email-masked]>
Date: Tue, 14 Oct 2008 10:08:00 +0100

Hi Ali, All,

Follow-up inline below. One new nit - it's fairly clear that the
sequence numbers referred to 
must be sequence numbers of the primary stream, but the draft doesn't
state this. The 
repair techniques may involve parallel RTP sessions with independent
sequences, so the 
draft could be explicit that sequence numbers are those of the primary
stream.

Best regards
Geoff

Geoff Hunt 
BT Design

Tel: 01473 608325
Email: [email-masked]
Web: www.bt.com

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: 13 October 2008 21:09
> To: Hunt,RG,Geoff,DMM R; Dong Hsu (dohsu); Michael Lague 
> (mlague); [email-masked]
> Subject: RE: Comments on draft-ietf-avt-post-repair-rtcp-xr-01
> 
> Hi Geoff,
> 
> > Hi Ali, All,
> > 
> > following the extension of the WGLC. I think these are both areas 
> > where an implementer would be uncertain what to code, on 
> the basis of 
> > the current draft.
> 
> Thanks for the comments.
> 
>  
> > 1) The new block defines its reporting window with fields begin_seq 
> > and end_seq but for both of the repair techniques mentioned 
> (RFC4588 
> > and
> > For example, for RFC4588, at the instant the block is generated a 
> > packet might have been identified as missing from the 
> original stream 
> > and a retransmission requested, but it is not yet known whether the 
> > retransmission will successfully recover the missing packet. For 
> > RFC5109 (even with only a single level of protection), at 
> the instant 
> > the block is generated a media packet could have been identified as 
> recoverable. For 
> > a metric which just *counts* irrecoverably lost packets, 
> this problem 
> > might be solved in a simple way by counting those packets which the 
> > receiver finally gave up hope on, in the stated interval. For a 
> > detailed RLE report it's more difficult - you could have some later 
> > packets known to have been received correctly, but earlier 
> ones where 
> > the status is still unknown. In other words, how do the 
> begin and end 
> > packets of the reported chunk data relate to the reported begin_seq 
> > and end_seq?
> 
> The implementation should choose to generate these reports 
> for the media packets that the receiver has lost all the 
> recovery hopes. The purpose of this RLE is to show the repair 
> performance after "all" repair is done. In other words, if 
> there is still some repairing in progress, sending this 
> report would not make much sense as it would include wrong 
> information.
> 
> If you think it is a good idea, we can add some text around 
> this. We should probably use "SHOULD" or "RECOMMENDED" to 
> avoid the implementation confusions.
>
 
I guess it's obvious that the span of the RLE chunks in a report 
block *starts* either at the first packet of the connection, or 
at the packet after the last reported packet of the preceding report, 
and begin_seq would reflect this. I think you're saying here that the 
span of the RLE chunks in a report block should *end* at the packet 
immediately preceding the earliest packet whose reception/recovery 
status is still ambiguous. The value of end_seq (which must point 
to the packet after the last packet included in the RLE span) would 
be the sequence number of this earliest packet whose status is still 
ambiguous. This value of end_seq could be significantly behind the 
sequence number of the "next packet expected" in the primary stream, 
if network conditions mean that the recovery mechanism is in active 
use. Is this correct? If so could you put in some words to clarify?

> repaired, at 
> > allow partial repair of packets
> > - a selling point of RFC5109 is better repair of earlier 
> data in each 
> > packet where codecs typically place "more important"
> experience. This 
> > might be by protecting only the first few octets, or protecting the 
> > first few octets more strongly than the rest of the packet. 
> How should 
> > the new block type report a partially repaired packet?
> 
> I am not aware of any 5109 implementations or any other one 
> that uses partial recovery at the packet level. There may be 
> some now or in the future and I believe your concern is 
> valid. However, this is an XR report like the previous ones 
> that work on the packet level and RTP does not readily have 
> any method to identify sub-packet components so there is not 
> much RTCP can do here.
> 
> If 5109-like implementations gain importance in the future, 
> then we can probably develop a new reporting mechanism. Such 
> a mechanism will be very different from what we have for 
> post-repair RLE and will deserve to be registered as a 
> separate report block type.

OK, it's very simple, the scope of the new block is restricted to 
reporting repair at the whole-packet level, and the draft could 
have a few words to say so. 

> > If you are not the intended recipient, note that 
> disclosing, copying, 
> > distributing or using this information is prohibited. If you have 
> > received this email in error, please let me know immediately on the 
> > email address above. Thank you.
> > Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
> > England no: 1800000
> > 
> > 
> > 
>

---

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

> Hi Ali, All,
> 
> Follow-up inline below. One new nit - it's fairly clear that 
> the sequence numbers referred to must be sequence numbers of 
> the primary stream, but the draft doesn't state this. The 
> repair techniques may involve parallel RTP sessions with 
> independent sequences, so the draft could be explicit that 
> sequence numbers are those of the primary stream.

Will fix this. Thanks.
 
> begin_seq 
> > The implementation should choose to generate these reports for the 
> > media packets that the receiver has lost all the recovery 
> hopes. The 
> > purpose of this RLE is to show the repair performance after "all" 
> > repair is done. In other words, if there is still some repairing in 
> > progress, sending this report would not make much sense as it would 
> > include wrong information.
> > 
> this. We 
> I guess it's obvious that the span of the RLE chunks in a 
> report block *starts* either at the first packet of the 
> connection, or at the packet after the last reported packet 
> of the preceding report, and begin_seq would reflect this. I 
> think you're saying here that the span of the RLE chunks in a 
> report block should *end* at the packet immediately preceding 
> the earliest packet whose reception/recovery status is still 
> ambiguous. The value of end_seq (which must point to the 
> packet after the last packet included in the RLE span) would 
> be the sequence number of this earliest packet whose status 
> is still ambiguous. This value of end_seq could be 
> significantly behind the sequence number of the "next packet 
> expected" in the primary stream, if network conditions mean 
> that the recovery mechanism is in active use. Is this 
> correct? If so could you put in some words to clarify?

Yes, what you are saying makes sense. Also note that the client, if it
prefers, may send reports that are disjoint in terms of seqnums. I don't
think we need to require contiguous seqnums. This will probably be
implementation specific.

> that uses 
> > report like the previous ones that work on the packet level and RTP 
> > does not readily have any method to identify sub-packet 
> components so 
> > there is not much RTCP can do here.
> > 
> > If 5109-like implementations gain importance in the future, then we 
> > can probably develop a new reporting mechanism. Such a 
> mechanism will 
> > be very different from what we have for post-repair RLE and will 
> > deserve to be registered as a separate report block type.
> 
> OK, it's very simple, the scope of the new block is 
> restricted to reporting repair at the whole-packet level, and 
> the draft could have a few words to say so. 

Will add this as well.

BR,
-acbegen