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

[Magnus Westerlund <[e-mail]>]

Hi,

I think the discussion has become so convoluted that it is difficult to
understand what applies to which deployment.

On 2011-09-19 07:36, Qin Wu wrote:
> Hi, Magnus:
> Please see my reply below.
> ----- Original Message ----- 
> From: "Magnus Westerlund" <[e-mail]>
> To: "Qin Wu" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Friday, September 16, 2011 11:04 PM
> Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt
> 
> 
>> On 2011-09-16 12:18, Qin Wu wrote:
>>>>>>
>>>>>>> 5. Section 3, fourth paragraph:
>>>>
>>>> I think using observed RTTs is a good thing. However, one needs to 
>>>> answer the question of who's RTT are one using. A SSM receiver has
>>>> no RTT measurements performed, as they are sending no SRs. So
>>>> unless the summary Report is provided the receiver have no
>>>> knowledge of any RTTs in the system.
>>>>
>>>> This is likely true also for intermediaries unless they send data
>>>> using their own SSRC, like unicast RTX.
>>>>
>>>> Thus, it becomes difficult to know how the entities will behave
>>>> with these retransmission timers.
>>>
>>>
>>> [Qin]: This is not true. Look at the section 7.1.6 of RFC5760, in SSM
>>> summary feedback case, the distribution source can use Round-Trip
>>> time sub-report block defined in section 7.1.6 to tell the receiver
>>> about the round-trip time from the distribution source to the
>>> receivers. This round-trip time can be calculated based on the SR
>>> from media source, RR from receiver and the current time according to
>>> the section 7.1.6. So this round-trip time calculation also applies
>>> to the other use cases.
>>
>> I think we are in full agreement when the summary feedback mode is used.
>> But what if it isn't. What if one uses the simple feedback. 
> 
> [Qin]: As described in draft-ietf-avtcore-feedback-suppression-rtp, 
> 
> in simple feedback case, DS will not send TPLR instead it send NACK.
> 
> I am not sure the timing rule for sending NACK is the scope of this document.
> 

I guess we are back to what "it" says in the following sentence.
One example is the middle box gets
   the retransmitted packet by sending a NACK upstream and sent it
   downstream.

If it is "the NACK". But I have to say that I am confused by this test
if it is one SSM group that continues all the way to the ultimate
receiver and the Intermediary is just a on route monitoring and help
device.


> 
>> Sure, the
>> receiver can measure the time until its RTCP packet comes back to it.
>> But that doesn't measure the Media source to receiver RTT which I
>> believe is the relevant here.
> 
> [Qin]Unlike Summary Feedback model case, in simple feedback model,
> 
>  as described in section 6.1 of RFC5760, the DS create its own Sender
> 
>  report which includes round trip time calculation between DS and 
> 
> receiver.


>  
> 
> If the DS want to know the RTT between media source and itself, the DS
> 
>  can estimate it based on the SR sent from media source to the DS and
> 
>  current time as measured from its own system clock.
> 

I think I missed something important in this case. In simple feedback
model, also the receivers RTCP are feed back into the group. Thus the
combination of the SR and the receivers RRs should enable each
participant to have a view of the delay between the DS and each receiver.


>  
> 
> I don't understand why in this case the receiver still needs to know the RTT 
> between media source and receiver since the SR sent from DS rather than media source 
> carries the round trip time calcualtion.

Well, if the goal is to determine the amount of time a TPLR or for that
matter a NACK suppresses new NACKs I think one have to take into account
the RTTs to be expected before receiving a repair packet or know that it
has been lost.

But with this each session participant clearly has the information it
needs.

> 
>> And I think the question is still what RTT one uses in these
>> measurements. 
> 
> [Qin]: See above.
> 
> 
>> The one related to the media server, or one related to the
>> SSRC injecting the TPLR. They don't need to be the same.
> 
> [Qin]: In all these case, I think SSRC of source is still from media server or media source.
> 
> The SSRC of sender is generated by the middlebox.
> In TPLR format described in section 4.2 of draft-ietf-avtcore-feedback-suppression-rtp, SSRC in FCI format
> is SSRC of media source. Since media source may change, so does SSRC of media source.
> am I wrong?


The above question was really about whose delays in the system one
should consider. If an Intermediary sends the NACK to the DS. Then there
is one RTT between the intermediary and the DS. The downstream receiver
will have another RTT with the DS. In that context I think one do need
to consider which time intervalls that makes sense. What legs of the
system does the messages need to traverse before getting the reaction,
or having to retransmit.

When it comes to the SSRCs, don't forgett that you do have two SSRC isn
the common packet format for feedback messges. One of the source of the
feedback message and one that is the media source that the message
relate to.


>>>
>>> Assume the intermediary sits between media source and receiver, we
>>> can ask intermediary to measure the round trip time between media
>>> source and intermediary, the round trip time between intermediary and
>>> receiver to make sure the media source is more near to the
>>> intermediary than the receiver.
>>
>> Yes, that makes sense. But what method(s) of measuring are you proposing
>> for the intermediary?
> 
> [Qin]: The intermediary may Use the same measurement method described in 
> 
> the section 7.1.6 ,first paragraph of RFC5760 in SSM summary feedback model case.
> 
> Is that clear?

Well, does that work? Is the intermediary receving the RTCP RRs from the
receivers. And what way have they taken to reach the intermediary.

But I have to say that I have become confused in which model we are
discussing here.



-- 

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