Subject: Re: [AVT] draft-ietf-avt-post-repair-rtcp-xr-02

From: <[email-masked]>
Date: Sat, 18 Oct 2008 19:26:07 +0100

Hi Ali, All,

1) My comment about ambiguity of reception/recovery status and the
impact on sequence numbers *is* addressed in the Introduction para 3.
However I'd expected that you would recommend that the report should be
sent when the system normally expects to send a report (e.g. timer
giving uniform distribution 2.5s-7.5s between reports). Then the
post-repair block would fix the ambiguity by setting begin_seq and
end_seq (and the RLE chunk endpoints) to lower values (if necessary)
than the begin_seq and end_seq of the metrics which report on the
primary stream - this may well not be the best scheme. I note that
you've taken the other approach, of delaying the post-repair report
until there is no ambiguity due to repair procedures in active use, but
your exact proposal is not totally clear. Do you expect that
implementations will delay the whole report (post repair metrics and
others) until there is no ambiguity due to repair? If so, will the
metrics for the primary stream have begin_seq and end_seq equal to those
of the post-repair metric? Or should the post-repair block be sent
separately and later!? Or will the metrics for the primary stream
advance their reports to cover all packets received on the primary
stream, whilst the system waits for the ambiguity to be resolved? What
about cases of high packet loss where the repair mechanism could be
continuously active, so the post-repair metric could be delayed
indefinitely? Or, is the intention to fix begin_seq and end_seq for the
primary stream, and delay the whole RTCP report just long enough to
resolve the ambiguity for the post-repair metrics for exactly the same
span (bearing in mind that the delay may be >RTT for RFC4588)? Sorry to
sound obsessive but I envisage complex code in systems receiving the
RTCP, if the guidance is not simple, unambiguous and preferably
mandatory

2) The nit requesting clarification that sequence numbers are those of
the primary stream is fixed.

3) Re my comment about partially repaired packets, the parenthesis "(at
the packet level)" in Introduction para 3 is slightly cryptic, if it's
intended to address the comment. RFC5109 is one of your two main
application references, and quite a lot of it is about partial repair,
even if as you said there are no implementations - to date - which use
this feature. I expected a statement either that scope of the current
draft doesn't include systems which attempt partial repair, or some
implementation guidance e.g. that partially repaired packets are counted
as unrepaired.

If you think I'm giving you a hard time here, you can get back when I
start submitting the drafts derived from RTCP HR ;)

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: Sat, 18 Oct 2008 23:13:18 -0700

Hi Geoff,

I must feel lucky as we have a diligent reader like you.

> 1) My comment about ambiguity of reception/recovery status 
> and the impact on sequence numbers *is* addressed in the 
> Introduction para 3.

Y.

> However I'd expected that you would recommend that the report 
> should be sent when the system normally expects to send a 
> report (e.g. timer giving uniform distribution 2.5s-7.5s 
> between reports). Then the post-repair block would fix the 
> ambiguity by setting begin_seq and end_seq (and the RLE chunk 
> endpoints) to lower values (if necessary) than the begin_seq 
> and end_seq of the metrics which report on the primary stream 

This is one approach and certainly possible. As you indicated, if the
time window for loss repair is pretty slim, the begin/end seqnums in
both pre and post-repair reports could be the same or close to each
other. If the time window is pretty large, of course the begin/end
seqnums will be totally off.

> - this may well not be the best scheme. I note that you've 
> taken the other approach, of delaying the post-repair report 
> until there is no ambiguity due to repair procedures in 
> active use, but your exact proposal is not totally clear. Do 

What we are saying is that the post-repair needs to be reported only for
those packets that have no more repair hopes. If the user wants to have
both the pre and post-repair reports for the same set of packets in the
same RTCP report, that may require delaying the pre-repair report. If
the user does not care whether the same or different packets are
reported in the pre and post-repair reports (carried in the same RTCP
report), it does not have to delay anything. Every time an RTCP report
is being prepared, the user selects a set of packets for the pre-repair
report and possibly a different set of packets for the post-repair
report.

> you expect that implementations will delay the whole report 
> (post repair metrics and
> others) until there is no ambiguity due to repair? If so, 
> will the metrics for the primary stream have begin_seq and 
> end_seq equal to those of the post-repair metric? Or should 
> the post-repair block be sent separately and later!? Or will 
> the metrics for the primary stream advance their reports to 
> cover all packets received on the primary stream, whilst the 
> system waits for the ambiguity to be resolved? What about 

I believe these are implementation issues. One can prefer one of these
approaches (or a different one if that works better) depending on how
they want to implement this stuff. 

> cases of high packet loss where the repair mechanism could be 
> continuously active, so the post-repair metric could be 
> delayed indefinitely? Or, is the intention to fix begin_seq 

