Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Oct 2011 11:37:05 +0200

Thanks for updating the draft,

I have reviewed the updated draft and have the following comments on the
updated version. Some issues are follow up on previous version or on the
actual changes.

1. Section 3.
"The Third Party Loss Report
   message is generated by a RTP system that has not seen the actual
   packet loss and sent following the same timing rule as sending NACK
   defined in [RFC4585]"

I do object against the strict formulation that the TPLR sender hasn't
seen the loss itself. In the case of tree based distribution, the
sending node can have observed the loss first hand. Thus I think it
should say "may not seen the actual packet loss". And I think the second
part of the sentence needs to be split into its own sentence.

Also fix the capitilization of "The" after the e.g. in this sentence. I
would consider thurther splitting rather than have a 5 line sentence.

2. Section 3.
  "The timer value shall be
   based on the observed round-trip time.  A receiver should compute an
   estimate of the round-trip time (RTT) to the sender of TPLR from RTCP
   report round-trip time if available, or its reception time of the
   reflected RTCP FB message (e.g.,NACK), or any other means."

We hade the discussion before but now that you clarified which RTT to be
used, I think it is worth having a discussion if that RTT is the right
one. So you suggest that the RTT between the sender of the TPLR and the
receiver of the message is the most appropriate to use when suppressing
the message. I am not certain that is the case.

Lets consider the use cases. In the case of an intermediary in a
distribution tree sending the TPLR and at the same time sending a NACK
upstream. Then the time until the retransmission reaches the suppressed
receiver is the time from the sending of the NACK up to the
retransmitting entity and all the way down past the TPLR sender to the
suppressed receiver. The receiver may not have a true RTT to the
original media sender as that source appears to live at the TPLR sender,
not further upstream.

Yes, the sender of the TPLR and the receiver might at least have mutual
knowledge of each other, thus the TPLR sender is able to determine the
lowest RTT in the set of receviers thus determining how often to repeat
it to cover additional time requried for the upstream part of the
request. But I do note that these times aren't matching what appear to
be the delays in the systems.

Can we find a better solution?

3. Section 3:
  "To increase the robustness to the loss of a TPLR or of a transmission
   packet, a receiver is allowed to receive additional TPLR for the same
   packet.  In the case the first TPLR is lost and the additional TPLR
   arrives at the receiver, the receiver should immediately refresh the
   timer."

In the second sentence I don't see how the receiver can know that it is
a retransmission. It is simply a TPLR from its perspective if that is lost.

Robustness reasons is only one reason for repeating them the other is
clearly to renew the timer. Thus I think the formulation should be more
generic to make it clear that all receivers should upon reception of a
TPLR refresh the timer for the packets indicated.

4. Section 3.
"The media source or intermediate nodes cannot assume that the use of
   a Third Party Loss Report message actually reduces the amount of
   feedback it receives."

I would recommend that one changes "assume" to "be certain". The
intention is that TPLRs should reduced the feedback, but it is not
guaranteed.

5. Section 4.1:
"and the "SSRC of media source"
   denotes the media sender."

I would expand this, to say the "denotes the media sender of the flow
for which the indicated losses are being suppressed."

This to make it more clear that this field is used to identify the
sequence number space for which the rest identifies which packets where
loss is suppressed.

6. Section 4.2:
"Each entry applies to a different media
   Source that is requested to send a decoder refresh point or that is
   indicated that it lost synchronization with the video stream,
   identified by its SSRC."

and

"SSRC (32 bits):

      The SSRC value of the media source that is requested to send a
      decoder refresh point or that is indicated that it lost
      synchronization with the video stream."

I think this needs to be better defined to identify that these are the
SSRCs of the flows for on which suppression of transmission of PLI or
FIR is suppressed.

7. Section 4.2:
   Seq nr:8bits  Command sequence number.  It is used by the Command
      receiver to check if the Command is repeated.  The sequence number
      space is unique for each pairing of the SSRC of command sender and
      the SSRC of the command receiver.  The sequence number SHALL
      increase by 1 modulo 256 for each new Command.  A repetition SHALL
      NOT increase the sequence number.  The initial value is arbitrary.

Based on that it is defined that upon receiving one of the PSLEI
request, one shouldn't send a FIR or PLI message for a time interval
equal to the RTT between the receiver and the sender of the PSLEI
message does the sequence number field have any meaning? From my
perspective it doesn't matter if it is a new request or not. You are
suppressed from the reception of the message, nothing else.

8. Section 5.
" using the Augmented Backus-Naur Form (ABNF)
   [RFC4585]."

The reference is wrong. The form of the reference implies that the
reference is for ABNF which is RFC 5234, rather than the specific
semantics defined in RFC 4585.

