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

[Magnus Westerlund <[e-mail]>]

On 2011-09-05 06:06, Qin Wu wrote:
> 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"

good.

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

I agree with the intention of not sending them upstream. Which boils
this down to finding the right place and right wording to ensure that
this is captured in a clearly understandable form.

I don't like RTP system in the network. Maybe keeping it simple and
replacing "Systems" with "RTP node" is the most straight forward in this
sentence.



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

Much clearer.

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

Well, but if you are a Intermediary that forwards upstream RTP packets
onto a multicast segment and at the same time buffers them for
retransmission. Then when that Intermediary detects a loss upstream of
itself it might want to send a TPLR as soon as it is pretty certain of
that loss downstream to avoid the receivers sending NACK on something it
can't repair. And in that case, it is difficult to determine how often
it should be repeated while it is still not received or repaired.


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

I still don't know how often I need to send them to ensure that I don't
get NACKs from my receivers.

> 
>> 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 personally think refreshing the timer immediately in both cases might
be both simpler and work better. Especially as the sender of an update
then knows that it is one interval from the reception of the new TPLR,
and not two intervals since the first one. As the length of the interval
is not known it is difficult to know when receivers will approximately
resume sending NACKs.

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

That is fine with me.
> 
> 
>> 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?

I think 1 is the most appropriate in this case. Most of the application
scenarios for TPLR is where you will have few SSRCs but potentially a
lot of packets.

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

I think the above was intended as general comment and then diving into
the details.

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

Agree

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

Yes, but you might have to point out the timing rules that applies.

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

Still not done with this part. Will try to follow up soon.

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