The focus here is on the real-time applications as we use RTP transport.
So, a loss repair that will last beyond a few seconds is not much a use
here, anyway. Even if that's the case, the application may always put an
upper bound (of its own choice) on how long it will wait before it gives
up.

> and end_seq for the primary stream, and delay the whole RTCP 
> report just long enough to resolve the ambiguity for the 
> post-repair metrics for exactly the same span (bearing in 
> mind that the delay may be >RTT for RFC4588)? Sorry to sound 
> obsessive but I envisage complex code in systems receiving 
> the RTCP, if the guidance is not simple, unambiguous and 
> preferably mandatory

The code does not have to be complex. As long as your sender understands
what your receiver is reporting, everything should work fine. RFC 3611
does not give specific timing rules (or rules selecting the begin and
end seqnums) for sending out regular loss rles, either. I suppose the
authors of 3611 also thought that these were implementation issues and
did not say specific things about them.

As the authors, we feel the same way for this draft. There is no single
best solution that will work for everyone and we let the implementer
decide what to do.

> 2) The nit requesting clarification that sequence numbers are 
> those of the primary stream is fixed.

Y.
 
> 3) Re my comment about partially repaired packets, the 
> parenthesis "(at the packet level)" in Introduction para 3 is 
> slightly cryptic, if it's intended to address the comment. 

We also changed the term "error repair" to "loss repair." I believe it
now clearly identifies that we are working at the packet level, not bit
level. I thought you'd notice that.

If you will feel more comfortable, I can remove the ref to 5109 and
replace it with one of our new FEC drafts. Since the ref is not
normative, I should be able to do that. We simply used 5109 as it was
already an RFC, not because we advocate for it.

> RFC5109 is one of your two main application references, and 
> quite a lot of it is about partial repair, even if as you 
> said there are no implementations - to date - which use this 
> feature. I expected a statement either that scope of the 
> current draft doesn't include systems which attempt partial 
> repair, or some implementation guidance e.g. that partially 
> repaired packets are counted as unrepaired.

Again removing 5109 should make this clear. But, to emphasize the point,
I can explicitly add your statement.

> If you think I'm giving you a hard time here, you can get 
> back when I start submitting the drafts derived from RTCP HR ;)

I don't think I will do as well as you did ;)

-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: Sun, 19 Oct 2008 21:36:07 +0100

Hi Ali, All,

Comments on your comments, inline. I've cut some of the text, hope
there's still enough to 
give a context.

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: 19 October 2008 07:13
> To: Hunt,RG,Geoff,DMM R; Dong Hsu (dohsu); Michael Lague 
> (mlague); [email-masked]
> Subject: RE: draft-ietf-avt-post-repair-rtcp-xr-02
> 

> upper bound (of its own choice) on how long it will wait 

OK, but the mechanism should behave sensibly on occasions when
the network behaves badly and the repair mechanism is busy.

> best solution that will work for everyone and we let the implementer

There's a question about approach here. A loose specification might be 
better than a tight specification of a poor design, but any loose 
specification will make inter-operability harder to achieve. The
"complex
code" concern was for a system receiving the block, trying to work out
what 
interpretation of the spec a given sender had chosen, before it can
start
to use the metrics.
But I think I've used all my bandwidth on this - let's see if anyone
else
wants to comment. If there is any consensus for a tighter spec, I do
have a
preference for one of the options, but I'll keep it quiet for now.

> level. I thought you'd notice that.

Fair cop :)
 
> already an RFC, not because we advocate for it.

I definitely wasn't asking for removal of RFC5109. Only pointing out a
possible issue with applying your scheme to one of its features.

> I can explicitly add your statement.

IMO leaving RFC5109 in, and making one of these statements, would be 
better than ignoring the issue, particularly when your technique is
applicable to common RFC5109 implementations which work at the whole-
packet level. Adding the statement seems a low-cost solution.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 19 Oct 2008 18:57:58 -0700

Hi Geoff,

[Snip]

> the network behaves badly and the repair mechanism is busy.

Agree.

> interpretation of the spec a given sender had chosen, before it can

I agree but you need to know what the report owner puts in its report
and how it puts that information in the report anyway. For example, 3611
does say that there are multiple options for RLE encoding and the choice
is up to the implementation. IMO, the extended reports (3611) have some
issues with interoperability in their nature anyway. As we follow 3611
in our draft, we will inherent those issues. 

> preference for one of the options, but I'll keep it quiet for now.

Sounds good. It would be a good idea to listen to folks who have
implemented regular RLEs at some point in their lives.
 
[snip]

> packet level. Adding the statement seems a low-cost solution.

OK, we will keep 5109 and add your statement.

BR,
-acbegen