Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02)

Michael Welzl <michawe@ifi.uio.no> Wed, 27 August 2014 20:45 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321C71A02E0; Wed, 27 Aug 2014 13:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRalJ7XVLoKU; Wed, 27 Aug 2014 13:45:15 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C523F1A0282; Wed, 27 Aug 2014 13:45:14 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1XMk5c-0003xh-3U; Wed, 27 Aug 2014 22:45:08 +0200
Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1XMk5b-0005py-Ev; Wed, 27 Aug 2014 22:45:08 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <DB56BB81-4CD0-4A2A-A664-67103CED72BC@nostrum.com>
Date: Wed, 27 Aug 2014 22:45:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABC20E38-5908-400D-BAF2-FEA46931DC76@ifi.uio.no>
References: <embac59e09-6dad-42df-94b2-7daa46d31d5d@sydney> <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <A4501649-B293-4B6F-A4EB-A08B30EF922C@ifi.uio.no> <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> <B43C20C1-C34E-4441-80EB-24C89DCE430D@ifi.uio.no> <0F1C9E57-EDA5-4A44-9F8A-87A76C159AED@csperkins.org> <DB56BB81-4CD0-4A2A-A664-67103CED72BC@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 13 sum msgs/h 3 total rcpts 19588 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 13D793E7B1647186306EA8C4C19AA58E771DDB83
X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 184 max/h 7 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/8Fnk2-37APEQU53TLru8jlSexKM
Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>, "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>, "Paul E. Jones" <paulej@packetizer.com>, Colin Perkins <csp@csperkins.org>
Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02)
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 20:45:18 -0000

I don't know the beginning of this but I can help go up the stack:

for the short dialogue between Colin and me, the conclusion is: Colin is right. RTCP probably won't be used by congestion control to estimate the RTT.

Cheers,
Michael


On 27. aug. 2014, at 21:46, Ben Campbell <ben@nostrum.com> wrote:

> Hi,
> 
> Where are we with this discussion? Are there conclusions buried in there somewhere?
> 
> Thanks!
> 
> Ben.
> 
> On Aug 27, 2014, at 1:50 PM, Colin Perkins <csp@csperkins.org> wrote:
> 
>> On 27 Aug 2014, at 19:47, Michael Welzl <michawe@ifi.uio.no> wrote:
>>> On 27. aug. 2014, at 20:42, Colin Perkins <csp@csperkins.org> wrote:
>>>> On 27 Aug 2014, at 19:39, Michael Welzl <michawe@ifi.uio.no> wrote:
>>>>> On 27. aug. 2014, at 18:00, Colin Perkins <csp@csperkins.org> wrote:
>>>>>> On 26 Aug 2014, at 17:38, Black, David <david.black@emc.com> wrote:
>>>>>>>> The more difficult case is when an SSRC is sending video using different
>>>>>>>> markings for RTP packets carrying the I- and P-frames. Should that SSRC then
>>>>>>>> mark its RTCP packets like the RTP packets carrying I-frames, like the RTP
>>>>>>>> packets carrying P-frames, or what?
>>>>>>> 
>>>>>>> Answering a question w/a question :-), how are those reports likely to be used?
>>>>>>> 
>>>>>>> For example, if the primary use of these reports is to adjust a variable rate
>>>>>>> codec's sending rate, the P-frame info is probably more useful as indicative
>>>>>>> of what's happening to the traffic that the network drops first when the going
>>>>>>> gets rough (or whose delivery w/o loss indicates that a sending rate increase
>>>>>>> may be reasonable), which suggests P-frame-like RTCP report marking.
>>>>>> 
>>>>>> I doubt the RTT estimate derived from RTCP is used for congestion control, since it’s too infrequent to get insight into the dynamics. It’s for user experience reporting, maybe rough clustering of receivers, that sort of thing. 
>>>>> 
>>>>> I'd agree if I didn't have the impression, in RMCAT, that nothing but RTP / RTCP is allowed?!  So can we send extra packets to probe for the RTT?
>>>> 
>>>> I’d expect RMCAT will probe the one-way delay variation by measuring the arrival times of RTP packets, and report that in RTCP once per video frame (or so). That would give a much more accurate measurement than a single-packet sample of the RTT derived from RTCP, and would still allow per-frame adaptation.
>>> 
>>> I agree that this is a useful signal to use - but I think you still need a rough idea of the RTT to be able to interoperate with TCP, else you may cause TCP to go into RTOs and be ignorant of that. But this could perhaps be a more coarse signal - maybe that's okay. I think this is reasonable.
>> 
>> You have the RTT estimate, irrespective of the other information you include along with the regular RTCP packets, although it’s relatively infrequent and coarse-grained.
>> 
>>> I wonder if your RTCP draft in RMCAT should clarify this?  (sorry if it does already, didn’t check)
>> 
>> It probably should talk about this, I agree.
>> 
>> 
>> -- 
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
>> 
>> _______________________________________________
>> Dart mailing list
>> Dart@ietf.org
>> https://www.ietf.org/mailman/listinfo/dart
>