9. Section 5:
The comments in the ABNF is to long. Please break them over several
lines so that they don't violate the max column count of the draft format.

Also "token" needs to have a reference like for the "byte-string".

10. Section 6.2:
" one or more BRSes. one"

Strange punctuation.

11. Section 7.
"Sending the spurious Third Party Loss Report (e.g., the Third Party
   Loss Report with the wrong sequence number of lost packet) that makes
   missing RTP packets can not be compensated."

"that makes" seems to be strange grammer. Please reword.
"... that causes missing RTP packets to not be repaired in a timely
fashion."?

12. Section 8.
   New registration in this registry follows the "Specification
   required" policy as defined by [RFC2434].  In addition, they are
   required to indicate any additional RTCP feedback types, such as
   "nack" and "ack".

The reference should be RFC 5226.

In addition you should check the plural forms that is currently used,
due to the copy and paste from RFC 5104 to singular form as only a
single of each type is present in the FMT registration requests.

You are also missing the the initial values in the "Third Party Loss
Report Messages" registry you create. Both TLLEI and PSLEI should be
part of that registry shouldn't they?

13. Section 10.1:

The following references I think should be moved to the Informative
section instead (10.2). The reason are that they are not strictly needed
for implementation and understanding of the normative parts.

RFC 5760
RFC 3711
RFC 5124

The following isn't used in the text at all:
RFC 3550

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: Qin Wu <[email-masked]>
Date: Tue, 11 Oct 2011 09:40:40 +0800

Hi, Magnus,
Thank for your valuable review, please see my replies belows.

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "IETF AVTCore WG" <[email-masked]>; <[email-masked]>
Sent: Thursday, October 06, 2011 5:37 PM
Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

1. Section 3.

[Qin]: Okay, fixed.

2. Section 3.

[Qin]: It looks to me the round trip time between media source and

 intermediary is trivial if we assume the intermediary is much 

closer to the source, that is why I put the last paragraph in the 

section 3 as follows:

"

In order not to incur a lot of NACK requests due to additional TPLR 

described above, it is recommended that the RTP system sending 

TPLR should be implemented more closer to the source. Also when

 the loss was detected and repair initiated much closer to the source, 

the delay for the receiver to recover from packet loss can be reduced 

through the combination of intermediary feedback to the source and 

Third Party Loss Report downstream.

"

If we look for a better solution, I think we have two possible ways:

The first way is to rely on sender report from media sender to 

calculate the more approximate RTT from media sender to the receiver. 

RTT measurement method follows the same way described in the 

figure 2 of RFC3550.

The second way is to we can allow the intermediary tell the receiver the 

RTT from media source to intermediary itself by sending a new message 

since the intermediary can measure such RTT based on past observation 

and estimation. However for the second way we need to define new 

message or extend TPLR message to carry such RTT.

What do you think? 

3. Section 3:

[Qin]: If the receiver does not keep state for the times the TPLR is

 retransmitted, we can add repetition count field in each FCI entry

 of TPLR feedback message to indicate the times TPLR is retransmitted.

 Particularly in PSLEI Feedback Message, we can reuse seq nr. Field to

 indicate if additional TPLR is retransmitted, which one you think better?

4. Section 3.

[Qin]: Okay.

5. Section 4.1:

[Qin]: Okay.

6. Section 4.2:

and

"SSRC (32 bits):

[Qin]:Okay, will do it in the new version.

7. Section 4.2:

[Qin]: I think we can use seq nr field to indicate the times the TPLR is retransmitted, e.g.,

If the additional TPLR with the same SSRC and different Seq Number is received, the 

receiver knows that it is a retransmission if the receiver keeps state for the previous 

TPLR with the same SSRC.

Also we can replace seq nr. Field with Repetition count field to indicate how many time 

the TPLR is retransmitted. 

8. Section 5.

[Qin]: Okay, fixed.

9. Section 5:

[Qin]: Okay, fixed.

10. Section 6.2:

Strange punctuation.

11. Section 7.

[Qin]: Okay, fixed.

12. Section 8.

[Qin]: Okay, fixed.

13. Section 10.1:

RFC 5760
RFC 3711
RFC 5124

[Qin]: Okay, fixed.

Cheers

Magnus Westerlund

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 11 Oct 2011 15:19:48 +0800

Hi,Magnus:
As regarding if there is better solution, I have some corrections and additional thoughts.
I think 
If the media source is the repair server,
the receiver should set timer to T1=max(the RTT from media source to middlebox sending TPLR, 1/2 of RTT from middlebox to receiver) when the receiver 
receives first TPLR. When the receiver receive addtional TPLR within T1, the receiver should reset the timer to the RTT from media source to middlebox sending TPLR.

