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

[Magnus Westerlund <[e-mail]>]

On 2011-09-22 11:26, Qin Wu wrote:
> Hi, Magnus: ----- Original Message ----- From: "Magnus Westerlund"
> <[e-mail]> To: "Qin Wu" <[e-mail]> 
> Cc: <[e-mail]>;
> <[e-mail]> Sent:
> Wednesday, September 21, 2011 11:27 PM Subject: Re: Comments on
> draft-ietf-avtcore-feedback-supression-rtp-06.txt
> 
> 
>> Hi,
>> 
>> I think the discussion has become so convoluted that it is
>> difficult to understand what applies to which deployment.
> 
> [Qin]: Sorry, I think there is some misunderstanding on a few issues
> we are talking about.
> 
> I am working on the restructuring of section 3. I believe we are on
> the same page and our
> 
> discussion is approaching convergence rather than going into loop.

Yes, thus I think it might be simplest that you update the document to
your understanding of the discussion and then I can check the update to
determine if we still have any ambiguities.

> 
> 
>> 
>> 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.
>> 
> 
> [Qin]: I think there is some misunderstanding.
> 
> In Simple feedback case, the DS may send SR including round-trip time
> 
> 
> calculation. So it is also not difficult for DS to behave with the
> retransmission
> 
> timer.
> 
> 
> 
> In this example mentioned above, the NACK sent to upstream is just
> for
> 
> asking for lost packet on behalf of receivers. I am not saying how to
> deal
> 
> the timing rule of this NACK sent to upstream is out scope of this
> document.
> 
> 
> 
> What I am saying is in simple feedback case, DS only reflect NACK to
> the receivers,
> 
> however this document focus on defining the use of TPLR, that's why I
> am saying
> 
> how to deal with retransmission timer when NACK
> 
> sent to downstream may not be the scope of this document, but I am
> okay if you think
> 
> we should.
> 
> Does this clarify?
> 

If the conclusion is that TPLR is not applicable to this case I think we
are in agreement.

>>> 
>>> 
>>> 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.
> 
> 
> [Qin]: Agree, but I believe you misunderstand what I said above. What
> I am saying is
> 
> RTT measurement method for simple feedback case is different from RTT
> measurement
> 
> method for Summary Feedback case, am I right?

Well, to some extent yes.

In both cases the DS can do RTT measurements as intended for anyone
sending SRs in basic RTP.

In the simple feedback model any SSM session recipient can first measure
its RTT to the DS. That by determing the time it takes from it sends its
RTCP RR to get it back. Yes, there is some component of undetermined
processing in that.

With that knowledge it can determine the RTT values for any receiver by
determine its reception time of the reflected RTCP RR and then deduct
the time from the DS to one self. Use that to derive both the RTCP SR
sending time and the time the RTCP RR was received by the DS. Thus
calculating the delay.

In the summary session, the receiver have no way of measuring the RTT.
It can only use the RTT distribution received from the DS based
measurements.

> 
> 
> 
>>> 
>>>> 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.
>> 
> 
> 
> 
> 
> [Qin]: Agree, I am not sure which case you are talking about, SSM
> case or RAMS case.
> 
> For SSM case, I am going to remove the text about "intermediary send
> NACK to DS", so
> 
> there is only one DS in SSM case, the only RTT with DS needs to be
> taken into account.

I tried to understand if there was any usage of the TPLR in the SSM
case. Which I think it is for the summary mode.

And in that case that what RTT(s) should be used when determing the time
of suppression.

> 
> For RAMS case, please see my previous email on the suggestion, i.e.,
> reference Tom's draft.
> 

Yes, lets deal with RAMS usage in Tom's draft.


> 
> 
>> 
>>>>> 
>>>>> 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.
> 
> 
> [Qin]: I agree it depends on the model since different model may use
> different measurement method.
> 
> E.g., in Summary Feedback case, the DS may be disjointed from media
> soure, or may be itself media source.
> 
> the measurement method differs apparently. Therefore I agree we can't
> apply one measurement method to
> 
> all the use cases. So the general questions here are what's your
> suggestion about how to document measurement
> 
> method in this draft? shall we need to specify common text in section
> 3 to talk about this?

I think you need to discuss the general cases with summary and simple
feedback modes being very different. In fact simple feedback seems to
have very little use of the TPLR as long as the MS and DS are the same
entity.

I think the reasonable thing is to ensure that all cases are covered.


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