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

[Qin Wu <[e-mail]>]

Hi, Magnus:
I agree with your comments below and will issue new version to address these comments soon.
----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, September 22, 2011 11:34 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt


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

[Qin]:Okay.

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

[Qin]: Yes, that is what I said.

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

[Qin]: Exactly.

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

[Qin]: Yes.

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

[Qin]: Okay.

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

[Qin]:Yes. Fully agree.

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