If the middlebox is the repair server, the receiver should set the timer to T2=1/2 of RTT from middlebox to receiver when the receiver 
receives first TPLR. When the receiver receive addtional TPLR within T2, the receiver should reset the timer to the T2.

Regards!
-Qin
  ----- Original Message ----- 
  From: Qin Wu 
  To: Magnus Westerlund ; IETF AVTCore WG ; [email-masked] 
  Sent: Tuesday, October 11, 2011 9:40 AM
  Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-07

  Hi, Magnus,

  Regards!
  -Qin
  ----- Original Message ----- 
  From: "Magnus Westerlund" <[email-masked]>
  To: "IETF AVTCore WG" <[email-masked]>; <[email-masked]>
  Sent: Thursday, October 06, 2011 5:37 PM
  Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

  2. Section 3.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Oct 2011 11:08:48 +0200

Hi,

Sorry for the delay in following up.

I have removed the issues which don't need further discussion.

On 2011-10-11 03:40, Qin Wu wrote:
> From: "Magnus Westerlund" <[email-masked]

> “
> ”

>From follow up email:
> Hi,Magnus: As regarding if there is better solution, I have some
> corrections and additional thoughts.
> I think If the media source is the repair server, the receiver should
> set timer to T1=max(the RTT from media source to middlebox sending
> TPLR, 1/2 of RTT from middlebox to receiver) when the receiver
> receives first TPLR. When the receiver receive addtional TPLR within
> T1, the receiver should reset the timer to the RTT from media source
> to middlebox sending TPLR.
> 
> If the middlebox is the repair server, the receiver should set the
> timer to T2=1/2 of RTT from middlebox to receiver when the receiver
> receives first TPLR. When the receiver receive addtional TPLR within
> T2, the receiver should reset the timer to the T2.
> 

Can you express these rules for the receiver as something that is based
on what is observable from the RTP and RTCP traffic? Is when media
server being repair server equal to TPLR sender SSRC = Media SSRC the
TPLR applies on? And if they are not the same it is the second case?

>  indicate if additional TPLR is retransmitted, which one you think better?

How, can the receiver keep state for something it has not seen due to
the initial packet not having been received?

I don't think we need new packet extensions, just clarified rules that
correctly describe what the RTP end-point should do when it sees the
TPLR message.

> the TPLR is retransmitted.

That is possible, but is the repetition count really providing anything?
What is the simplest most straight forward that can work? I think that
is that one simple suppress the source for X time after having receives
a TPLR message indicate that source. So, as long as you get repeat
messages more often than X you continue to be suppressed. Will the
receiver work better to know that it is now suppressed for Y times in a
go because of the same event?

cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Oct 2011 17:27:01 +0800

Hi, Magnus:
Thank for your replies. please see inline.
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "IETF AVTCore WG" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 19, 2011 5:08 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

> TPLR applies on? And if they are not the same it is the second case?

[Qin]: Okay, I think the media source will not be the TPLR sender. 

The receiver should set the timer for the retransmitted data packet when it receive the first TPLR.

If the sender of Retransmitted data packet is the media source, the timer value shall be

based on the observed time difference between the round-trip time from the receiver to 

the original media source and the round-trip time from the receiver to the sender of the TPLR.  

A receiver should compute an estimate of the round-trip time (RTT) to the original media source 

from Sender Report (SR) packets for the original stream, or any other means. The round-trip time 

from the receiver to the sender of the TPLR can be calculated from RTCP report round-trip time 

if available, or any other means.

> correctly describe what the RTP end-point should do when it sees the

[Qin]; Okay, I Agree with that, see below.

> go because of the same event?

[Qin]: I agree that adding new field is a little overdesign and does not too much value.

 Your proposal is more straightforward and looks good to me. I will make it clear in the text.

---

From: Roni Even <[email-masked]>
Date: Mon, 24 Oct 2011 16:42:25 +0200

Hi Magnus,
Maybe we can add a recommendation for SSM to use the round trip sub report
block specified in section 7.1.6 of RFC 5760
(http://tools.ietf.org/html/rfc5760 ) to distribute the RTT from the
distribution source to the receivers.

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Wednesday, October 19, 2011 11:09 AM
> To: Qin Wu
> Cc: IETF AVTCore WG; draft-ietf-avtcore-feedback-supression-
> [email-masked]
> > [Qin]: I think we can use seq nr field to indicate the times the TPLR
> is
> > retransmitted, e.g.,
> >
> > receiver knows that it is a retransmission if the receiver keeps
> state
> > for the previous
> >
> > TPLR with the same SSRC.
> >