Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Qin Wu <[e-mail]>]

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

>----- Original Message ----- 
>From: "Magnus Westerlund" <[e-mail]>
>To: <[e-mail]>; <[e-mail]>
>Sent: Thursday, September 01, 2011 10:52 PM
>Subject: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt


>Hi,

>I have reviewed this last version and have some comments.

>1. Why is the copyright boilerplate indicating that there is copyrighted
>material that is from prior to 2008 change of the boiler plate? Can you
>please point to what material that exist in the document that is prior
>to this change and where the authors has been unable to acquire the rights?

>I think we really should avoid using the exception if there is no reason
>for it. Otherwise we just make the future reference puzzle that more
>difficult.

[Qin]:Your are right. I am using the wrong copyright boilerplate. 
 IPR attribute in the "<rfc>" tag  within boilerplat should be set to 
"trust200902"instead of "pre5378Trust200902"

>2. Section 3, second paragraph.
>Lack of space after RFC4585 reference.

[Qin]: fixed, thanks.

>3. Section 3, third paragraph:
>Systems that
>   receive a Third Party Loss Report SHOULD NOT initiate their own
>   additional Third Party Loss Report messages for the same packet
>   sequence numbers.

>Is it really systems, isn't it rather Intermediaries that this sentence
>applies to? If you are an end-point you have no down stream direction to
>send the TPLR message to. And if you sent it upstream or to a feedback
>target that is a different action. OR should system say "RTP node" if it
>truly should apply to all RTP nodes?

[Qin]:Firstly, I do not think it is important, the system can be RTP node. Secondly , 
I think TPLR message was not meant to be sent from downstream host end-point in upstream
Direction since sending TPLR message is used to suppress all the downstream host end points 
from sending unnecessary RTCP messages. The example of the system here can be media source 
or intermediaries. The RTP end device that is receiving RTP packet is not necessary to be counted
 as System. In order to avoid ambiguity, how about change system as
"RTP system in the network or RTP node in the network"?

>4. Third paragraph:

>or they may generate their own Third Party Loss
> Report that reports a set of the losses they see, which are different
> from ones reported in the Third Party Loss report they received.

>What about the original Third party loss report message, should that be
>suppressed, or still be forwarded?

[Qin]: The original TPLR message receiving from upstream direction should be forwarded. 
But for the loss that is not reported in the original TPLR message, the intermediary should 
generate new TPLR to convey them.
It looks the current descrption doesn't reflect this very well. How about change as follows:
Original text:
"
They may either simply forward the Third Party
   Loss Report message, or they may generate their own Third Party Loss
   Report that reports a set of the losses they see, which are different
   from ones reported in the Third Party Loss report they received. 
"
New text:
"
They should simply forward the Third Party
   Loss Report message received from upstream direction, additionally, they may generate their own Third Party Loss
   Report that reports a set of the losses they see, which are different
   from ones reported in the Third Party Loss report they received. 
"

>5. Section 3, fourth paragraph:
>I am trying to get my head around the implications of not being explicit
>about the time feedback suppression lasts. And I don't quite get how it
>works from either side.

>As the sender of of Third party loss report, the first message is pretty
>straight forward. It suppresses all receiver that get it for one of
>their Retransmission timeout intervals. As a sender I have no idea how
>long that interval are in the various receivers implementations. It is
>likely a RTT + some fudge time for the source being reported. The issue
>is that the RTT to the orignal source, rather than the third party
>reporting the loss is quite different, thus not reflecting the interval
>before the Third party expects to get the packet for forwarding.

[Qin]: Firstly, the normal behavior of TPLR sender is the same as for sending a NACK and not
receiving a repair. I think that the paragraph was about the case when the
downstream receiver received a suppression message but expected to get a
repair packet w=even though it did not sent a NACK.

Secondly, it is true that the interval to get TPLR varies from different receivers implementation. 
However the senders of TPLR does not need to know how long it take for receiver to get TPLR 
message, instead the receiver should more concerns the interval to recieve TPLR from the sender 
of TPLR. In other words, upon being told about the packet loss, TPLR senders should immediately 
create, send TPLR to the recievers. The other intermediary between sender and receiver just simply 
forward TPLR message to the recievers. 

For reciever who concerns the interval, they should know how to choose appropirate interval for timer. 
one way is to choose the longest time to receive TPLR, i.e., one RTT to recieve TPLR from source since
 the media source also can be the sender of TPLR. Does this clarification make sense to you? 

>The next question is if and in that case when the node should send an
>additional TPLR message. Should it wait for receiving a first NACK and
>expect a storm of others before the suppression has reached the others.
>Should it try to estimate the lowest suppression time to any of the down
>stream receivers?

