Re: [Dart] Open Issue: Guidance for RTCP

[Harald Alvestrand <[e-mail]>]

On 08/25/2014 09:57 AM, Black, David wrote:
> (as editor)
>
> I believe the core of this issue is the role of RTCP in providing RTT
> estimates.  This is the core of open issue [B] and resolving it is
> likely to resolve much of open issue [F].

I think we're just scratching at a deeper issue here:

What is the role of the RTT estimate, and is RTT what we're looking for?

In ack-based congestion control, RTT estimates are used to determine 
when we should say "we have not seen the ACK we expected" - which 
indicates either packet loss or increased congestion, either on the 
forward or the reverse path - the algorithm does not care which.

The signal is only useful for end-of-packet-train packet loss (because 
otherwise there will be later packets leading to SACK indications of 
lost packets before the RTT timer runs out), so the exact value doesn't 
really matter - only that the false positive rate isn't too high.

In delay-based, sender-side-only congestion control, however, RTT has to 
be used as a stand-in for the sender->receiver transit time (because we 
have nothing else). So any variation in return-path RTT is going to be 
interpreted as congestion change on the forward path - which means wrong 
decisions.

My conclusions are two:

- If delay-based senders-side-only is used, what matters is that the 
feedback signal gets there with as little delay variation as possible. 
The highest precedence available should be used.

- Delay-based schemes need to have the timing done at receiver. RTT is 
just too sensitive to errors.

The last argument belongs in RMCAT, not here. I'll leave the first 
argument for your consideration.

>
> I believe the key question is:
>
> 	Is the role of RTCP in providing RTCP estimates important enough
> 	to serve as the primary basis for providing guidance on DSCP usage
> 	w/RTCP?
>
> Here's a summary of the "yes it is" viewpoint (from Colin Perkins):
>
> 	Using a single
> 	PHB and DSCP for all RTCP packets within an RTP session might make
> 	sense, but it's important to note that one role of RTCP is to provide
> 	an estimate of the round-trip time seen by the media, so the PHB/DSCP
> 	will have to be chosen with care to avoid biasing that estimate too
> 	much.

To which my comment is "media has no round trip time". Media goes one way.

>
> And a summary of the "no it isn't" viewpoint (from Paul Jones):
>
> 	it was proposed that RTCP
> 	should be marked the same as for RTP.  The argument was that this
> 	is used for RTT calculations.  If that is what was said, I'd like
> 	to state my disagreement. :-)
>
> 	The forward and reverse paths are not necessarily the same and there is
> 	nothing one should assume about the reverse path to provide guidance about
> 	the forward path (or vice versa).  As perhaps a gross example, I have the
> 	ability to download far faster on my home Internet connection than I can
> 	upload.  Other important traffic characteristics differ in each direction.
>
> Thanks,
> --David (as editor)
>
>> -----Original Message-----
>> From: Dart [mailto:[e-mail]] On Behalf Of Ben Campbell
>> Sent: Monday, August 25, 2014 1:00 AM
>> To: [e-mail]
>> Subject: [Dart] Open Issue: Guidance for RTCP
>>
>> (as chair)
>>
>> We have an open issue (Designated issue [B] by David) about what guidance to
>> give about RTCP in draft-ietf-dart-dscp-rtp. We need to close this in order to
>> progress the draft--meaning we need to do so ASAP.
>>
>> Please look at the the following quoted text for background, and offer an
>> opinion:
>>
>>
>>> (2) PHBs and DSCPs for RTCP.
>>>
>>> I'm not sure what to say about this, as it looks like I need to set
>>> off a discussion (debate?) between you and my co-author, Paul Jones.
>>>
>>> Colin (from WGLC comments):
>>>
>>>> Rather, within a single RTP session there are RTCP packets sent
>>>> that give information about the RTP streams that are being sent, and that
>>>> report on the reception quality of RTP streams being received. Using a
>> single
>>>> PHB and DSCP for all RTCP packets within an RTP session might make sense,
>> but
>>>> it's important to note that one role of RTCP is to provide an estimate of
>> the
>>>> round-trip time seen by the media, so the PHB/DSCP will have to be chosen
>> with
>>>> care to avoid biasing that estimate too much.
>>> Paul (from shortly after the Toronto meeting:
>>>
>>>> During the meeting, there was discussion of marking RTCP packets.  Some
>>>> notes I received on this topic suggested that it was proposed that RTCP
>>>> should be marked the same as for RTP.  The argument was that this is used
>>>> for RTT calculations.  If that is what was said, I'd like to state my
>>>> disagreement. :-)
>>>>
>>>> The forward and reverse paths are not necessarily the same and there is
>>>> nothing one should assume about the reverse path to provide guidance about
>>>> the forward path (or vice versa).  As perhaps a gross example, I have the
>>>> ability to download far faster on my home Internet connection than I can
>>>> upload.  Other important traffic characteristics differ in each direction.
>>>>
>>>> Further, an RTCP packet might provide information related to several
>> different
>>>> RTP packets.  I certainly would not want to see one RTCP packet per RTP
>> packet.
>>>
>> _______________________________________________
>> Dart mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dart
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart