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

[Qin Wu <[e-mail]>]

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

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


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.

[Qin]: Okay, fixed.

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?

[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:
  "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.



[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.
"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.



[Qin]: Okay.



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.



[Qin]: Okay.

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.



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

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.



[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.
" 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.



[Qin]: Okay, fixed.

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".



[Qin]: Okay, fixed.

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."?



[Qin]: Okay, fixed.


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?



[Qin]: Okay, fixed.

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



[Qin]: Okay, fixed.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------

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