[Qin]: 
 In most case, the node in the middle does not need to send additional 
TPLR if upstream node has been told about all the packet loss event.
 Unless the upsteam node miss one or more than one packet loss, the
 node in the middle between upstream node and the receive may send 
additional TPLR. However same as the upstream node sending TPLR,
 the node in the middle does not need to wait for a certain time to send 
TPLR. upon been told about the loss and make sure the loss is not reported 
by upstream node, the node should create and send additional TPLR immediately. 
Does it make sense?

>As a receiver, when I receive an additional TPLR message, do I
>immediately restart the timer, or do I wait until the timer expires and
>then refreshes it for one new interval?

[Qin]: First, I think the reciever behavior follows the feedback suppression
 rule defined in RFC4585. secondly, I think the timer is restarted per each new loss, if the
 reciever receive additinal TPLR message, which report the different loss, the
 reciever should restart the timer immediately. However if additinal TPLR report 
the same loss as the previous TPLR, the receiver should wait untile the timer expires 
and then refreshes it for one new interval.

>I think there need to be significant clarification on the nodes behavior
>regarding how long the suppression works and how to deal with additional
>messages.

>6. Section 4.1, second paragraph:

>   The FCI field MUST contain one or more entries of transport layer
 >  third party loss Early Indication (TLLEI).  Each entry applies to a
 >  different media source, identified by its SSRC.

>Something is wrong here. There is no SSRC field in the FCI format
>depicted in figure 1. Despite that each entry reports on different media
>streams. So there needs to either a clarification that the entry formats
>are an SSRC plus the PID+BLP word. Or the last sentence in above quote
>needs to be changed.

[Qin]:I believe it should be latter. 
Adding SSRC plus the PID+BLP is not as in
 http://tools.ietf.org/html/rfc4585#section-6.2.1
. My proposed change to the second paragraph of section 4.1
 is to remove the last sentence in second paragraph.


>In addition this section is clearly missing clarification on how the
>SSRC field in the feedback header is used. Although I have to say for
>once the fields name is quite suitable and reasonably clear.


[Qin]: If we agree all the entries in FCI format share the same SSRC of 
media source, then it is clear the SSRC field in the feedback header is 
set to what it is.
However if you think we can add multiple entries of TLLEI, each entry 
is identified by an SSRC,
Then I think SSRC of media source field should not be used and set to 
zero. So the open question is we may have two choice for the format of transport layer feedback:
1.  No SSRC field in FCI format and all the entries share the same SSRC 
defined in the SSRC of media source field of Feedback header
2. FCI contain multiple entries, each entry is identified by an SSRC. The 
SSRC of media source field of Feedback header is set to zero. 

Which one is more appropriate?

>7. Section 4.2:
>The FCI part specification is not updated to reflect the PSLEI usages.

[Qin]: The PSLEI usages is reflected in the section 6.2 as an example.

>First of all the SSRC field, would be of the source for which it is not
>necessary to request video fast update from. Secondly, I don't see how
>the sequence number is used in this case. It made quite a lot of sense
>in the case of requesting video updates as one needs to distinguish
>retransmissions that might be in flight from new updates. I don't see
>that being necessary here, where a suppression is a suppression.

[Qin]: You are right, the intermediary knows the SSRC of the source
from which it request to send a decoder refresh point and will tell the 
receivers to not send a FIR to this source. The sqn is not needed.

>A third question is, does the same timing rules apply to this case
>compared to loss? If one only uses this format and not retransmission,
>then one may not have the same retransmission request logic.


[Qin]: The receiver should not send a FIR but behave as if it did
expecting to get a synchronization point the same as if it did sent a FIR
(no behavior change for receiver)
Does this answer your question?

>8. Section 8.

>The registrations that needs to happens are first of all the FMT values
>for the two formats. One in "FMT Values for RTPFB Payload Types"
>registry, the second one in "FMT Values for PSFB Payload Types".

>Then the three registrations provided seems to be in the wrong format.
>What I understand they are intended for the registries on the
>http://www.iana.org/assignments/sdp-parameters page.

>The first one is for "rtcp-fb" Attribute Values". The second and third
>that currently exist, should be part of a registry creation request,
>similar to what is in Codec Control Messages RFC 5104 IANA considerations.

[Qin]:I think you are right and will follow your advice.

>9. Section 10.1:

>I wonder is really RFC 5117 a normative reference? The reason is that is
>an informational RFC.

[Qin]: Okay, I will put it as informative reference.

>I haven't finished reviewing section 6 and 7 and will send a follow up
>when that is done.

>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]
>----------------------------------------------------------------------