From holmer@google.com Tue Dec 4 01:23:16 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827421F8630 for ; Tue, 4 Dec 2012 01:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy2zaJZLoLuc for ; Tue, 4 Dec 2012 01:23:15 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2661B21F86F4 for ; Tue, 4 Dec 2012 01:23:11 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so3873707obc.31 for ; Tue, 04 Dec 2012 01:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DRK++F0IdchOTKlgNBVi8JRSUWezgseLa1WGxatNQ6s=; b=VS6zzUgfiJySV77hAOe7I3/8gorhrTAmw2zU3t9tqY+3Fmi5FUE3pV15K9DyqE67y3 0lMimDr00jSPKu6KpzqpXUI6acTJE9Ed7/CuMaHkit76VfBi5sKYZtmStFfwdhxaPyWn n7DbRQE7PZ62qG9IINC9EZ3qOudwXarIKE5do/q+IZAE9+dKoY4NTRV7ocvkBC2JeVS1 oOHBCCZPN/dFY4mRY5e7Ru/egah5gITwgzn/Vze8uumgE5cxs7vWRhcgEyzlwltFCV9x hG6QHGNrUu8dm2QPcXa6cKxSC3y8LTWaWKffRqrx20EWeJihMdHbiwhgjl7Z3L/ISW23 VfIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=DRK++F0IdchOTKlgNBVi8JRSUWezgseLa1WGxatNQ6s=; b=bU0kFipxZbcQkSJXq2t4zdRLZhnVOneZXiNhSPlbrGJpvsi3KcRqo9jV1fI07b473D wGp4sC8reLoFOG/3W7jPdOJAWG09ToS1W5M8wwM8fuKv8YixAOTe67iO2c4Ue0dcIYhR RCkizVQ8O/Godh+E9fMfAyIwvPdMX9szxxwhEaWhepa/jgq/JDEFvZf8rdbqgT/z7mTR o37TsyhyoVlJ/34aUh5wlXsXZpCntejv42PQpcJa9PHH7rp+oKyiF9TiBVP1OTWKs6hy /XAuNWL8IoBKYLDvaTd0DuoRayhjzB3vWBimwSIhD+jbugwh1AmGifpA+ZZHUDKuCWCU /CdQ== MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr6874303obc.6.1354612990494; Tue, 04 Dec 2012 01:23:10 -0800 (PST) Received: by 10.76.73.196 with HTTP; Tue, 4 Dec 2012 01:23:10 -0800 (PST) Date: Tue, 4 Dec 2012 10:23:10 +0100 Message-ID: From: Stefan Holmer To: rmcat WG Content-Type: multipart/alternative; boundary=f46d044631681b480904d0036ae1 X-Gm-Message-State: ALoCoQleL71UqUryAFxydVgpBOwSMc8Rn3pyvE8eCbaUAoziAPaq7G585eM1q2Gbx/DY9zU1Bsb7YyVlVz+gbyYXiVme7HZgEZhW1bwp1LCn2BdT3UIJIEhznu1/FNjR0vybVYP+7Gq5cEEeHQMgSJFJFDjj6R0ZKl52PandLnzLg0a5b0/4HVpaxtY2s+nU2Swh4lUrJfLF X-Mailman-Approved-At: Tue, 04 Dec 2012 01:29:31 -0800 Subject: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:23:16 -0000 --f46d044631681b480904d0036ae1 Content-Type: text/plain; charset=ISO-8859-1 Hi, In draft-alvestrand-rtcweb-congestion-01 we proposed using a send timestamp RTP header extension for measuring the packet inter-arrival time offset. In 02 this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send timestamp as an offset relative to the RTP timestamp. Thinking further about this, there seems to be a couple of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the relaying server can simply rewrite the send timestamp of a packet to correspond to the time it was relayed. Doing so the receiver can jointly process all streams being received from the relay server, even though they were initially captured and sent by different senders (with different clocks). With a send timestamp offset, accomplishing the same thing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synchronized with audio the RTCP packet for the audio streams must also be rewritten in a similar way. This may not even be possible if the audio stream is relayed through a different server. Do you see any problems with using an RTP header extension with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing? /Stefan --f46d044631681b480904d0036ae1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">Hi,

In draft-al= vestrand-rtcweb-congestion-01=A0we proposed using a send timestamp RTP = header extension for measuring the packet inter-arrival time offset. In 02=A0this was revised to instead reference RFC 5450, which spe= cifies a header extension for specifying the send timestamp as an offset re= lative to the RTP timestamp.

Thinking further about this, there seems to= be a couple of benefits with defining a new, absolute, send timestamp head= er extension. If a relay approach to conference servers are used, the relay= ing server can simply rewrite the send timestamp of a packet to correspond = to the time it was relayed. Doing so the receiver can jointly process all s= treams being received from the relay server, even though they were initiall= y captured and sent by different senders (with different clocks).=A0

With a send timestamp offset, accomplishing= the same thing would require rewriting both the timestamp offset and the N= TP time in the corresponding RTCP SR reports. And to keep video synchronize= d with audio the RTCP packet for the audio streams must also be rewritten i= n a similar way. This may not even be possible if the audio stream is relay= ed through a different server.

Do you see any problems with using an RTP h= eader extension with absolute send timestamps? Are there any benefits with = the send timestamp offset header extension I might be missing?

/Stefan
--f46d044631681b480904d0036ae1-- From john@jlc.net Tue Dec 4 09:27:29 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0621F8C57 for ; Tue, 4 Dec 2012 09:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.354 X-Spam-Level: X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6dxgsM1Nkab for ; Tue, 4 Dec 2012 09:27:28 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CF61C21F8C52 for ; Tue, 4 Dec 2012 09:27:28 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D5F7933CDB; Tue, 4 Dec 2012 12:27:28 -0500 (EST) Date: Tue, 4 Dec 2012 12:27:28 -0500 From: John Leslie To: Stefan Holmer Message-ID: <20121204172728.GK1941@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: rmcat WG Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:27:29 -0000 Stefan Holmer wrote: > > Thinking further about this, there seems to be a couple of benefits with > defining a new, absolute, send timestamp header extension. If a relay > approach to conference servers are used, the relaying server can simply > rewrite the send timestamp of a packet to correspond to the time it was > relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captured > and sent by different senders (with different clocks). > > With a send timestamp offset, accomplishing the same thing would require > rewriting both the timestamp offset and the NTP time in the corresponding > RTCP SR reports. And to keep video synchronized with audio the RTCP packet > for the audio streams must also be rewritten in a similar way. This may not > even be possible if the audio stream is relayed through a different server. > > Do you see any problems with using an RTP header extension with absolute > send timestamps? Are there any benefits with the send timestamp offset > header extension I might be missing? I must admit to failing to understand what problem you think this would solve. :^( I am far more concerned with deriving mouth-to-ear delay than anything relating to some intermediary relay. (But, to tell truth, I'm still less than clear how to derive even transducer-to-transducer delay -- perhaps somebody could write up a "RTP-latency for dummies" piece?) -- John Leslie From kevin.gross@avanw.com Tue Dec 4 11:30:57 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1077121F8CBD for ; Tue, 4 Dec 2012 11:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbLj07aVKmUt for ; Tue, 4 Dec 2012 11:30:56 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 20E1521F8CBB for ; Tue, 4 Dec 2012 11:30:56 -0800 (PST) Received: (qmail 694 invoked by uid 0); 4 Dec 2012 19:30:30 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 4 Dec 2012 19:30:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=qupgLV/w0Dpk3SqZd5zbGWp84butItRo3MqfT7v2KpM=; b=be+VV3rXgf5PhEGOEsqPCtw5uAOMHkhi/RsypjLCJ5J2KMhqwNlRoeulvf7tgW1RTgCvPLB6bPcwk0fhPEtXTpZapNL0lUQFSS0UA4uZ4jyq423aF1Ol+0SiDef0idRc; Received: from [209.85.210.172] (port=52143 helo=mail-ia0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TfyCM-0007NO-4a for rmcat@ietf.org; Tue, 04 Dec 2012 12:30:30 -0700 Received: by mail-ia0-f172.google.com with SMTP id z13so3577376iaz.31 for ; Tue, 04 Dec 2012 11:30:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.34.226 with SMTP id c2mr3947019igj.24.1354649429247; Tue, 04 Dec 2012 11:30:29 -0800 (PST) Received: by 10.50.151.135 with HTTP; Tue, 4 Dec 2012 11:30:29 -0800 (PST) In-Reply-To: <20121204172728.GK1941@verdi> References: <20121204172728.GK1941@verdi> Date: Tue, 4 Dec 2012 12:30:29 -0700 Message-ID: From: Kevin Gross To: John Leslie Content-Type: multipart/alternative; boundary=14dae934059506888b04d00be663 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.172 authed with kevin.gross@avanw.com} Cc: Stefan Holmer , rmcat WG Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:30:57 -0000 --14dae934059506888b04d00be663 Content-Type: text/plain; charset=ISO-8859-1 For a discussion of latency in RTP, you should have a look at - http://tools.ietf.org/html/draft-ietf-avtcore-idms-07. http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-01 may also be helpful. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Dec 4, 2012 at 10:27 AM, John Leslie wrote: > Stefan Holmer wrote: > > > > Thinking further about this, there seems to be a couple of benefits with > > defining a new, absolute, send timestamp header extension. If a relay > > approach to conference servers are used, the relaying server can simply > > rewrite the send timestamp of a packet to correspond to the time it was > > relayed. Doing so the receiver can jointly process all streams being > > received from the relay server, even though they were initially captured > > and sent by different senders (with different clocks). > > > > With a send timestamp offset, accomplishing the same thing would require > > rewriting both the timestamp offset and the NTP time in the corresponding > > RTCP SR reports. And to keep video synchronized with audio the RTCP > packet > > for the audio streams must also be rewritten in a similar way. This may > not > > even be possible if the audio stream is relayed through a different > server. > > > > Do you see any problems with using an RTP header extension with absolute > > send timestamps? Are there any benefits with the send timestamp offset > > header extension I might be missing? > > I must admit to failing to understand what problem you think this would > solve. :^( > > I am far more concerned with deriving mouth-to-ear delay than anything > relating to some intermediary relay. (But, to tell truth, I'm still less > than clear how to derive even transducer-to-transducer delay -- perhaps > somebody could write up a "RTP-latency for dummies" piece?) > > -- > John Leslie > --14dae934059506888b04d00be663 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For a discussion of latency in RTP, you should have a look at -=A0http://tools.iet= f.org/html/draft-ietf-avtcore-idms-07.=A0http://tools.ietf.org/html/draft-ietf= -avtcore-clksrc-01 may also be helpful.

Kevin Gross
+1-303-447-0517
Media = Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org



On Tue, Dec 4, 2012 at 10:27 AM, John Le= slie <john@jlc.net> wrote:
Stefan Holmer <ho= lmer@google.com> wrote:
>
> Thinking further about this, there seems to be a couple of benefits wi= th
> defining a new, absolute, send timestamp header extension. If a relay<= br> > approach to conference servers are used, the relaying server can simpl= y
> rewrite the send timestamp of a packet to correspond to the time it wa= s
> relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captur= ed
> and sent by different senders (with different clocks).
>
> With a send timestamp offset, accomplishing the same thing would requi= re
> rewriting both the timestamp offset and the NTP time in the correspond= ing
> RTCP SR reports. And to keep video synchronized with audio the RTCP pa= cket
> for the audio streams must also be rewritten in a similar way. This ma= y not
> even be possible if the audio stream is relayed through a different se= rver.
>
> Do you see any problems with using an RTP header extension with absolu= te
> send timestamps? Are there any benefits with the send timestamp offset=
> header extension I might be missing?

=A0 =A0I must admit to failing to understand what problem you think t= his would
solve. :^(

=A0 =A0I am far more concerned with deriving mouth-to-ear delay than anythi= ng
relating to some intermediary relay. (But, to tell truth, I'm still les= s
than clear how to derive even transducer-to-transducer delay -- perhaps
somebody could write up a "RTP-latency for dummies" piece?)

--
John Leslie <john@jlc.net>

--14dae934059506888b04d00be663-- From holmer@google.com Wed Dec 5 00:47:20 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1DF21F8C69 for ; Wed, 5 Dec 2012 00:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGXUuuacBXyM for ; Wed, 5 Dec 2012 00:47:19 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDDD21F8C9C for ; Wed, 5 Dec 2012 00:47:19 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5223950obc.31 for ; Wed, 05 Dec 2012 00:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hzzZGnHBEPXh9CFdbAd2vdpUEFSbnDhoW34OM7r6e+E=; b=mzxNwmLB1uP+4ff8qZduir9ks3asfrObankwuBZfuiMST13vHgVxPrhyJNdPDFH3yX lS3+9UeLju18HwL+f6ZN2U5pS87ttg0OPsBt8qOs1Up9xkw/rAz7gMfRxu0Vozr8ldVN wReJ6gSFTpPynoLWQmgc+gVX7Y3HQz6iHhBcrE6SOozb6gXWM0QW8vgBA982iCk6Z2cw F4xkyZGIA/0D55nOttE68fnvgZtIVRo/97MtuVP6lNTPY6YNFhV8sx32aLTSDiRu3P/F 1gn+5Y0CcjYLNwB0cUxG1rnJqAe+vDg3avH7NqjE1p7GgpLpi4u5p0oPHw1HU7LV39lj R55g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hzzZGnHBEPXh9CFdbAd2vdpUEFSbnDhoW34OM7r6e+E=; b=phUYzcHelEcPX5y3RF/GbX4SnRW5EZDoC1PvW8kY+m0n0TUyDJT73Nbl0NCkZi/R+I am8J6GQMLaT1x07C85pD0xeuho3yVD4ax7bpua9Xqcnyg0kffoCkSTiT5VRR24YZpRfX /t9v9+EM62gkGMvz+TcA+4WIAniVBAcarnEvINaTvWuz/4qg+V6+S2g36YmeHP/M3WC/ Iv40vT59MVVd3R8OK/paBbrq1hfAfWyGKPp/R8n8U/ut2Dm2LxQ97EHob6u4ZdNfP71s LNHEDYwDr6sqwWLeBmwFm7KiX59Ky6TCqTRXoV3YjGPRTjFdzv1KhI9xsiqi/C7XSlbp bGzg== MIME-Version: 1.0 Received: by 10.182.109.101 with SMTP id hr5mr9833371obb.84.1354697238539; Wed, 05 Dec 2012 00:47:18 -0800 (PST) Received: by 10.76.73.196 with HTTP; Wed, 5 Dec 2012 00:47:18 -0800 (PST) In-Reply-To: <20121204172728.GK1941@verdi> References: <20121204172728.GK1941@verdi> Date: Wed, 5 Dec 2012 09:47:18 +0100 Message-ID: From: Stefan Holmer To: John Leslie Content-Type: multipart/alternative; boundary=f46d0444edb1ae6ba604d0170756 X-Gm-Message-State: ALoCoQn/a2Bwm4jpAsTvTrMetYfIX3LDCm3dEBQRv0IXhagJdkBTcibilrJTu9FoahhoS64aYmsn66LKc6CUs6IgKblNKWXJw9myH5RfqFSaa6Pj46BCToTjPiNBkN8wunIW95pug91HKi9RKJMpMelmJPmz2wKDYVnxSwyH/OFnNSgkRiPLNuNgSk2i6xPWM2Ii2YPkZTcX Cc: rmcat WG Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:47:20 -0000 --f46d0444edb1ae6ba604d0170756 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 4, 2012 at 6:27 PM, John Leslie wrote: > Stefan Holmer wrote: > > > > Thinking further about this, there seems to be a couple of benefits with > > defining a new, absolute, send timestamp header extension. If a relay > > approach to conference servers are used, the relaying server can simply > > rewrite the send timestamp of a packet to correspond to the time it was > > relayed. Doing so the receiver can jointly process all streams being > > received from the relay server, even though they were initially captured > > and sent by different senders (with different clocks). > > > > With a send timestamp offset, accomplishing the same thing would require > > rewriting both the timestamp offset and the NTP time in the corresponding > > RTCP SR reports. And to keep video synchronized with audio the RTCP > packet > > for the audio streams must also be rewritten in a similar way. This may > not > > even be possible if the audio stream is relayed through a different > server. > > > > Do you see any problems with using an RTP header extension with absolute > > send timestamps? Are there any benefits with the send timestamp offset > > header extension I might be missing? > > I must admit to failing to understand what problem you think this would > solve. :^( > I might have gone into the details too fast above, sorry about that. I'm specifically thinking of the problem of measuring the changes in one-way delay by calculating the relative inter-arrival time. In http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 we calculate this as d(i) = t(i) - t(i-1) - (T(i) - T(i-1)), where t(i) is the receive-time and T(i) is the send-time of a packet. The send-time can be stamped on the packet in different ways, either with an offset relative to the RTP timestamp or as an absolute send time. With a relaying conference server a receiving client may receive several streams, originating from different sending clients. As all of those streams have been relayed by the same conference server we may want to use all of those streams to estimate bandwidth between the server and the receiving client. When doing that, the problems described in my initial e-mail arise. Hope this somewhat clarifies what I'm talking about. > > I am far more concerned with deriving mouth-to-ear delay than anything > relating to some intermediary relay. (But, to tell truth, I'm still less > than clear how to derive even transducer-to-transducer delay -- perhaps > somebody could write up a "RTP-latency for dummies" piece?) > > -- > John Leslie > --f46d0444edb1ae6ba604d0170756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">


On Tue, Dec 4, 2012 at 6:27 PM, John Leslie <john@jlc.n= et> wrote:
Stefan Holmer <holmer@google.com> wrote:
>
> Thinking further about this, there seems to be a couple of benefits wi= th
> defining a new, absolute, send timestamp header extension. If a relay<= br> > approach to conference servers are used, the relaying server can simpl= y
> rewrite the send timestamp of a packet to correspond to the time it wa= s
> relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captur= ed
> and sent by different senders (with different clocks).
>
> With a send timestamp offset, accomplishing the same thing would requi= re
> rewriting both the timestamp offset and the NTP time in the correspond= ing
> RTCP SR reports. And to keep video synchronized with audio the RTCP pa= cket
> for the audio streams must also be rewritten in a similar way. This ma= y not
> even be possible if the audio stream is relayed through a different se= rver.
>
> Do you see any problems with using an RTP header extension with absolu= te
> send timestamps? Are there any benefits with the send timestamp offset=
> header extension I might be missing?

=A0 =A0I must admit to failing to understand what problem you think t= his would
solve. :^(

I might have gone into= the details too fast above, sorry about that.

I'm specifically thinking of the problem of measuring the changes in= one-way delay by calculating the relative inter-arrival time. In=A0http:= //tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 we calculat= e this as

d(i) =3D t(i) - t(i-1) - (T(i) - T(i-1)),

where t(i) is the receive-time and= T(i) is the send-time of a packet. The send-time can be stamped on the pac= ket in different ways, either with an offset relative to the RTP timestamp = or as an absolute send time.

=
With a relaying c= onference server a receiving client may receive several streams, originatin= g from different sending clients. As all of those streams have been relayed= by the same conference server we may want to use all of those streams to e= stimate bandwidth between the server and the receiving client. When doing t= hat, the problems described in my initial e-mail arise.

=
Hope this somewhat clarifies what I'= m talking about.
=A0

=A0 =A0I am far more concerned with deriving mouth-to-ear delay than anythi= ng
relating to some intermediary relay. (But, to tell truth, I'm still les= s
than clear how to derive even transducer-to-transducer delay -- perhaps
somebody could write up a "RTP-latency for dummies" piece?)

--
John Leslie <john@jlc.n= et>

--f46d0444edb1ae6ba604d0170756-- From sergio.garcia.murillo@gmail.com Wed Dec 5 01:28:02 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D1B21F8BD5 for ; Wed, 5 Dec 2012 01:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhEQ+KIxagdJ for ; Wed, 5 Dec 2012 01:27:59 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7802421F8BCF for ; Wed, 5 Dec 2012 01:27:58 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4298810lbk.31 for ; Wed, 05 Dec 2012 01:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=OyRi8Hsp3R8dl4DvEN54RONwUEMjxRVgrKTqXoL/cug=; b=NCTCU5dZh0FHsPNTrUiVP2LKaxQiviudODy/Kx5yEeGP+Albye+YLWzfKLVz7h/w7E uRtr5r1a73712Epyw/KTLAk8D00Xnc79S4Xa6l4e0kZ3XqpgvlLFsbeQRhpo/M+FNu7K 6/KMr0PwdLmZJWrk+hQXOVnniL3DyM5sKw4z5Ez3irF0YhLM+gIN8jW+J+QJ4zU1G70F 0ItP1yaN2smQmsdVuASdJnud9yaU/ny7yJHnez+9vWlhB75L1WpNzmsv5C+6U2tklsrx pCvN5rs9nobqccUJwOjQca/1k3cn+u/ZOrTUUOFHDMI0r9rUmDJjHjsH1pBJBPCQsP3R nvGg== Received: by 10.152.110.234 with SMTP id id10mr16038574lab.15.1354699676917; Wed, 05 Dec 2012 01:27:56 -0800 (PST) Received: from [192.168.1.48] (47.Red-95-122-162.staticIP.rima-tde.net. [95.122.162.47]) by mx.google.com with ESMTPS id so7sm1714838lab.0.2012.12.05.01.27.54 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 01:27:56 -0800 (PST) Message-ID: <50BF1399.6050009@gmail.com> Date: Wed, 05 Dec 2012 10:27:53 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <20121204172728.GK1941@verdi> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030802040305040502070604" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:28:02 -0000 This is a multi-part message in MIME format. --------------030802040305040502070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 05/12/2012 9:47, Stefan Holmer escribió: > > > > On Tue, Dec 4, 2012 at 6:27 PM, John Leslie > wrote: > > Stefan Holmer > wrote: > > > > Thinking further about this, there seems to be a couple of > benefits with > > defining a new, absolute, send timestamp header extension. If a > relay > > approach to conference servers are used, the relaying server can > simply > > rewrite the send timestamp of a packet to correspond to the time > it was > > relayed. Doing so the receiver can jointly process all streams being > > received from the relay server, even though they were initially > captured > > and sent by different senders (with different clocks). > > > > With a send timestamp offset, accomplishing the same thing would > require > > rewriting both the timestamp offset and the NTP time in the > corresponding > > RTCP SR reports. And to keep video synchronized with audio the > RTCP packet > > for the audio streams must also be rewritten in a similar way. > This may not > > even be possible if the audio stream is relayed through a > different server. > > > > Do you see any problems with using an RTP header extension with > absolute > > send timestamps? Are there any benefits with the send timestamp > offset > > header extension I might be missing? > > I must admit to failing to understand what problem you think > this would > solve. :^( > > > I might have gone into the details too fast above, sorry about that. > > I'm specifically thinking of the problem of measuring the changes in > one-way delay by calculating the relative inter-arrival time. In > http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 we > calculate this as > > d(i) = t(i) - t(i-1) - (T(i) - T(i-1)), > > where t(i) is the receive-time and T(i) is the send-time of a packet. > The send-time can be stamped on the packet in different ways, either > with an offset relative to the RTP timestamp or as an absolute send time. > > With a relaying conference server a receiving client may receive > several streams, originating from different sending clients. As all of > those streams have been relayed by the same conference server we may > want to use all of those streams to estimate bandwidth between the > server and the receiving client. When doing that, the problems > described in my initial e-mail arise. > > Hi Steffan, Not considering packet losses, to calculate the t(i) reception time of a frame, wouldn't we just need the timestamp in the last RTP packet of a frame? I am still struggling to understand the draft to implement it in my media server, so maybe my suggestion is quite dumb, but, if we had absolute timestamps for each packet, could we improve the algorithm to work on a per rtp packet base instead of a per frame? Something like: At the receiving side we are observing incoming packets, where each packet has an absolute sent timestamp P(i). Each packet is assigned a receive time p(i), which corresponds to the time at which the packet has been received. A packet is delayed relative to its predecessor if p(i)-p(i-1)>P(i)-P(i-1), i.e., if the arrival time difference is larger than the timestamp difference. We define the (relative) inter-arrival time, d(i) as d(i) = p(i)-p(i-1)-(P(i)-P(i-1)) Best regards Sergio --------------030802040305040502070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 05/12/2012 9:47, Stefan Holmer escribió:



On Tue, Dec 4, 2012 at 6:27 PM, John Leslie <john@jlc.net> wrote:
Stefan Holmer <holmer@google.com> wrote:
>
> Thinking further about this, there seems to be a couple of benefits with
> defining a new, absolute, send timestamp header extension. If a relay
> approach to conference servers are used, the relaying server can simply
> rewrite the send timestamp of a packet to correspond to the time it was
> relayed. Doing so the receiver can jointly process all streams being
> received from the relay server, even though they were initially captured
> and sent by different senders (with different clocks).
>
> With a send timestamp offset, accomplishing the same thing would require
> rewriting both the timestamp offset and the NTP time in the corresponding
> RTCP SR reports. And to keep video synchronized with audio the RTCP packet
> for the audio streams must also be rewritten in a similar way. This may not
> even be possible if the audio stream is relayed through a different server.
>
> Do you see any problems with using an RTP header extension with absolute
> send timestamps? Are there any benefits with the send timestamp offset
> header extension I might be missing?

   I must admit to failing to understand what problem you think this would
solve. :^(

I might have gone into the details too fast above, sorry about that.

I'm specifically thinking of the problem of measuring the changes in one-way delay by calculating the relative inter-arrival time. In http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 we calculate this as

d(i) = t(i) - t(i-1) - (T(i) - T(i-1)),

where t(i) is the receive-time and T(i) is the send-time of a packet. The send-time can be stamped on the packet in different ways, either with an offset relative to the RTP timestamp or as an absolute send time.

With a relaying conference server a receiving client may receive several streams, originating from different sending clients. As all of those streams have been relayed by the same conference server we may want to use all of those streams to estimate bandwidth between the server and the receiving client. When doing that, the problems described in my initial e-mail arise.


Hi Steffan,

Not considering packet losses, to calculate the t(i) reception time of a frame, wouldn't we just need the timestamp in the last RTP packet of a frame? I am still struggling to understand the draft to implement it in my media server, so maybe my suggestion is quite dumb, but, if we had absolute timestamps for each packet, could we improve the algorithm to work on a per rtp packet base instead of a per frame?  Something like:

   At the receiving side we are observing incoming packets, where each 
   packet has an absolute sent timestamp P(i).

   Each packet is assigned a receive time p(i), which corresponds to the
   time at which the packet has been received.  A packet is delayed 
   relative to its predecessor if p(i)-p(i-1)>P(i)-P(i-1), i.e., if the 
   arrival time difference is larger than the timestamp difference.

   We define the (relative) inter-arrival time, d(i) as

     d(i) = p(i)-p(i-1)-(P(i)-P(i-1))


Best regards
Sergio

--------------030802040305040502070604-- From mramalho@cisco.com Wed Dec 5 11:59:40 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3173521F8C7E for ; Wed, 5 Dec 2012 11:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vhZNEa24Xc1 for ; Wed, 5 Dec 2012 11:59:36 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09D21F8713 for ; Wed, 5 Dec 2012 11:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22997; q=dns/txt; s=iport; t=1354737576; x=1355947176; h=from:to:subject:date:message-id:mime-version; bh=Fn2uj1MZMPqShttkzzdsEtcUPX8oA/PGiTdMShVezXA=; b=kmNgneMJV0Cc/OnvPglZ18K7XUf++HYwthVGtbIyw8AhOz0t29HQtyHd xYqkxe7YtvpMr3NIx9TKEzD3TFcAMf6MfYO93U4I1F4iZJ288jFcLIbu1 2tidPW43yZpApm2hLhVBfqJZPg/3fpnMJMQaczDGxqOiQAz+uTKFJqNR6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FABCmv1CtJV2c/2dsb2JhbABEgkmyUwGJCBZzgh4BAQEELTsjAQgRBAEBAQoWBzkUCQkBBBMIiAgMoQChWow3G4NFYQOIKo51jyuCcoFsNQ X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149579276" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 05 Dec 2012 19:59:35 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB5JxZH0020339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Dec 2012 19:59:35 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.84]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 13:59:35 -0600 From: "Michael Ramalho (mramalho)" To: "rmcat@ietf.org" Thread-Topic: [rmcat] Send timestamps Thread-Index: Ac3TIzSyQ6ilKk6UTdqNrfxFyCWNYA== Date: Wed, 5 Dec 2012 19:59:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.52.126] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B910315499132xmbrcdx12ciscoc_" MIME-Version: 1.0 Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:59:40 -0000 --_000_D21571530BF9644D9A443D6BD95B910315499132xmbrcdx12ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, Stephan Asked: "Do you see any problems with using an RTP header extension = with absolute send timestamps?" (with send timestamps relative to the actua= l send time and not the capture timestamps as the normal RTP timestamp unit= represents). Not only don't I see any issue with absolute timestamps, but I note that t= he processing of inter-departure times at the receiver (i.e., the resulting= measurements being an inter-ARRIVAL time measurement) is often brittle. That is, there are LOTS of (application-end to application-end) transport r= elated things that result in the transport time of A GIVEN packet NOT to be= nominal. By "not nominal" I mean statistically UNEXPECTED from what you w= ould think should occur if the measurement sample was created by what was a= ssumed to be an underlying Normal, Gaussian process. Things like software firewalls burping when doing some non-forwarding relat= ed processing (e.g., garbage collection), OSs adding strange delays after a= pplication-layer timestamps have been applied to the headers - not to menti= on the occasional burps in normal/expected Internet transport. The net resu= lt is that a pdf created from a histogram of individual packet delays would= be one-sided and pretty different from a normal distribution. Why process = these data samples as IF they were created by a Gaussian process - when you= KNOW that they are not? A SINGLE packet "outlier delay" not being "nominal" effects TWO bad (inter-= arrival time) measurement data points. And most of the processing I have se= en proposed on such data (e.g., Kalman filtering) is in the form of Euclide= an processing in which the ERROR in the measurement is SQUARED before furth= er processing. This effectively BIASES the very control mechanism you want = to use with outlier data! So, like Stephan, I would prefer to have the ability to have absolute times= tamps in the header extension - as I desire to do some non-linear outlier f= iltering BEFORE traditional signal processing is applied from the output of= my measurements. IMHO we ought not to be codifying an inter-arrival timest= amp in the header when you could generate (if you wanted) inter-arrival mea= surements from the absolute quantities. Michael Ramalho From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of S= ergio Garcia Murillo Sent: Wednesday, December 05, 2012 4:28 AM To: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps El 05/12/2012 9:47, Stefan Holmer escribi=F3: On Tue, Dec 4, 2012 at 6:27 PM, John Leslie > wrote: Stefan Holmer > wrote: > > Thinking further about this, there seems to be a couple of benefits with > defining a new, absolute, send timestamp header extension. If a relay > approach to conference servers are used, the relaying server can simply > rewrite the send timestamp of a packet to correspond to the time it was > relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captured > and sent by different senders (with different clocks). > > With a send timestamp offset, accomplishing the same thing would require > rewriting both the timestamp offset and the NTP time in the corresponding > RTCP SR reports. And to keep video synchronized with audio the RTCP packe= t > for the audio streams must also be rewritten in a similar way. This may n= ot > even be possible if the audio stream is relayed through a different serve= r. > > Do you see any problems with using an RTP header extension with absolute > send timestamps? Are there any benefits with the send timestamp offset > header extension I might be missing? I must admit to failing to understand what problem you think this would solve. :^( I might have gone into the details too fast above, sorry about that. I'm specifically thinking of the problem of measuring the changes in one-wa= y delay by calculating the relative inter-arrival time. In http://tools.iet= f.org/html/draft-alvestrand-rtcweb-congestion-03 we calculate this as d(i) =3D t(i) - t(i-1) - (T(i) - T(i-1)), where t(i) is the receive-time and T(i) is the send-time of a packet. The s= end-time can be stamped on the packet in different ways, either with an off= set relative to the RTP timestamp or as an absolute send time. With a relaying conference server a receiving client may receive several st= reams, originating from different sending clients. As all of those streams = have been relayed by the same conference server we may want to use all of t= hose streams to estimate bandwidth between the server and the receiving cli= ent. When doing that, the problems described in my initial e-mail arise. Hi Steffan, Not considering packet losses, to calculate the t(i) reception time of a fr= ame, wouldn't we just need the timestamp in the last RTP packet of a frame?= I am still struggling to understand the draft to implement it in my media = server, so maybe my suggestion is quite dumb, but, if we had absolute times= tamps for each packet, could we improve the algorithm to work on a per rtp = packet base instead of a per frame? Something like: At the receiving side we are observing incoming packets, where each packet has an absolute sent timestamp P(i). Each packet is assigned a receive time p(i), which corresponds to the time at which the packet has been received. A packet is delayed relative to its predecessor if p(i)-p(i-1)>P(i)-P(i-1), i.e., if the arrival time difference is larger than the timestamp difference. We define the (relative) inter-arrival time, d(i) as d(i) =3D p(i)-p(i-1)-(P(i)-P(i-1)) Best regards Sergio --_000_D21571530BF9644D9A443D6BD95B910315499132xmbrcdx12ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

 <= /p>

Stephan Asked: “Do you see any problems with using an RTP header extension w= ith absolute send timestamps?” (with send times= tamps relative to the actual send time and not the capture timestamps as th= e normal RTP timestamp unit represents).

 <= /p>

Not only don’t I se= e any issue with absolute  timestamps, but I note that the processing = of inter-departure times at the receiver (i.e., the resulting measurements being an inter-ARRIVAL time measurement) is often brittle.

 <= /p>

That is, there are LOTS o= f (application-end to application-end) transport related things that result= in the transport time of A GIVEN packet NOT to be  nominal. By “not nominal” I mean statistically UNEXPECTED from what you= would think should occur if the measurement sample was created by what was= assumed to be an underlying Normal, Gaussian process.

 <= /p>

Things like software fire= walls burping when doing some non-forwarding related processing (e.g., garb= age collection), OSs adding strange delays after application-layer timestamps have been applied to the headers – not to mention the occ= asional burps in normal/expected Internet transport. The net result is that= a pdf created from a histogram of individual packet delays would be one-si= ded and pretty different from a normal distribution. Why process these data samples as IF they were created by a = Gaussian process – when you KNOW that they are not?=

 <= /p>

A SINGLE packet “ou= tlier delay” not being “nominal” effects TWO bad (inter-a= rrival time) measurement data points. And most of the processing I have see= n proposed on such data (e.g., Kalman filtering) is in the form of Euclidean processi= ng in which the ERROR in the measurement is SQUARED before further processi= ng. This effectively BIASES the very control mechanism you want to use with= outlier data!

 <= /p>

So, like Stephan, I would= prefer to have the ability to have absolute timestamps in the header exten= sion – as I desire to do some non-linear outlier filtering BEFORE traditional signal processing is applied from the output of my meas= urements. IMHO we ought not to be codifying an inter-arrival timestamp in t= he header when you could generate (if you wanted) inter-arrival measurement= s from the absolute quantities.

 <= /p>

Michael Ramalho

 <= /p>

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf= .org] On Behalf Of Sergio Garcia Murillo
Sent: Wednesday, December 05, 2012 4:28 AM
To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

El 05/12/2012 9:47, Stefan Holmer escribi=F3:

 

 = ;

On Tue, Dec 4, 2012 at 6:27 PM, John Lesl= ie <= john@jlc.net> wrote:

Stefan Hol= mer <holmer@googl= e.com> wrote:
>
> Thinking further about this, there seems to be a couple of benefits wi= th
> defining a new, absolute, send timestamp header extension. If a relay<= br> > approach to conference servers are used, the relaying server can simpl= y
> rewrite the send timestamp of a packet to correspond to the time it wa= s
> relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captur= ed
> and sent by different senders (with different clocks).
>
> With a send timestamp offset, accomplishing the same thing would requi= re
> rewriting both the timestamp offset and the NTP time in the correspond= ing
> RTCP SR reports. And to keep video synchronized with audio the RTCP pa= cket
> for the audio streams must also be rewritten in a similar way. This ma= y not
> even be possible if the audio stream is relayed through a different se= rver.
>
> Do you see any problems with using an RTP header extension with absolu= te
> send timestamps? Are there any benefits with the send timestamp offset=
> header extension I might be missing?

   I must admit to failing to u= nderstand what problem you think this would
solve. :^(

 

I might have gone into the details too fa= st above, sorry about that.

 

I'm specifically thinking of the problem = of measuring the changes in one-way delay by calculating the relative inter= -arrival time. In http://tools.ietf.org/html/draft= -alvestrand-rtcweb-congestion-03 we calculate this as

 

d(i) =3D t(i) - t(i-1) - (T(i) - T(i-1)),=

 

where t(i) is the receive-time and T(i) i= s the send-time of a packet. The send-time can be stamped on the packet in = different ways, either with an offset relative to the RTP timestamp or as an absolute send time.

 

With a relaying conference server a recei= ving client may receive several streams, originating from different sending= clients. As all of those streams have been relayed by the same conference server we may want to use all of those streams to estimate= bandwidth between the server and the receiving client. When doing that, th= e problems described in my initial e-mail arise.

 

 

Hi Steffan,

Not considering packet losses, to calculate the t(i) reception time of a fr= ame, wouldn't we just need the timestamp in the last RTP packet of a frame?= I am still struggling to understand the draft to implement it in my media = server, so maybe my suggestion is quite dumb, but, if we had absolute timestamps for each packet, could we i= mprove the algorithm to work on a per rtp packet base instead of a per fram= e?  Something like:


&n=
bsp;  At the receiving side we are observing incoming packets, where e=
ach 
&n=
bsp;  packet has an absolute sent timestamp P(i).
 
&n=
bsp;  Each packet is assigned a receive time p(i), which corresponds t=
o the
&n=
bsp;  time at which the packet has been received.  A packet is de=
layed 
&n=
bsp;  relative to its predecessor if p(i)-p(i-1)>P(i)-P(i-1), =
i.e., if the 
&n=
bsp;  arrival time difference is larger than the timestamp differ=
ence.
 
&n=
bsp;  We define the (relative) inter-arrival time, d(i) as<=
/span>
 
 &=
nbsp;   d(i) =3D p(i)-p(i-1)-(P(i)-P(i-1))=



Best regards
Sergio

--_000_D21571530BF9644D9A443D6BD95B910315499132xmbrcdx12ciscoc_-- From holmer@google.com Thu Dec 6 02:26:30 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517621F8546 for ; Thu, 6 Dec 2012 02:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juSdI9A5QEht for ; Thu, 6 Dec 2012 02:26:29 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF81721F8545 for ; Thu, 6 Dec 2012 02:26:28 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6781514oag.31 for ; Thu, 06 Dec 2012 02:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=neVNBzy3YjT9EKKh8mk+ZM+eojFwaYbD9GXYqSIc68k=; b=Iwd5w61Up5KjrP31vm1aCXod+ozu3GBvQt8kGX80y+fCBd2YE/qyvkl6EctJqsUx4G PpZTfGTyvQoesD4BF5iV9OOKzmr9Df1dgdaBqq1RW4rvbLzmqakMipS0o+ZTnFdLhbX7 a1c6KYQa9CyEBbWGXpvIne1jp5MvRVxDYCVrc/UvksFyeBo0nc+StyjYhvcyWE6TMGGV ds1SZapB/Bz4ilH+9Dg+MKv8Ab5+fwCv13Oq5MoQPr9AOerwIIIpKWmyS1TpC7WwPEYd x0g3m+pDbOAKidxeVfjkqZ+w8x5l7fKe2KR8oFkdfuZa+LBxQaKmAwqP5YbvkNdlyblx qATg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=neVNBzy3YjT9EKKh8mk+ZM+eojFwaYbD9GXYqSIc68k=; b=ke8ssMZ69aoyRaEQsNEeDl1MoeeobmwL/fS+WUTkKScNeSEoc7doFjqgD8U9Z2Iwbq wLmjZpUPHMp3sHS8jIdt5hABnLqKW24szC0u2n3h0K8gE+2vCDVUN/BEe95G4tVqAbS4 aYVMnA9IRy+zJ2BVrfNV45IOHsEFbWKk+eO8Rghb8Eqnj/Yw79zeZyuchoTPRFimJRUp TMJs80/EgKwHTFuy3WA5xmkcEwN8trDNXrTjJxU7XWwfsugZIYtujQuEpiqMGXiJx7hO et3EZzglpMec9vx1BPhfXz1mCwVCcnktrZA7AFh/QvOi4ZrfdxW0d6KBPcvN+TWmFlXO /GNQ== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr556630oeg.17.1354789588230; Thu, 06 Dec 2012 02:26:28 -0800 (PST) Sender: holmer@google.com Received: by 10.76.73.196 with HTTP; Thu, 6 Dec 2012 02:26:28 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Dec 2012 11:26:28 +0100 X-Google-Sender-Auth: lqoGWERGfYQlqpsTY1cIj_UYPB0 Message-ID: From: Stefan Holmer To: "Michael Ramalho (mramalho)" Content-Type: multipart/alternative; boundary=e89a8fb1f47826e39604d02c88d9 X-Gm-Message-State: ALoCoQklDz8Zzg9fn+Cnrzo/I1u9e3OZpLSAZeUI64EYpcQlNHXSXUOn31kDQ5Uj260/dcPka5KT5uWgte6dI7AxP+OKG0nFpKpDQWVJsCkWXUDnx0/JRhPaiWMQIF0jl2c3wggMr25CU7Uhv2dLdMTeOlmBxY2kTR1s2JlSbWFHJfBchxA69KbhMNwDS+bRiQtiPlMVfiHl Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 10:26:30 -0000 --e89a8fb1f47826e39604d02c88d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Dec 5, 2012 at 8:59 PM, Michael Ramalho (mramalho) < mramalho@cisco.com> wrote: > All,**** > > ** ** > > Stephan Asked: =93Do you see any problems with using an RTP header > extension with absolute send timestamps?=94 (with send timestamps relativ= e > to the actual send time and not the capture timestamps as the normal RTP > timestamp unit represents).**** > > ** ** > > Not only don=92t I see any issue with absolute timestamps, but I note th= at > the processing of inter-departure times at the receiver (i.e., the > resulting measurements being an inter-ARRIVAL time measurement) is often > brittle.**** > > ** ** > > That is, there are LOTS of (application-end to application-end) transport > related things that result in the transport time of A GIVEN packet NOT to > be nominal. By =93not nominal=94 I mean statistically UNEXPECTED from wh= at you > would think should occur if the measurement sample was created by what wa= s > assumed to be an underlying Normal, Gaussian process.**** > > ** ** > > Things like software firewalls burping when doing some non-forwarding > related processing (e.g., garbage collection), OSs adding strange delays > after application-layer timestamps have been applied to the headers =96 n= ot > to mention the occasional burps in normal/expected Internet transport. Th= e > net result is that a pdf created from a histogram of individual packet > delays would be one-sided and pretty different from a normal distribution= . > Why process these data samples as IF they were created by a Gaussian > process =96 when you KNOW that they are not?**** > > ** ** > > A SINGLE packet =93outlier delay=94 not being =93nominal=94 effects TWO b= ad > (inter-arrival time) measurement data points. And most of the processing = I > have seen proposed on such data (e.g., Kalman filtering) is in the form o= f > Euclidean processing in which the ERROR in the measurement is SQUARED > before further processing. This effectively BIASES the very control > mechanism you want to use with outlier data!**** > > ** ** > > So, like Stephan, I would prefer to have the ability to have absolute > timestamps in the header extension =96 as I desire to do some non-linear > outlier filtering BEFORE traditional signal processing is applied from th= e > output of my measurements. IMHO we ought not to be codifying an > inter-arrival timestamp in the header when you could generate (if you > wanted) inter-arrival measurements from the absolute quantities. > I'm not sure we are talking about the same thing here. RFC 5450 defines an RTP header extension which allows you to specify how much earlier or later than the accompanying RTP timestamp a packet was sent. Adding the offset to the RTP timestamp gives you the absolute packet send-time in the RTP timestamp domain. So as far as I can see that should be enough for what you want to do. The problem arises when you want to jointly process packets from different sending clients which have been relayed through the same conference server because the RTP timestamps will be in different time domains. > **** > > ** ** > > Michael Ramalho**** > > ** ** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Sergio Garcia Murillo > *Sent:* Wednesday, December 05, 2012 4:28 AM > *To:* rmcat@ietf.org > *Subject:* Re: [rmcat] Send timestamps**** > > ** ** > > El 05/12/2012 9:47, Stefan Holmer escribi=F3:**** > > ** ** > > ** ** > > On Tue, Dec 4, 2012 at 6:27 PM, John Leslie wrote:**** > > Stefan Holmer wrote: > > > > Thinking further about this, there seems to be a couple of benefits wit= h > > defining a new, absolute, send timestamp header extension. If a relay > > approach to conference servers are used, the relaying server can simply > > rewrite the send timestamp of a packet to correspond to the time it was > > relayed. Doing so the receiver can jointly process all streams being > > received from the relay server, even though they were initially capture= d > > and sent by different senders (with different clocks). > > > > With a send timestamp offset, accomplishing the same thing would requir= e > > rewriting both the timestamp offset and the NTP time in the correspondi= ng > > RTCP SR reports. And to keep video synchronized with audio the RTCP > packet > > for the audio streams must also be rewritten in a similar way. This may > not > > even be possible if the audio stream is relayed through a different > server. > > > > Do you see any problems with using an RTP header extension with absolut= e > > send timestamps? Are there any benefits with the send timestamp offset > > header extension I might be missing?**** > > I must admit to failing to understand what problem you think this woul= d > solve. :^(**** > > ** ** > > I might have gone into the details too fast above, sorry about that.**** > > ** ** > > I'm specifically thinking of the problem of measuring the changes in > one-way delay by calculating the relative inter-arrival time. In > http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 we > calculate this as**** > > ** ** > > d(i) =3D t(i) - t(i-1) - (T(i) - T(i-1)),**** > > ** ** > > where t(i) is the receive-time and T(i) is the send-time of a packet. The > send-time can be stamped on the packet in different ways, either with an > offset relative to the RTP timestamp or as an absolute send time.**** > > ** ** > > With a relaying conference server a receiving client may receive several > streams, originating from different sending clients. As all of those > streams have been relayed by the same conference server we may want to us= e > all of those streams to estimate bandwidth between the server and the > receiving client. When doing that, the problems described in my initial > e-mail arise.**** > > ** ** > > ** ** > > Hi Steffan, > > Not considering packet losses, to calculate the t(i) reception time of a > frame, wouldn't we just need the timestamp in the last RTP packet of a > frame? > Yes. > I am still struggling to understand the draft to implement it in my media > server, so maybe my suggestion is quite dumb, but, if we had absolute > timestamps for each packet, could we improve the algorithm to work on a p= er > rtp packet base instead of a per frame? Something like: > Sure, but that's possible with send timestamp offsets relative to the rtp timestamp as well, as already proposed. > > > **** > > At the receiving side we are observing incoming packets, where each **= ** > > packet has an absolute sent timestamp P(i).**** > > ** ** > > Each packet is assigned a receive time p(i), which corresponds to the*= *** > > time at which the packet has been received. A packet is delayed **** > > relative to its predecessor if p(i)-p(i-1)>P(i)-P(i-1), i.e., if the *= *** > > arrival time difference is larger than the timestamp difference.**** > > ** ** > > We define the (relative) inter-arrival time, d(i) as**** > > ** ** > > d(i) =3D p(i)-p(i-1)-(P(i)-P(i-1))**** > > > > Best regards > Sergio**** > --e89a8fb1f47826e39604d02c88d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">


On Wed, Dec 5, 2012 at 8:59 PM, Michael Ramalho (mramalho) <mramalho@cisco.com> wrote:

All,=

=A0<= /p>

Stephan Asked: =93= Do you see any problems with using an RTP header extension with = absolute send timestamps?=94 (with send timestamp= s relative to the actual send time and not the capture timestamps as the no= rmal RTP timestamp unit represents).

=A0<= /p>

Not only don=92t I see an= y issue with absolute =A0timestamps, but I note that the processing of inte= r-departure times at the receiver (i.e., the resulting measurements being an inter-ARRIVAL time measurement) is often brittle.

=A0<= /p>

That is, there are LOTS o= f (application-end to application-end) transport related things that result= in the transport time of A GIVEN packet NOT to be=A0 nominal. By =93not nominal=94 I mean statistically UNEXPECTED from what you would t= hink should occur if the measurement sample was created by what was assumed= to be an underlying Normal, Gaussian process.

=A0<= /p>

Things like software fire= walls burping when doing some non-forwarding related processing (e.g., garb= age collection), OSs adding strange delays after application-layer timestamps have been applied to the headers =96 not to mention the occasio= nal burps in normal/expected Internet transport. The net result is that a p= df created from a histogram of individual packet delays would be one-sided = and pretty different from a normal distribution. Why process these data samples as IF they were created by a = Gaussian process =96 when you KNOW that they are not?<= /p>

=A0<= /p>

A SINGLE packet =93outlie= r delay=94 not being =93nominal=94 effects TWO bad (inter-arrival time) mea= surement data points. And most of the processing I have seen proposed on such data (e.g., Kalman filtering) is in the form of Euclidean processi= ng in which the ERROR in the measurement is SQUARED before further processi= ng. This effectively BIASES the very control mechanism you want to use with= outlier data!

=A0<= /p>

So, like Stephan, I would= prefer to have the ability to have absolute timestamps in the header exten= sion =96 as I desire to do some non-linear outlier filtering BEFORE traditional signal processing is applied from the output of my meas= urements. IMHO we ought not to be codifying an inter-arrival timestamp in t= he header when you could generate (if you wanted) inter-arrival measurement= s from the absolute quantities.


I'm not sure we are = talking about the same thing here. RFC 5450 defines an RTP header extension= which allows you to specify how much earlier or later than the accompanyin= g RTP timestamp a packet was sent. Adding the offset to the RTP timestamp g= ives you the absolute packet send-time in the RTP timestamp domain. So as f= ar as I can see that should be enough for what you want to do.=A0

The problem arises when you want to jointly= process packets from different sending clients which have been relayed thr= ough the same conference server because the RTP timestamps will be in diffe= rent time domains.
=A0

=A0<= /p>

Michael Ramalho=

=A0<= /p>

From: rmcat-bounces@ietf.org [mailto:rmcat-bou= nces@ietf.org] On Behalf Of Sergio Garcia Murillo
Sent: Wednesday, December 05, 2012 4:28 AM
To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

=A0

El 05/12/2012 9:47, Stefan Holmer escribi=F3:=

=A0

=A0=

On Tue, Dec 4, 2012 at 6:27 PM, John Lesl= ie <john@jlc.net> wrote:

Stefan Hol= mer <holmer@google.com> wrote:
>
> Thinking further about this, there seems to be a couple of benefits wi= th
> defining a new, absolute, send timestamp header extension. If a relay<= br> > approach to conference servers are used, the relaying server can simpl= y
> rewrite the send timestamp of a packet to correspond to the time it wa= s
> relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captur= ed
> and sent by different senders (with different clocks).
>
> With a send timestamp offset, accomplishing the same thing would requi= re
> rewriting both the timestamp offset and the NTP time in the correspond= ing
> RTCP SR reports. And to keep video synchronized with audio the RTCP pa= cket
> for the audio streams must also be rewritten in a similar way. This ma= y not
> even be possible if the audio stream is relayed through a different se= rver.
>
> Do you see any problems with using an RTP header extension with absolu= te
> send timestamps? Are there any benefits with the send timestamp offset=
> header extension I might be missing?

=A0 =A0I must admit to failing to underst= and what problem you think this would
solve. :^(

=A0

I might have gone into the details too fa= st above, sorry about that.

=A0

I'm specifically thinking of the prob= lem of measuring the changes in one-way delay by calculating the relative i= nter-arrival time. In=A0http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03= we calculate this as

=A0

d(i) =3D t(i) - t(i-1) - (T(i) - T(i-1)),=

=A0

where t(i) is the receive-time and T(i) i= s the send-time of a packet. The send-time can be stamped on the packet in = different ways, either with an offset relative to the RTP timestamp or as an absolute send time.

=A0

With a relaying conference server a recei= ving client may receive several streams, originating from different sending= clients. As all of those streams have been relayed by the same conference server we may want to use all of those streams to estimate= bandwidth between the server and the receiving client. When doing that, th= e problems described in my initial e-mail arise.

=A0

=A0

Hi Steffan,

Not considering packet losses, to calculate the t(i) reception time of a fr= ame, wouldn't we just need the timestamp in the last RTP packet of a fr= ame?


Yes.
=A0

I am still struggling to understand the draft to implement it in my media = server, so maybe my suggestion is quite dumb, but, if we had absolute timestamps for each packet, could we i= mprove the algorithm to work on a per rtp packet base instead of a per fram= e?=A0 Something like:


Sure, but that's possible with send timestamp offsets = relative to the rtp timestamp as well, as already proposed.
=A0
<= div>



=A0=A0 At the receiving side we are o=
bserving incoming packets, where each 
=A0=A0=A0packet has an absolute sent =
timestamp P(i).
=A0
=A0=A0 Each packet is assigned a rece=
ive time p(i), which corresponds to the
=A0=A0 time at which the packet has b=
een received.=A0 A packet is delayed 
=A0=A0=A0relative to its predecessor =
if p(i)-p(i-1)>P(i)-P(i-1), i.e., if the 
=A0=A0=A0arrival time difference is l=
arger than the timestamp difference.
=A0
=A0=A0 We define the (relative) inter=
-arrival time, d(i) as
=A0
 =A0=A0=A0=A0d(i) =3D p(i)-p(i-1)-(P(=
i)-P(i-1))



Best regards
Sergio


--e89a8fb1f47826e39604d02c88d9-- From lars@netapp.com Thu Dec 13 05:04:15 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4321F881A for ; Thu, 13 Dec 2012 05:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.308 X-Spam-Level: X-Spam-Status: No, score=-10.308 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvkpgMHjh3ie for ; Thu, 13 Dec 2012 05:04:15 -0800 (PST) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1B60821F8819 for ; Thu, 13 Dec 2012 05:04:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,273,1355126400"; d="scan'208";a="230573254" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 13 Dec 2012 05:04:14 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qBDD4DXK014371; Thu, 13 Dec 2012 05:04:14 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.108]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 05:04:13 -0800 From: "Eggert, Lars" To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [rmcat] Minutes & draft updates Thread-Index: AQHNyVop5xoS1uaFx0GbDS5AsgT00JgXWBgA Date: Thu, 13 Dec 2012 13:04:12 +0000 Message-ID: References: <201211231008.46222.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201211231008.46222.mkuehle@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2EF8DF6C2A4ADE43B12098CC658DE821@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rmcat] Minutes & draft updates X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:04:15 -0000 Hi, On Nov 23, 2012, at 10:08, Mirja K=FChlewind wrote: > @Draft authors: Please remember that we have a tight milestone plan. We a= re=20 > supposed to adopt the first wg docs on requirement and evaluation criteri= a in=20 > December. As there has been a lot discussion during the meeting, I don't= =20 > think we are able to adopt the current versions. So please update the dra= fts=20 > as soon as possible! I'd like to second this. It's been very quiet on the list since the Atlanta= meeting. Lars= From vsingh.ietf@gmail.com Thu Dec 13 06:32:40 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F86021F88F4 for ; Thu, 13 Dec 2012 06:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq1PBQ+yAilL for ; Thu, 13 Dec 2012 06:32:39 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2521F86F9 for ; Thu, 13 Dec 2012 06:32:39 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2056837obc.31 for ; Thu, 13 Dec 2012 06:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=NYRl8uZZBntSxnnrfmkv9cdcObY+uvEh7NmjKbB6mng=; b=lamlYHTWPNJj9EowU5Nf1kKmBcazMno2UFYYYFFY55oBIMBE+YR6WDigDyG7+Jc8Di W9Go/YeE/SlRR310crp644aHlIXOsehukPrHwclcyU4gb8GNCGY1owTF4DCJVqk9zpHM l2nLNAZVlS09LwI0/bc6VWzZVEWzDUkFR44Ad0bqBwUrkXT36o8aKlXqBT6DSbw7kh7o pqWcwdEJiZd/nWe5scPNetIOiqzMwFc/Bh05Ow2waEzhfYHHarWSAZj6Cng/8Xmt8HqD lgQngV28YTwKdTWornRQgC2rkBib9tvbVtDArvJx0vTj3U9ftJnHkLqZ2cLktnut4M4a ylJg== Received: by 10.60.31.227 with SMTP id d3mr1602354oei.70.1355409158976; Thu, 13 Dec 2012 06:32:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.17.68 with HTTP; Thu, 13 Dec 2012 06:32:17 -0800 (PST) In-Reply-To: References: <201211231008.46222.mkuehle@ikr.uni-stuttgart.de> From: Varun Singh Date: Thu, 13 Dec 2012 16:32:17 +0200 Message-ID: To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rmcat] Minutes & draft updates X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:32:40 -0000 Hi, I was away on vacation for the last 4 weeks, but an updated version of the evaluation draft will be available soon. However, at the Atlanta meeting there was discussion around existing ITU quality models which we can use as Quality Metrics (other than PSNR). Someone volunteered to send the related documents or pointers to them, but I haven't received them. Thanks, -Varun On Thu, Dec 13, 2012 at 3:04 PM, Eggert, Lars wrote: > Hi, > > On Nov 23, 2012, at 10:08, Mirja K=FChlewind wrote: >> @Draft authors: Please remember that we have a tight milestone plan. We = are >> supposed to adopt the first wg docs on requirement and evaluation criter= ia in >> December. As there has been a lot discussion during the meeting, I don't >> think we are able to adopt the current versions. So please update the dr= afts >> as soon as possible! > > I'd like to second this. It's been very quiet on the list since the Atlan= ta meeting. > > Lars --=20 http://www.netlab.tkk.fi/~varun/ From lars@netapp.com Thu Dec 13 06:42:43 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0A21F8B1A for ; Thu, 13 Dec 2012 06:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n438ZCZfKe9 for ; Thu, 13 Dec 2012 06:42:43 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0062421F8B1B for ; Thu, 13 Dec 2012 06:42:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,273,1355126400"; d="scan'208";a="217547" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 13 Dec 2012 06:42:42 -0800 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id qBDEgeRD008839; Thu, 13 Dec 2012 06:42:42 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.108]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 06:42:41 -0800 From: "Eggert, Lars" To: Varun Singh Thread-Topic: [rmcat] Minutes & draft updates Thread-Index: AQHNyVop5xoS1uaFx0GbDS5AsgT00JgXWBgAgAAYnYCAAALmAA== Date: Thu, 13 Dec 2012 14:42:40 +0000 Message-ID: References: <201211231008.46222.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6DD11B7020662D4CA50E5FCB598411C0@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rmcat] Minutes & draft updates X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:42:43 -0000 Hi, On Dec 13, 2012, at 15:32, Varun Singh wrote: > I was away on vacation for the last 4 weeks, but an updated version of th= e > evaluation draft will be available soon. thanks! > However, at the Atlanta meeting there was discussion around existing > ITU quality models which we can use as Quality Metrics (other than PSNR). > Someone volunteered to send the related documents or pointers to them, > but I haven't received them. In http://eggert.org/papers/2007-infocom-dccp.pdf, we used the E-Model to g= enerate R scores. Is this what was referred to? (Apologies if you've alread= y looked at that.) Lars= From vsingh.ietf@gmail.com Thu Dec 13 07:07:44 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83F21F8B54 for ; Thu, 13 Dec 2012 07:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ISQIouQsra7 for ; Thu, 13 Dec 2012 07:07:43 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2011021F8B44 for ; Thu, 13 Dec 2012 07:07:43 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2104264obc.31 for ; Thu, 13 Dec 2012 07:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WEzHcZsCwL8LOrKUOeeTYS0SmCo5E78i2rrSQHq+HEQ=; b=0Suz7xYlfr+TyWFU76+vUhpZo8E28Buj6MGedV8M1PxEg6RgVThpgbfNsKFoTG8F1R L7bZnDrmEEyYyNuqZmHFYpmkXPvdyu/2YZGxuirZ01nsucIPhmynk1RPNYLAdqnbZUcs rJzogDc2/nroTZRknBOub87Ish2RX9sAu+ad/1eWu2vTs53XknzXdJdwxCDaeqTHFvgn KHUaarkWJBPsdzJ5YXmS0gQpSTZbXj22nzsruwWNTnkRAqNx+w2MMy2czHf+aVB7Qzgu aQcGyUl6zRZzZ+CfrZs4aLLncwUlxtah7rFT8W0/sk7vYiw0wcIAJimHVorI2WTHdE8R UrMQ== Received: by 10.182.121.97 with SMTP id lj1mr1707744obb.63.1355411262727; Thu, 13 Dec 2012 07:07:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.17.68 with HTTP; Thu, 13 Dec 2012 07:07:22 -0800 (PST) In-Reply-To: References: <201211231008.46222.mkuehle@ikr.uni-stuttgart.de> From: Varun Singh Date: Thu, 13 Dec 2012 17:07:22 +0200 Message-ID: To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [rmcat] Minutes & draft updates X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:07:44 -0000 Hi, >> However, at the Atlanta meeting there was discussion around existing >> ITU quality models which we can use as Quality Metrics (other than PSNR). >> Someone volunteered to send the related documents or pointers to them, >> but I haven't received them. > > In http://eggert.org/papers/2007-infocom-dccp.pdf, we used the E-Model to generate R scores. Is this what was referred to? (Apologies if you've already looked at that.) > AFAIK, the E-model is for audio. However, the comment at the meeting was in the context of video. Per the minutes (http://trac.tools.ietf.org/wg/rmcat/minutes?item=minutes-85-rmcat.html): Christian: There's a lot known about this at the ITU, they have some standard models So if there are ITU standard models for video then I'd like to look at them before I submit a new version of the document. > Lars -Varun -- http://www.netlab.tkk.fi/~varun/ From p.ohanlon@gmail.com Thu Dec 13 07:41:46 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7C821F8B6C for ; Thu, 13 Dec 2012 07:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD56R+Knb-IZ for ; Thu, 13 Dec 2012 07:41:44 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E74121F8B37 for ; Thu, 13 Dec 2012 07:41:43 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so1027814wey.31 for ; Thu, 13 Dec 2012 07:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RPKPyARGk0xHILm8ofImOwc2MxULk+ThqZGYtClSGCs=; b=mngj6JHiiJOMOGAB09g2omeiI9TGpbOWqIxcDEzI3lik/L/r+lJcCRVBCeNGBobdq8 F8FtM+IJAy9ox9tTztF9gQ0XPUn/rjw+pzFgXS2z+zBJ9mnYnH6jTS1X7ZqrPxWYEQzr fk/sFK3EmIBKxLo4ffRgFKBM2nP/c2/vMlCOiuYnNvB/lF3FVeHFt9ViEV8GWufok9TP J5wI+Fwx+eDFYa3pSP3t4wc7RZ/z9cZSXwFCC6aP89KjUagqn+NELRN7N15/IcHlI9+2 Vqf1xobeFREL8eq2dJ/0//pWNxZm6RiznwhQEI+adDR17D6wReppWyifGto//ZosCH4z wPZA== Received: by 10.180.92.74 with SMTP id ck10mr24959384wib.9.1355413302871; Thu, 13 Dec 2012 07:41:42 -0800 (PST) Received: from ?IPv6:2001:470:1f09:d24:de4:7aa3:f526:aa54? ([2001:470:1f09:d24:de4:7aa3:f526:aa54]) by mx.google.com with ESMTPS id g2sm3129122wiy.0.2012.12.13.07.41.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 07:41:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: Date: Thu, 13 Dec 2012 15:41:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <04A309AF-6C7E-4394-9074-4E8867F1DC94@gmail.com> References: <201211231008.46222.mkuehle@ikr.uni-stuttgart.de> To: Varun Singh X-Mailer: Apple Mail (2.1283) Cc: "" , "Eggert, Lars" Subject: Re: [rmcat] Minutes & draft updates X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:41:46 -0000 Hi Varun, For video there's all the stuff from the Video Quality Experts Group = (VQEG): http://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx Which have led to a number of ITU docs: ITU-T P.920, ITU-T Rec. J.247, = J248, ITU-R Rec. BT.1866/7, J340. The problem is that most of this work = seems to be based on proprietary systems, which means it gets expensive = to run tests. There are a few systems out there (which provide for more = than things like PSNR or SSIM) that are available for download including = VQM from ITS: = http://www.its.bldrdoc.gov/resources/video-quality-research/guides-and-tut= orials/description-of-vqm-tools.aspx and MOVIE (and others) from Utexas: http://live.ece.utexas.edu/research/Quality/index.htm For more info see: https://en.wikipedia.org/wiki/PEVQ https://en.wikipedia.org/wiki/Video_quality Piers On 13 Dec 2012, at 15:07, Varun Singh wrote: > Hi, >=20 >>> However, at the Atlanta meeting there was discussion around existing >>> ITU quality models which we can use as Quality Metrics (other than = PSNR). >>> Someone volunteered to send the related documents or pointers to = them, >>> but I haven't received them. >>=20 >> In http://eggert.org/papers/2007-infocom-dccp.pdf, we used the = E-Model to generate R scores. Is this what was referred to? (Apologies = if you've already looked at that.) >>=20 >=20 > AFAIK, the E-model is for audio. >=20 > However, the comment at the meeting was in the context of video. Per > the minutes > = (http://trac.tools.ietf.org/wg/rmcat/minutes?item=3Dminutes-85-rmcat.html)= : > Christian: There's a lot known about this at the ITU, they = have some > standard models >=20 > So if there are ITU standard models for video then I'd like to look at = them > before I submit a new version of the document. >=20 >> Lars > -Varun >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ From mzanaty@cisco.com Sun Dec 16 07:08:27 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E4921F847B for ; Sun, 16 Dec 2012 07:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YipgHun9PnsS for ; Sun, 16 Dec 2012 07:08:25 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB821F846B for ; Sun, 16 Dec 2012 07:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10102; q=dns/txt; s=iport; t=1355670505; x=1356880105; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=48l8qEHeJ/kJfOcYOO7WnF/ZGs9gqAS/UlnfPLpNqK8=; b=CRSGGFKV/82opIvVYcOJQUzK7edDjc4hEhptoMxeKv9kJopn4BCHxWi6 M+kCW6CrLrxnWW6A0duRuM0nrHLJIN05XYz01LOOAYINyXWsIOO3/EaiS O0xWBCfcTk1o5hUe5A+gkSCeN58BDEb7FwZiDBIPHQIDKRNPDpa1prbHM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAP7izVCtJV2a/2dsb2JhbABFgkmyYQGJFxZzgh4BAQEELTshAgEIEQQBAQsdBzIUCQgCBAESCIgLDLlBjF2DYmEDlyaPLIJzgiI X-IronPort-AV: E=Sophos;i="4.84,294,1355097600"; d="scan'208,217";a="153256420" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 16 Dec 2012 15:08:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBGF8O9I007254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 15:08:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sun, 16 Dec 2012 09:08:24 -0600 From: "Mo Zanaty (mzanaty)" To: Stefan Holmer , rmcat WG Thread-Topic: [rmcat] Send timestamps Thread-Index: AQHN0gHghOHemZI0p0CqIdxtCIphjpgbkKuA Date: Sun, 16 Dec 2012 15:08:24 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.12] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F6477E1xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 15:08:27 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F6477E1xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please clarify "absolute". Do you mean another RTP timestamp using the same= units but a random offset from the main RTP timestamp, and no implied sync= across multiple RTP sessions? Or NTP timestamps with NTP units and implied= sync across all RTP sessions (within the same sync domain, currently defin= ed to be CNAME)? Please also clarify "relay conference server", as there are many RTP topolo= gies for conferencing. I think you are probably referring to a source proje= ction mixer. Rewriting RTCP is standard practice for those, as well as most= mixers. In fact, I can't envision when it would be possible to blindly rel= ay RTCP in any mixer/topology. So I'm not sure what complications you see a= rising from the use of RFC 5450. Mo From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of S= tefan Holmer Sent: Tuesday, December 04, 2012 4:23 AM To: rmcat WG Subject: [rmcat] Send timestamps Hi, In draft-alvestrand-rtcweb-congestion-01 we proposed using a send timestamp RTP head= er extension for measuring the packet inter-arrival time offset. In 02 this was revi= sed to instead reference RFC 5450, whic= h specifies a header extension for specifying the send timestamp as an offs= et relative to the RTP timestamp. Thinking further about this, there seems to be a couple of benefits with de= fining a new, absolute, send timestamp header extension. If a relay approac= h to conference servers are used, the relaying server can simply rewrite th= e send timestamp of a packet to correspond to the time it was relayed. Doin= g so the receiver can jointly process all streams being received from the r= elay server, even though they were initially captured and sent by different= senders (with different clocks). With a send timestamp offset, accomplishing the same thing would require re= writing both the timestamp offset and the NTP time in the corresponding RTC= P SR reports. And to keep video synchronized with audio the RTCP packet for= the audio streams must also be rewritten in a similar way. This may not ev= en be possible if the audio stream is relayed through a different server. Do you see any problems with using an RTP header extension with absolute se= nd timestamps? Are there any benefits with the send timestamp offset header= extension I might be missing? /Stefan --_000_3879D71E758A7E4AA99A35DD8D41D3D90F6477E1xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please clarify “absolute”. = Do you mean another RTP timestamp using the same units but a random offset = from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or NTP timestamps with NTP units and implied sync across all RTP= sessions (within the same sync domain, currently defined to be CNAME)?

 

Please also clarify “relay confer= ence server”, as there are many RTP topologies for conferencing. I th= ink you are probably referring to a source projection mixer. Rewriting RTCP is standard practice for those, as well as most mixers. In fact, I ca= n’t envision when it would be possible to blindly relay RTCP in any m= ixer/topology. So I’m not sure what complications you see arising fro= m the use of RFC 5450.

 

Mo

 

From: rmcat-bo= unces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

 

Hi,

 

In draft-alvestrand-rtcweb-congestion-01 we proposed using a send t= imestamp RTP header extension for measuring the packet inter-arrival time o= ffset. In 02 this was revised to instead reference RFC 5450, which specifie= s a header extension for specifying the send timestamp as an offset relativ= e to the RTP timestamp.

 

Thinking further about this, there seems = to be a couple of benefits with defining a new, absolute, send timestamp he= ader extension. If a relay approach to conference servers are used, the relaying server can simply rewrite the send timestamp of a p= acket to correspond to the time it was relayed. Doing so the receiver can j= ointly process all streams being received from the relay server, even thoug= h they were initially captured and sent by different senders (with different clocks). =

 

With a send timestamp offset, accomplishi= ng the same thing would require rewriting both the timestamp offset and the= NTP time in the corresponding RTCP SR reports. And to keep video synchronized with audio the RTCP packet for the audio streams must a= lso be rewritten in a similar way. This may not even be possible if the aud= io stream is relayed through a different server.

 

Do you see any problems with using an RTP= header extension with absolute send timestamps? Are there any benefits wit= h the send timestamp offset header extension I might be missing?

 

/Stefan

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F6477E1xmbrcdx14ciscoc_-- From holmer@google.com Mon Dec 17 03:00:57 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6649321F8A95 for ; Mon, 17 Dec 2012 03:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZo+GwnSwXs5 for ; Mon, 17 Dec 2012 03:00:53 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBA1A21F8A98 for ; Mon, 17 Dec 2012 03:00:52 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so2643424bku.31 for ; Mon, 17 Dec 2012 03:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aoyGA8WaFx1H9AOJUNiKCpWpscyd5nMWXBoHbZUawWY=; b=eINZLCrDdhaVfkWVmrIoeTRFHXYSlTJ4zswTNTXb7ICbl18thG4PeKo6UBXOjMsEmg Kp1v8flE5sOeBz7gEgAQtwVpa4jdB3jnZgmVZt0UTXtU2xOBoDaA1cWh/UE+3N3KW4DU S5ikzR8qoiGWzf1GektXweMqoa9mA9aaNLUAd3uj5V7g5WNNco7BYXltcVjtpPxfi01f K07R25LEeXR3DS/gsSIw3ZHMqvdnzCJCCtgj5MbpJLmJ21FK6BQOLNgZXBxlf4uKWtie Efjde+0q55quO6SPXjYmfpsVhOMzH+f0kEPvU4wraHzAkYJ0hfwXMgEpaQA851cOBNF/ UNEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aoyGA8WaFx1H9AOJUNiKCpWpscyd5nMWXBoHbZUawWY=; b=LOMpotJbl1d527bM6PHVL6eMVDQfd/Nr4a278P0mzVOwMeKM9DyGoQ0Kbb+eFFlEM0 t054X1Z7cwYah794kSToG7M1MhhDIF5O+C/nump565nwVaU1u+J6PCAZO7aXY30UbGvJ CCRI275lsFJp3WuoInhGiBiKwnavIKSSmi9/nBif7SQV4zYKN/7Cw+jgvJdFbYui3Guf sJYcjWyyTSD+m4qc74gk5efQpMtMYlwyFHsyi+xli7MPBEa+uTHoP2dEIayFqhkVJB8Z w/UqCMlbt8QtuoGhk+JSORqdehIB2u1b/r9jtCIyO9GB1HRP3ldTfTriHlxNtTZhb9DQ EncA== MIME-Version: 1.0 Received: by 10.204.156.139 with SMTP id x11mr5480441bkw.128.1355742051567; Mon, 17 Dec 2012 03:00:51 -0800 (PST) Received: by 10.204.99.210 with HTTP; Mon, 17 Dec 2012 03:00:51 -0800 (PST) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> Date: Mon, 17 Dec 2012 12:00:51 +0100 Message-ID: From: Stefan Holmer To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=0015175dd71464094c04d10a4b2e X-Gm-Message-State: ALoCoQlTWuw7rr7kq53HLmWX3WYjB83RlhFxj6cROyeODxn9HPqmJRZT+ILqea5quGu1ZQBAw7L3SN7z1sWevUh1PePL0YPFhOLumhAclMEGljRPdVae4i1RbfYL0y1tDaj4g649xHtl5AeWy9ojdrcZXswpRf0mwKqt2SEQsZj5xkXy34zsYUm+6NxxNk+ZJZnZG8xTI+Ab Cc: rmcat WG Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:00:57 -0000 --0015175dd71464094c04d10a4b2e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'll try to clarify with an example: Let's say we have two clients (A and B) in a call. We want to estimate the bandwidth from A to B by looking at the variations in one-way delay, which we can measure by comparing deltas in RTP timestamp to deltas in receive-time. The problem with using RTP timestamps is that those represent capture time and not the send time of a frame, so we get a lot of noise related to variations in, e.g., video encoding time. To get around that we introduce RFC 5450 and now we can measure something much closer to actual network time. If we want to jointly process all RTP streams from A to B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report. Now let's add a server (let's call it S) in between client A and B. This server simply relays RTP packets (and might do some rewriting as well). Now we want to estimate the bandwidth between A and S, and between S and B. S will have to change the timestamp offset (RFC 5450) of the RTP packets to correspond to its send-time, but besides that all is fine. Now let's add a third client (C). S will relay packets from both A and C to B, so ideally we should jointly process all of those packets when estimating the bandwidth between S to B. However, packets sent from A will be based on the tuple (RTP timestamp A, NTP timestamp A) and packets sent from C will be based on (RTP timestamp C, NTP timestamp C), so we can't just convert to NTP at B and compare them. This can be solved in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relaying to B, which requires rewriting both RTP packets and RTCP packets. This is fine as long as you rewrite _all_ streams from the same sending client in the same way, otherwise you won't be able to synchronize them. Therefore all streams must go through the same server. I'm suggesting that we could introduce a new "send timestamp" which doesn't relate to the RTP timestamp (which is used for synchronized playback). Whenever a packet is sent (no matter if it's sent from A, C or S) it will be stamped with the send-time taken from the clock of that sender, for instance at 1 kHz or 90 kHz. Since it's not related to the RTP timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we don't even have to convert to NTP at the receiver since all send timestamps are taken directly from the same clock. Removing the relation to the RTP timestamp is what I mean with an "absolute" timestamp (i.e., not relative to RTP timestamp). /Stefan On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) wro= te: > Please clarify =93absolute=94. Do you mean another RTP timestamp using t= he > same units but a random offset from the main RTP timestamp, and no implie= d > sync across multiple RTP sessions? Or NTP timestamps with NTP units and > implied sync across all RTP sessions (within the same sync domain, > currently defined to be CNAME)?**** > > ** ** > > Please also clarify =93relay conference server=94, as there are many RTP > topologies for conferencing. I think you are probably referring to a sour= ce > projection mixer. Rewriting RTCP is standard practice for those, as well = as > most mixers. In fact, I can=92t envision when it would be possible to bli= ndly > relay RTCP in any mixer/topology. So I=92m not sure what complications yo= u > see arising from the use of RFC 5450.**** > > ** ** > > Mo**** > > ** ** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Stefan Holmer > *Sent:* Tuesday, December 04, 2012 4:23 AM > *To:* rmcat WG > *Subject:* [rmcat] Send timestamps**** > > ** ** > > Hi,**** > > ** ** > > In draft-alvestrand-rtcweb-congestion-01 we > proposed using a send timestamp RTP header extension for measuring the > packet inter-arrival time offset. In 02 this > was revised to instead reference RFC 5450, > which specifies a header extension for specifying the send timestamp as a= n > offset relative to the RTP timestamp.**** > > ** ** > > Thinking further about this, there seems to be a couple of benefits with > defining a new, absolute, send timestamp header extension. If a relay > approach to conference servers are used, the relaying server can simply > rewrite the send timestamp of a packet to correspond to the time it was > relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captured > and sent by different senders (with different clocks). **** > > ** ** > > With a send timestamp offset, accomplishing the same thing would require > rewriting both the timestamp offset and the NTP time in the corresponding > RTCP SR reports. And to keep video synchronized with audio the RTCP packe= t > for the audio streams must also be rewritten in a similar way. This may n= ot > even be possible if the audio stream is relayed through a different serve= r. > **** > > ** ** > > Do you see any problems with using an RTP header extension with absolute > send timestamps? Are there any benefits with the send timestamp offset > header extension I might be missing?**** > > ** ** > > /Stefan**** > --0015175dd71464094c04d10a4b2e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">I'll try to clarify with an example:

Let's say we have two clients (A and B) in a call. We want to estimate= the bandwidth from A to B by looking at the variations in one-way delay, w= hich we can measure by comparing deltas in RTP timestamp to deltas in recei= ve-time. The problem with using RTP timestamps is that those represent capt= ure time and not the send time of a frame, so we get a lot of noise related= to variations in, e.g., video encoding time. To get around that we introdu= ce=A0RFC 5450<= /a>=A0and now we can measure something much closer to actual network time. = If we want to jointly process all RTP streams from A to B (at the receiver,= B) we can convert the RTP timestamps of all streams to NTP using the (RTP = timestamp, NTP timestamp) tuple in the RTCP SR report.

Now let's add a server (let's call it S) in bet= ween client A and B. This server simply relays RTP packets (and might do so= me rewriting as well). Now we want to estimate the bandwidth between A and = S, and between S and B. S will have to change the timestamp offset (RFC 545= 0) of the RTP packets to correspond to its send-time, but besides that all = is fine.

Now let's add a third client (C). S will relay pack= ets from both A and C to B, so ideally we should jointly process all of tho= se packets when estimating the bandwidth between S to B. However, packets s= ent from A will be based on the tuple (RTP timestamp A, NTP timestamp A) an= d packets sent from C will be based on (RTP timestamp C, NTP timestamp C), = so we can't just convert to NTP at B and compare them. This can be solv= ed in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, N= TP timestamp S) before relaying to B, which requires rewriting both RTP pac= kets and RTCP packets. This is fine as long as you rewrite _all_ streams fr= om the same sending client in the same way, otherwise you won't be able= to synchronize them. Therefore all streams must go through the same server= .

I'm suggesting that we could introduce a new "= send timestamp" which doesn't relate to the RTP timestamp (which i= s used for synchronized playback). Whenever a packet is sent (no matter if = it's sent from A, C or S) it will be stamped with the send-time taken f= rom the clock of that sender, for instance at 1 kHz or 90 kHz. Since it'= ;s not related to the RTP timestamp we won't have to rewrite the (RTP, = NTP) tuple, and actually, we don't even have to convert to NTP at the r= eceiver since all send timestamps are taken directly from the same clock. R= emoving the relation to the RTP timestamp is what I mean with an "abso= lute" timestamp (i.e., not relative to RTP timestamp).

/Stefan


On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

Please clarify =93absolute=94. Do you mean another RTP timestamp using the= same units but a random offset from the main RTP timestamp, and no implied= sync across multiple RTP sessions? Or NTP timestamps with NTP units and implied sync across all RTP= sessions (within the same sync domain, currently defined to be CNAME)?<= /u>

=A0

Please also clarify =93relay conference server=94, as there are many RTP t= opologies for conferencing. I think you are probably referring to a source = projection mixer. Rewriting RTCP is standard practice for those, as well as most mixers. In fact, I ca= n=92t envision when it would be possible to blindly relay RTCP in any mixer= /topology. So I=92m not sure what complications you see arising from the us= e of RFC 5450.

=A0

Mo

=A0

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

=A0

H= i,

<= u>=A0

I= n draft-alvestrand-rtcweb-congestion-01<= /a>=A0we proposed using a send timestamp RTP header extension for measuring= the packet inter-arrival time offset. In 02=A0this was revised to instead r= eference RFC 5450, which specifies a header extension for specifying the = send timestamp as an offset relative to the RTP timestamp.

<= u>=A0

T= hinking further about this, there seems to be a couple of benefits with def= ining a new, absolute, send timestamp header extension. If a relay approach= to conference servers are used, the relaying server can simply rewrite the send timestamp of a p= acket to correspond to the time it was relayed. Doing so the receiver can j= ointly process all streams being received from the relay server, even thoug= h they were initially captured and sent by different senders (with different clocks).=A0=

<= u>=A0

W= ith a send timestamp offset, accomplishing the same thing would require rew= riting both the timestamp offset and the NTP time in the corresponding RTCP= SR reports. And to keep video synchronized with audio the RTCP packet for the audio streams must a= lso be rewritten in a similar way. This may not even be possible if the aud= io stream is relayed through a different server.

<= u>=A0

D= o you see any problems with using an RTP header extension with absolute sen= d timestamps? Are there any benefits with the send timestamp offset header = extension I might be missing?

<= u>=A0

/= Stefan


--0015175dd71464094c04d10a4b2e-- From harald@alvestrand.no Mon Dec 17 03:06:45 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A22421F8A9D for ; Mon, 17 Dec 2012 03:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy85mcP+0hKC for ; Mon, 17 Dec 2012 03:06:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA1521F8A69 for ; Mon, 17 Dec 2012 03:06:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B50B739E1C9 for ; Mon, 17 Dec 2012 12:06:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lp3zSU8gQvg for ; Mon, 17 Dec 2012 12:06:38 +0100 (CET) Received: from [172.28.90.88] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2A75939E04C for ; Mon, 17 Dec 2012 12:06:38 +0100 (CET) Message-ID: <50CEFCBD.9030104@alvestrand.no> Date: Mon, 17 Dec 2012 12:06:37 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040007070101080709080000" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:06:45 -0000 This is a multi-part message in MIME format. --------------040007070101080709080000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Separating the timestamp used as a congestion signal from timestamps that may be used for other purposes would seem to me to be an advantage in terms of architectural cleanliness. RTP timestamps need to reflect media time. In a situation with relay nodes and changing paths, this may have uncomfortable amounts of variation from the time the packets enter the last hop to the recipient. Given that we won't have all systems deploying the new extension from Day One, we need to be able to fall back to the RTP timestamp (it's better than nothing), but it seems we shouldn't marry it more than we have to. Harald On 12/17/2012 12:00 PM, Stefan Holmer wrote: > I'll try to clarify with an example: > > Let's say we have two clients (A and B) in a call. We want to estimate > the bandwidth from A to B by looking at the variations in one-way > delay, which we can measure by comparing deltas in RTP timestamp to > deltas in receive-time. The problem with using RTP timestamps is that > those represent capture time and not the send time of a frame, so we > get a lot of noise related to variations in, e.g., video encoding > time. To get around that we introduce RFC 5450 > and now we can measure something > much closer to actual network time. If we want to jointly process all > RTP streams from A to B (at the receiver, B) we can convert the RTP > timestamps of all streams to NTP using the (RTP timestamp, NTP > timestamp) tuple in the RTCP SR report. > > Now let's add a server (let's call it S) in between client A and B. > This server simply relays RTP packets (and might do some rewriting as > well). Now we want to estimate the bandwidth between A and S, and > between S and B. S will have to change the timestamp offset (RFC 5450) > of the RTP packets to correspond to its send-time, but besides that > all is fine. > > Now let's add a third client (C). S will relay packets from both A and > C to B, so ideally we should jointly process all of those packets when > estimating the bandwidth between S to B. However, packets sent from A > will be based on the tuple (RTP timestamp A, NTP timestamp A) and > packets sent from C will be based on (RTP timestamp C, NTP timestamp > C), so we can't just convert to NTP at B and compare them. This can be > solved in the server by rewriting RTP and NTP timestamps to (RTP > timestamp S, NTP timestamp S) before relaying to B, which requires > rewriting both RTP packets and RTCP packets. This is fine as long as > you rewrite _all_ streams from the same sending client in the same > way, otherwise you won't be able to synchronize them. Therefore all > streams must go through the same server. > > I'm suggesting that we could introduce a new "send timestamp" which > doesn't relate to the RTP timestamp (which is used for synchronized > playback). Whenever a packet is sent (no matter if it's sent from A, C > or S) it will be stamped with the send-time taken from the clock of > that sender, for instance at 1 kHz or 90 kHz. Since it's not related > to the RTP timestamp we won't have to rewrite the (RTP, NTP) tuple, > and actually, we don't even have to convert to NTP at the receiver > since all send timestamps are taken directly from the same clock. > Removing the relation to the RTP timestamp is what I mean with an > "absolute" timestamp (i.e., not relative to RTP timestamp). > > /Stefan > > > On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > > wrote: > > Please clarify “absolute”. Do you mean another RTP timestamp using > the same units but a random offset from the main RTP timestamp, > and no implied sync across multiple RTP sessions? Or NTP > timestamps with NTP units and implied sync across all RTP sessions > (within the same sync domain, currently defined to be CNAME)? > > Please also clarify “relay conference server”, as there are many > RTP topologies for conferencing. I think you are probably > referring to a source projection mixer. Rewriting RTCP is standard > practice for those, as well as most mixers. In fact, I can’t > envision when it would be possible to blindly relay RTCP in any > mixer/topology. So I’m not sure what complications you see arising > from the use of RFC 5450. > > Mo > > *From:*rmcat-bounces@ietf.org > [mailto:rmcat-bounces@ietf.org ] > *On Behalf Of *Stefan Holmer > *Sent:* Tuesday, December 04, 2012 4:23 AM > *To:* rmcat WG > *Subject:* [rmcat] Send timestamps > > Hi, > > In draft-alvestrand-rtcweb-congestion-01 > we > proposed using a send timestamp RTP header extension for measuring > the packet inter-arrival time offset. In 02 > this > was revised to instead reference RFC 5450 > , which specifies a header > extension for specifying the send timestamp as an offset relative > to the RTP timestamp. > > Thinking further about this, there seems to be a couple of > benefits with defining a new, absolute, send timestamp header > extension. If a relay approach to conference servers are used, the > relaying server can simply rewrite the send timestamp of a packet > to correspond to the time it was relayed. Doing so the receiver > can jointly process all streams being received from the relay > server, even though they were initially captured and sent by > different senders (with different clocks). > > With a send timestamp offset, accomplishing the same thing would > require rewriting both the timestamp offset and the NTP time in > the corresponding RTCP SR reports. And to keep video synchronized > with audio the RTCP packet for the audio streams must also be > rewritten in a similar way. This may not even be possible if the > audio stream is relayed through a different server. > > Do you see any problems with using an RTP header extension with > absolute send timestamps? Are there any benefits with the send > timestamp offset header extension I might be missing? > > /Stefan > > --------------040007070101080709080000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Separating the timestamp used as a congestion signal from timestamps that may be used for other purposes would seem to me to be an advantage in terms of architectural cleanliness.

RTP timestamps need to reflect media time. In a situation with relay nodes and changing paths, this may have uncomfortable amounts of variation from the time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from Day One, we need to be able to fall back to the RTP timestamp (it's better than nothing), but it seems we shouldn't marry it more than we have to.

              Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:
I'll try to clarify with an example:

Let's say we have two clients (A and B) in a call. We want to estimate the bandwidth from A to B by looking at the variations in one-way delay, which we can measure by comparing deltas in RTP timestamp to deltas in receive-time. The problem with using RTP timestamps is that those represent capture time and not the send time of a frame, so we get a lot of noise related to variations in, e.g., video encoding time. To get around that we introduce RFC 5450 and now we can measure something much closer to actual network time. If we want to jointly process all RTP streams from A to B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report.

Now let's add a server (let's call it S) in between client A and B. This server simply relays RTP packets (and might do some rewriting as well). Now we want to estimate the bandwidth between A and S, and between S and B. S will have to change the timestamp offset (RFC 5450) of the RTP packets to correspond to its send-time, but besides that all is fine.

Now let's add a third client (C). S will relay packets from both A and C to B, so ideally we should jointly process all of those packets when estimating the bandwidth between S to B. However, packets sent from A will be based on the tuple (RTP timestamp A, NTP timestamp A) and packets sent from C will be based on (RTP timestamp C, NTP timestamp C), so we can't just convert to NTP at B and compare them. This can be solved in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relaying to B, which requires rewriting both RTP packets and RTCP packets. This is fine as long as you rewrite _all_ streams from the same sending client in the same way, otherwise you won't be able to synchronize them. Therefore all streams must go through the same server.

I'm suggesting that we could introduce a new "send timestamp" which doesn't relate to the RTP timestamp (which is used for synchronized playback). Whenever a packet is sent (no matter if it's sent from A, C or S) it will be stamped with the send-time taken from the clock of that sender, for instance at 1 kHz or 90 kHz. Since it's not related to the RTP timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we don't even have to convert to NTP at the receiver since all send timestamps are taken directly from the same clock. Removing the relation to the RTP timestamp is what I mean with an "absolute" timestamp (i.e., not relative to RTP timestamp).

/Stefan


On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

Please clarify “absolute”. Do you mean another RTP timestamp using the same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or NTP timestamps with NTP units and implied sync across all RTP sessions (within the same sync domain, currently defined to be CNAME)?

 

Please also clarify “relay conference server”, as there are many RTP topologies for conferencing. I think you are probably referring to a source projection mixer. Rewriting RTCP is standard practice for those, as well as most mixers. In fact, I can’t envision when it would be possible to blindly relay RTCP in any mixer/topology. So I’m not sure what complications you see arising from the use of RFC 5450.

 

Mo

 

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

 

Hi,

 

In draft-alvestrand-rtcweb-congestion-01 we proposed using a send timestamp RTP header extension for measuring the packet inter-arrival time offset. In 02 this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send timestamp as an offset relative to the RTP timestamp.

 

Thinking further about this, there seems to be a couple of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the relaying server can simply rewrite the send timestamp of a packet to correspond to the time it was relayed. Doing so the receiver can jointly process all streams being received from the relay server, even though they were initially captured and sent by different senders (with different clocks). 

 

With a send timestamp offset, accomplishing the same thing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synchronized with audio the RTCP packet for the audio streams must also be rewritten in a similar way. This may not even be possible if the audio stream is relayed through a different server.

 

Do you see any problems with using an RTP header extension with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?

 

/Stefan



--------------040007070101080709080000-- From ingemar.s.johansson@ericsson.com Mon Dec 17 06:45:41 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047F721F848B for ; Mon, 17 Dec 2012 06:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFYtAeZ5orpO for ; Mon, 17 Dec 2012 06:45:36 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2D21F8895 for ; Mon, 17 Dec 2012 06:45:35 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-17-50cf300ef2dd Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 47.41.24873.E003FC05; Mon, 17 Dec 2012 15:45:34 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.209]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 15:45:33 +0100 From: Ingemar Johansson S To: Harald Alvestrand , "rmcat@ietf.org" Thread-Topic: [rmcat] Send timestamps Thread-Index: AQHN3EaefRIKucEfr0icBTzuckgkWJgdDOGA Date: Mon, 17 Dec 2012 14:45:32 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> In-Reply-To: <50CEFCBD.9030104@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9ESESSMB205ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvjS6fwfkAg4MnNS2O9XWxWay++YHN gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4teIva8GT64wV6+dvZW5gnL+bsYuRk0NC wERidc9LZghbTOLCvfVsXYxcHEIChxglulpWsEM4Sxglntz7yQJSxSZgI7Hy0HewbhGBQIlD 3cvAbGEBFYkDs+8xQcRVJTp3HICyjSS2rW5iB7FZgOLn388G28Yr4C3x+NV8VhBbSOAvo8Tx iZIgNqeArsTSmwvBZjIKyErc/34PbC+zgLjErSfzmSAuFZBYsuc81NWiEi8f/2OFsBUlPr7a xwhRny/R8PQiE8QuQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DET svgCRvZVjOy5iZk56eVGmxiBEXRwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA6PlnlmX/t2uzXpoPif2An/uh0vdx2MsXvredtl4xfWqyRTxP5qyyzLW qXxcFr110rmbvhJHvfpSPpuXiawQX3PzbtnNdoP3kreONx3YNqfYr/jipQ0zV/6wYJm22HXi zvoZjLyMzgZKC5hzD8X+su0Nv/L/9b1bLYJJ8qkG+gEuMYkRtVtjNFSUWIozEg21mIuKEwGU aYjgbgIAAA== Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:45:41 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9ESESSMB205ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I believe that it can make sense to use a separate timestamp for congestion= control but I may need to read and understand some more. A few reflections= though. Unless I miss something, this is quite close to the TCP timestamps which ar= e used for congestion avoidance in TCP Vegas and LEDBAT. The problem in Vegas is that it is sensitive to congestion in the feedback = path, not shure though how much concern that should be. LEDBAT modifies this and implement the concept of base delay, but suffers f= rom late comers advantage. Both the above assume that one ACKs are returned to the sender almost immed= iately (delay ACK adds some uncertanity here) also one don't need to synchr= onize clocks. Here I get unsure about what to do with the received timestamps, I guess yo= u can compute a delta between sent and received timestamp but unless you ha= ve exactly synchronized clocks in sender(s) and receiver(s), you will have = an unknown offset that can possibly also drift due to clock skew. /Ingemar From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 17 december 2012 12:07 To: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps Separating the timestamp used as a congestion signal from timestamps that m= ay be used for other purposes would seem to me to be an advantage in terms = of architectural cleanliness. RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient. Given that we won't have all systems deploying the new extension from Day O= ne, we need to be able to fall back to the RTP timestamp (it's better than = nothing), but it seems we shouldn't marry it more than we have to. Harald On 12/17/2012 12:00 PM, Stefan Holmer wrote: I'll try to clarify with an example: Let's say we have two clients (A and B) in a call. We want to estimate the = bandwidth from A to B by looking at the variations in one-way delay, which = we can measure by comparing deltas in RTP timestamp to deltas in receive-ti= me. The problem with using RTP timestamps is that those represent capture t= ime and not the send time of a frame, so we get a lot of noise related to v= ariations in, e.g., video encoding time. To get around that we introduce RF= C 5450 and now we can measure something= much closer to actual network time. If we want to jointly process all RTP = streams from A to B (at the receiver, B) we can convert the RTP timestamps = of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the= RTCP SR report. Now let's add a server (let's call it S) in between client A and B. This se= rver simply relays RTP packets (and might do some rewriting as well). Now w= e want to estimate the bandwidth between A and S, and between S and B. S wi= ll have to change the timestamp offset (RFC 5450) of the RTP packets to cor= respond to its send-time, but besides that all is fine. Now let's add a third client (C). S will relay packets from both A and C to= B, so ideally we should jointly process all of those packets when estimati= ng the bandwidth between S to B. However, packets sent from A will be based= on the tuple (RTP timestamp A, NTP timestamp A) and packets sent from C wi= ll be based on (RTP timestamp C, NTP timestamp C), so we can't just convert= to NTP at B and compare them. This can be solved in the server by rewritin= g RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relay= ing to B, which requires rewriting both RTP packets and RTCP packets. This = is fine as long as you rewrite _all_ streams from the same sending client i= n the same way, otherwise you won't be able to synchronize them. Therefore = all streams must go through the same server. I'm suggesting that we could introduce a new "send timestamp" which doesn't= relate to the RTP timestamp (which is used for synchronized playback). Whe= never a packet is sent (no matter if it's sent from A, C or S) it will be s= tamped with the send-time taken from the clock of that sender, for instance= at 1 kHz or 90 kHz. Since it's not related to the RTP timestamp we won't h= ave to rewrite the (RTP, NTP) tuple, and actually, we don't even have to co= nvert to NTP at the receiver since all send timestamps are taken directly f= rom the same clock. Removing the relation to the RTP timestamp is what I me= an with an "absolute" timestamp (i.e., not relative to RTP timestamp). /Stefan On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > wrote: Please clarify "absolute". Do you mean another RTP timestamp using the same= units but a random offset from the main RTP timestamp, and no implied sync= across multiple RTP sessions? Or NTP timestamps with NTP units and implied= sync across all RTP sessions (within the same sync domain, currently defin= ed to be CNAME)? Please also clarify "relay conference server", as there are many RTP topolo= gies for conferencing. I think you are probably referring to a source proje= ction mixer. Rewriting RTCP is standard practice for those, as well as most= mixers. In fact, I can't envision when it would be possible to blindly rel= ay RTCP in any mixer/topology. So I'm not sure what complications you see a= rising from the use of RFC 5450. Mo From: rmcat-bounces@ietf.org [mailto:rmcat-b= ounces@ietf.org] On Behalf Of Stefan Holmer Sent: Tuesday, December 04, 2012 4:23 AM To: rmcat WG Subject: [rmcat] Send timestamps Hi, In draft-alvestrand-rtcweb-congestion-01 we proposed using a send timestamp RTP head= er extension for measuring the packet inter-arrival time offset. In 02 this was revi= sed to instead reference RFC 5450, whic= h specifies a header extension for specifying the send timestamp as an offs= et relative to the RTP timestamp. Thinking further about this, there seems to be a couple of benefits with de= fining a new, absolute, send timestamp header extension. If a relay approac= h to conference servers are used, the relaying server can simply rewrite th= e send timestamp of a packet to correspond to the time it was relayed. Doin= g so the receiver can jointly process all streams being received from the r= elay server, even though they were initially captured and sent by different= senders (with different clocks). With a send timestamp offset, accomplishing the same thing would require re= writing both the timestamp offset and the NTP time in the corresponding RTC= P SR reports. And to keep video synchronized with audio the RTCP packet for= the audio streams must also be rewritten in a similar way. This may not ev= en be possible if the audio stream is relayed through a different server. Do you see any problems with using an RTP header extension with absolute se= nd timestamps? Are there any benefits with the send timestamp offset header= extension I might be missing? /Stefan --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9ESESSMB205ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

I believe that it can mak= e sense to use a separate timestamp for congestion control but I may need t= o read and understand some more. A few reflections though.

 <= /p>

Unless I miss something, = this is quite close to the TCP timestamps which are used for congestion avo= idance in TCP Vegas and LEDBAT.

The problem in Vegas is t= hat it is sensitive to congestion in the feedback path, not shure though ho= w much concern that should be.

LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers advantage= .

Both the above assume tha= t one ACKs are returned to the sender almost immediately (delay ACK adds so= me uncertanity here) also one don’t need to synchronize clocks.

Here I get unsure about w= hat to do with the received timestamps, I guess you can compute a delta bet= ween sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.

 <= /p>

/Ingemar

 <= /p>

 <= /p>

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: den 17 december 2012 12:07
To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

Separating the timestamp used as a congestion signal= from timestamps that may be used for other purposes would seem to me to be= an advantage in terms of architectural cleanliness.

RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from Day O= ne, we need to be able to fall back to the RTP timestamp (it's better than = nothing), but it seems we shouldn't marry it more than we have to.

            &nb= sp; Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:

I'll try to clarify with an example:

 

Let's say we have two clients (A and B) i= n a call. We want to estimate the bandwidth from A to B by looking at the v= ariations in one-way delay, which we can measure by comparing deltas in RTP timestamp to deltas in receive-time. The problem with using = RTP timestamps is that those represent capture time and not the send time o= f a frame, so we get a lot of noise related to variations in, e.g., video e= ncoding time. To get around that we introduce RFC 5450 and now we can measure something much closer to = actual network time. If we want to jointly process all RTP streams from A t= o B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) = tuple in the RTCP SR report.

 

Now let's add a server (let's call it S) = in between client A and B. This server simply relays RTP packets (and might= do some rewriting as well). Now we want to estimate the bandwidth between A and S, and between S and B. S will have to change the = timestamp offset (RFC 5450) of the RTP packets to correspond to its send-ti= me, but besides that all is fine.

 

Now let's add a third client (C). S will = relay packets from both A and C to B, so ideally we should jointly process = all of those packets when estimating the bandwidth between S to B. However, packets sent from A will be based on the tuple (RTP times= tamp A, NTP timestamp A) and packets sent from C will be based on (RTP time= stamp C, NTP timestamp C), so we can't just convert to NTP at B and compare= them. This can be solved in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timest= amp S) before relaying to B, which requires rewriting both RTP packets and = RTCP packets. This is fine as long as you rewrite _all_ streams from the sa= me sending client in the same way, otherwise you won't be able to synchronize them. Therefore all streams mus= t go through the same server.

 

I'm suggesting that we could introduce a = new "send timestamp" which doesn't relate to the RTP timestamp (w= hich is used for synchronized playback). Whenever a packet is sent (no matter if it's sent from A, C or S) it will be stamped with the send-t= ime taken from the clock of that sender, for instance at 1 kHz or 90 kHz. S= ince it's not related to the RTP timestamp we won't have to rewrite the (RT= P, NTP) tuple, and actually, we don't even have to convert to NTP at the receiver since all send timestamp= s are taken directly from the same clock. Removing the relation to the RTP = timestamp is what I mean with an "absolute" timestamp (i.e., not = relative to RTP timestamp).

 

/Stefan

 = ;

On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanat= y (mzanaty) <mzan= aty@cisco.com> wrote:

Please clarify “absolute”. Do you mean an= other RTP timestamp using the same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or N= TP timestamps with NTP units and implied sync across all RTP sessions (with= in the same sync domain, currently defined to be CNAME)?=

 

Please also clarify “relay conference server= 221;, as there are many RTP topologies for conferencing. I think you are probably referring to a source projection mixer. Rewriting RTCP is standar= d practice for those, as well as most mixers. In fact, I can’t envisi= on when it would be possible to blindly relay RTCP in any mixer/topology. S= o I’m not sure what complications you see arising from the use of RFC 5450.<= /p>

 

Mo

 

From: rmcat-bounces@i= etf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps=

 

Hi,

 

In draft-alvestrand-rtcweb-congestion-01 we proposed using a send tim= estamp RTP header extension for measuring the packet inter-arrival time off= set. In 02 this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send ti= mestamp as an offset relative to the RTP timestamp.

 

Thinking further about this, there seems to be a couple= of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the = relaying server can simply rewrite the send timestamp of a packet to corres= pond to the time it was relayed. Doing so the receiver can jointly process = all streams being received from the relay server, even though they were initially captured and sent by dif= ferent senders (with different clocks). 

 

With a send timestamp offset, accomplishing the same th= ing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synch= ronized with audio the RTCP packet for the audio streams must also be rewri= tten in a similar way. This may not even be possible if the audio stream is= relayed through a different server.

 

Do you see any problems with using an RTP header extens= ion with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?

 

/Stefan

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9ESESSMB205ericsso_-- From holmer@google.com Mon Dec 17 08:15:34 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A511321F8B34 for ; Mon, 17 Dec 2012 08:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqy42CKvT7oe for ; Mon, 17 Dec 2012 08:15:33 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3F021F8B33 for ; Mon, 17 Dec 2012 08:15:32 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so2867844bku.31 for ; Mon, 17 Dec 2012 08:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ymc/cfT+P5+m0vSaGOtDvRV9AEZ3Wiz0EbftZaoTE4I=; b=MvGlyvXL8Oada2fz6Vb1IFcs4QmB+LSvsU1tV8v6JEPjdhikEGBtiz8b25X9F68BYj 1JGv0mSnWum42Gvy8kIlQuc5hqXxYlbloWOKA+LPwkm9S/plRi3HW5QnhFSNld1a2/P0 b01YB3OXdFBovEWBAlfLMLt72qt01Y2osKUawcELR2fsz9k1fcVsLb3NV01/mA81Et/Q nILfVHjc999rXf2jPMMLJIfFxn64M3FXB/hHoeeFgiWGl1EzZfAbQL/G/yQksVbJA69/ HTHXuo8YXfgFwSq/XPyZEYatT6Oz6RJl5cfry5pbkzSTjfrwZJGLHT+V0y6A4q/YlVh3 1PoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Ymc/cfT+P5+m0vSaGOtDvRV9AEZ3Wiz0EbftZaoTE4I=; b=SVxU+YvnLv6kqwydDd4o2Ygb4XPX5mQIsb6Omn0NekeP3WSCJzuqsm0s3sjAypgZUv yNIqZWTtTO2ZjYrx75cMEJnwjfwYxNlgq37zKcAHZdnP6bdnPN6wVlD0TIbzmRO3w9YF wIQIo+E1Sqsed2nlqUhjq/NNlUd8e1dX3oUyQeSoZubdvKcuZqHYdoAZsTb0AFZiPugz TN6STMQuRt9wyGM7jsvMgPY1VqrZQiy5k3DSkKKykLa/+wNZ4F9CEC40D5eeLRO1Cb2q DZ5PxhOgSWsOIW6sy1vkrVMFvpxjNphHLj/DImVcH2okB0kwhvK3dkZ8KsCcIY2sy98k 9X0Q== MIME-Version: 1.0 Received: by 10.204.153.27 with SMTP id i27mr5967309bkw.116.1355760931431; Mon, 17 Dec 2012 08:15:31 -0800 (PST) Sender: holmer@google.com Received: by 10.204.99.210 with HTTP; Mon, 17 Dec 2012 08:15:31 -0800 (PST) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> Date: Mon, 17 Dec 2012 17:15:31 +0100 X-Google-Sender-Auth: MdGa8mznRAzNnvMQsRoXeCal8nM Message-ID: From: Stefan Holmer To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=00151761ca58b7e4db04d10eb0ca X-Gm-Message-State: ALoCoQm76qRCFKim5pqTWb1mvVspf4wFWrcxbzQXdVv1maBBOgeniDhz2w0B9Wn0D/w97uzb/2O7IohzKtVLtGw3xjrchKeAeKHsiCQ6kPjH2KbRJQ3wRiXgj4f/L8XFXG/Yc9B8BSUQplN5wg9VCHk4jiHd0KZcBOGvdmU6JbsRAmD2efntLfRDjIKYjbigwBa5zCkM2+Na Cc: Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:15:34 -0000 --00151761ca58b7e4db04d10eb0ca Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Dec 17, 2012 at 3:45 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi**** > > ** ** > > I believe that it can make sense to use a separate timestamp for > congestion control but I may need to read and understand some more. A few > reflections though.**** > > ** ** > > Unless I miss something, this is quite close to the TCP timestamps which > are used for congestion avoidance in TCP Vegas and LEDBAT. **** > > The problem in Vegas is that it is sensitive to congestion in the feedbac= k > path, not shure though how much concern that should be. **** > > LEDBAT modifies this and implement the concept of base delay, but suffers > from late comers advantage.**** > > Both the above assume that one ACKs are returned to the sender almost > immediately (delay ACK adds some uncertanity here) also one don=92t need = to > synchronize clocks.**** > > Here I get unsure about what to do with the received timestamps, I guess > you can compute a delta between sent and received timestamp but unless yo= u > have exactly synchronized clocks in sender(s) and receiver(s), you will > have an unknown offset that can possibly also drift due to clock skew. > In draft-alvestrand-rtcweb-congestion we are tracking the trend of that delta. If the receive-deltas are increasing compared to send-deltas we assume it's because of congestion. Doing so we don't have to deal with the unknown offset. > **** > > ** ** > > /Ingemar**** > > ** ** > > ** ** > > ** ** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* den 17 december 2012 12:07 > > *To:* rmcat@ietf.org > *Subject:* Re: [rmcat] Send timestamps**** > > ** ** > > Separating the timestamp used as a congestion signal from timestamps that > may be used for other purposes would seem to me to be an advantage in ter= ms > of architectural cleanliness. > > > RTP timestamps need to reflect media time. In a situation with relay node= s > and changing paths, this may have uncomfortable amounts of variation from > the time the packets enter the last hop to the recipient. > > Given that we won't have all systems deploying the new extension from Day > One, we need to be able to fall back to the RTP timestamp (it's better th= an > nothing), but it seems we shouldn't marry it more than we have to. > > Harald > > On 12/17/2012 12:00 PM, Stefan Holmer wrote:**** > > I'll try to clarify with an example: **** > > ** ** > > Let's say we have two clients (A and B) in a call. We want to estimate th= e > bandwidth from A to B by looking at the variations in one-way delay, whic= h > we can measure by comparing deltas in RTP timestamp to deltas in > receive-time. The problem with using RTP timestamps is that those represe= nt > capture time and not the send time of a frame, so we get a lot of noise > related to variations in, e.g., video encoding time. To get around that w= e > introduce RFC 5450 and now we can > measure something much closer to actual network time. If we want to joint= ly > process all RTP streams from A to B (at the receiver, B) we can convert t= he > RTP timestamps of all streams to NTP using the (RTP timestamp, NTP > timestamp) tuple in the RTCP SR report.**** > > ** ** > > Now let's add a server (let's call it S) in between client A and B. This > server simply relays RTP packets (and might do some rewriting as well). N= ow > we want to estimate the bandwidth between A and S, and between S and B. S > will have to change the timestamp offset (RFC 5450) of the RTP packets to > correspond to its send-time, but besides that all is fine.**** > > ** ** > > Now let's add a third client (C). S will relay packets from both A and C > to B, so ideally we should jointly process all of those packets when > estimating the bandwidth between S to B. However, packets sent from A wil= l > be based on the tuple (RTP timestamp A, NTP timestamp A) and packets sent > from C will be based on (RTP timestamp C, NTP timestamp C), so we can't > just convert to NTP at B and compare them. This can be solved in the serv= er > by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) > before relaying to B, which requires rewriting both RTP packets and RTCP > packets. This is fine as long as you rewrite _all_ streams from the same > sending client in the same way, otherwise you won't be able to synchroniz= e > them. Therefore all streams must go through the same server.**** > > ** ** > > I'm suggesting that we could introduce a new "send timestamp" which > doesn't relate to the RTP timestamp (which is used for synchronized > playback). Whenever a packet is sent (no matter if it's sent from A, C or > S) it will be stamped with the send-time taken from the clock of that > sender, for instance at 1 kHz or 90 kHz. Since it's not related to the RT= P > timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we > don't even have to convert to NTP at the receiver since all send timestam= ps > are taken directly from the same clock. Removing the relation to the RTP > timestamp is what I mean with an "absolute" timestamp (i.e., not relative > to RTP timestamp).**** > > ** ** > > /Stefan**** > > ** ** > > On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > wrote:**** > > Please clarify =93absolute=94. Do you mean another RTP timestamp using th= e > same units but a random offset from the main RTP timestamp, and no implie= d > sync across multiple RTP sessions? Or NTP timestamps with NTP units and > implied sync across all RTP sessions (within the same sync domain, > currently defined to be CNAME)?**** > > **** > > Please also clarify =93relay conference server=94, as there are many RTP > topologies for conferencing. I think you are probably referring to a sour= ce > projection mixer. Rewriting RTCP is standard practice for those, as well = as > most mixers. In fact, I can=92t envision when it would be possible to bli= ndly > relay RTCP in any mixer/topology. So I=92m not sure what complications yo= u > see arising from the use of RFC 5450.**** > > **** > > Mo**** > > **** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Stefan Holmer > *Sent:* Tuesday, December 04, 2012 4:23 AM > *To:* rmcat WG > *Subject:* [rmcat] Send timestamps**** > > **** > > Hi,**** > > **** > > In draft-alvestrand-rtcweb-congestion-01 we > proposed using a send timestamp RTP header extension for measuring the > packet inter-arrival time offset. In 02 this > was revised to instead reference RFC 5450, > which specifies a header extension for specifying the send timestamp as a= n > offset relative to the RTP timestamp.**** > > **** > > Thinking further about this, there seems to be a couple of benefits with > defining a new, absolute, send timestamp header extension. If a relay > approach to conference servers are used, the relaying server can simply > rewrite the send timestamp of a packet to correspond to the time it was > relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captured > and sent by different senders (with different clocks). **** > > **** > > With a send timestamp offset, accomplishing the same thing would require > rewriting both the timestamp offset and the NTP time in the corresponding > RTCP SR reports. And to keep video synchronized with audio the RTCP packe= t > for the audio streams must also be rewritten in a similar way. This may n= ot > even be possible if the audio stream is relayed through a different serve= r. > **** > > **** > > Do you see any problems with using an RTP header extension with absolute > send timestamps? Are there any benefits with the send timestamp offset > header extension I might be missing?**** > > **** > > /Stefan**** > > ** ** > > ** ** > --00151761ca58b7e4db04d10eb0ca Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">


On Mon, Dec 17, 2012 at 3:45 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

=A0

I believe that it can make sense to use a separate ti= mestamp for congestion control but I may need to read and understand some m= ore. A few reflections though.

=A0

Unless I miss something, this is quite close to the T= CP timestamps which are used for congestion avoidance in TCP Vegas and LEDB= AT.

The problem in Vegas is that it is sensitive to conge= stion in the feedback path, not shure though how much concern that should b= e.

LEDBAT modifies this and implement the concept of bas= e delay, but suffers from late comers advantage.

Both the above assume that one ACKs are returned to t= he sender almost immediately (delay ACK adds some uncertanity here) also on= e don=92t need to synchronize clocks.

Here I get unsure about what to do with the received = timestamps, I guess you can compute a delta between sent and received times= tamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.


In=A0draft-alv= estrand-rtcweb-congestion=A0we are tracking the trend of that delta. If= the receive-deltas are increasing compared to send-deltas we assume it'= ;s because of congestion. Doing so we don't have to deal with the unkno= wn offset.
=A0

=A0

/Ingemar

=A0

=A0

=A0

From: Harald Alvestrand [mailto:harald@= alvestrand.no]
Sent: den 17 december 2012 12:07


To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

=A0

Separating the timestamp used as a congestion signal from tim= estamps that may be used for other purposes would seem to me to be an advan= tage in terms of architectural cleanliness.



RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from D= ay One, we need to be able to fall back to the RTP timestamp (it's bett= er than nothing), but it seems we shouldn't marry it more than we have = to.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:

I= 'll try to clarify with an example:

<= u>=A0

L= et's say we have two clients (A and B) in a call. We want to estimate t= he bandwidth from A to B by looking at the variations in one-way delay, whi= ch we can measure by comparing deltas in RTP timestamp to deltas in receive-time. The problem with using = RTP timestamps is that those represent capture time and not the send time o= f a frame, so we get a lot of noise related to variations in, e.g., video e= ncoding time. To get around that we introduce=A0RFC 5450=A0and now we can measure something much= closer to actual network time. If we want to jointly process all RTP strea= ms from A to B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) = tuple in the RTCP SR report.

<= u>=A0

N= ow let's add a server (let's call it S) in between client A and B. = This server simply relays RTP packets (and might do some rewriting as well)= . Now we want to estimate the bandwidth between A and S, and between S and B. S will have to change the = timestamp offset (RFC 5450) of the RTP packets to correspond to its send-ti= me, but besides that all is fine.

<= u>=A0

N= ow let's add a third client (C). S will relay packets from both A and C= to B, so ideally we should jointly process all of those packets when estim= ating the bandwidth between S to B. However, packets sent from A will be based on the tuple (RTP times= tamp A, NTP timestamp A) and packets sent from C will be based on (RTP time= stamp C, NTP timestamp C), so we can't just convert to NTP at B and com= pare them. This can be solved in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timest= amp S) before relaying to B, which requires rewriting both RTP packets and = RTCP packets. This is fine as long as you rewrite _all_ streams from the sa= me sending client in the same way, otherwise you won't be able to synchronize them. Therefore all streams= must go through the same server.

<= u>=A0

I= 'm suggesting that we could introduce a new "send timestamp" = which doesn't relate to the RTP timestamp (which is used for synchroniz= ed playback). Whenever a packet is sent (no matter if it's sent from A, C or S) it will be stamped with the se= nd-time taken from the clock of that sender, for instance at 1 kHz or 90 kH= z. Since it's not related to the RTP timestamp we won't have to rew= rite the (RTP, NTP) tuple, and actually, we don't even have to convert to NTP at the receiver since all send times= tamps are taken directly from the same clock. Removing the relation to the = RTP timestamp is what I mean with an "absolute" timestamp (i.e., = not relative to RTP timestamp).

<= u>=A0

/= Stefan

=A0

O= n Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com&= gt; wrote:

Please clarify =93absolute=94. Do you mean another RTP timestamp using the= same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or N= TP timestamps with NTP units and implied sync across all RTP sessions (with= in the same sync domain, currently defined to be CNAME)?

=A0<= /u>

Please also clarify =93relay conference server=94, as there are many RTP t= opologies for conferencing. I think you are probably referring to a source projection mixer. Rewriting RTCP is standar= d practice for those, as well as most mixers. In fact, I can=92t envision w= hen it would be possible to blindly relay RTCP in any mixer/topology. So I= =92m not sure what complications you see arising from the use of RFC 5450.

=A0<= /u>

Mo

=A0<= /u>

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

= =A0

H= i,

= =A0

I= n draft-alvestrand-rtcweb-congestion-01=A0we proposed using a send timest= amp RTP header extension for measuring the packet inter-arrival time offset= . In 02=A0this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send ti= mestamp as an offset relative to the RTP timestamp.

= =A0

T= hinking further about this, there seems to be a couple of benefits with def= ining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the = relaying server can simply rewrite the send timestamp of a packet to corres= pond to the time it was relayed. Doing so the receiver can jointly process = all streams being received from the relay server, even though they were initially captured and sent by dif= ferent senders (with different clocks).=A0

= =A0

W= ith a send timestamp offset, accomplishing the same thing would require rew= riting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synch= ronized with audio the RTCP packet for the audio streams must also be rewri= tten in a similar way. This may not even be possible if the audio stream is= relayed through a different server.

= =A0

D= o you see any problems with using an RTP header extension with absolute sen= d timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?=

= =A0

/= Stefan

<= u>=A0

=A0


--00151761ca58b7e4db04d10eb0ca-- From harald@alvestrand.no Mon Dec 17 11:36:45 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9F621F8891 for ; Mon, 17 Dec 2012 11:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fyYO-Zd6FDA for ; Mon, 17 Dec 2012 11:36:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2F21F887B for ; Mon, 17 Dec 2012 11:36:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D6D439E1C9; Mon, 17 Dec 2012 20:36:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RthbWeUWz4Ev; Mon, 17 Dec 2012 20:36:41 +0100 (CET) Received: from [172.28.90.88] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 034BF39E020; Mon, 17 Dec 2012 20:36:38 +0100 (CET) Message-ID: <50CF7445.60907@alvestrand.no> Date: Mon, 17 Dec 2012 20:36:37 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ingemar Johansson S References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> Content-Type: multipart/alternative; boundary="------------090400060101070609070304" Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:36:45 -0000 This is a multi-part message in MIME format. --------------090400060101070609070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: > > Hi > > I believe that it can make sense to use a separate timestamp for > congestion control but I may need to read and understand some more. A > few reflections though. > > Unless I miss something, this is quite close to the TCP timestamps > which are used for congestion avoidance in TCP Vegas and LEDBAT. > > The problem in Vegas is that it is sensitive to congestion in the > feedback path, not shure though how much concern that should be. > If we keep a model of computation-at-receiver, it's not a problem at all. > > LEDBAT modifies this and implement the concept of base delay, but > suffers from late comers advantage. > > Both the above assume that one ACKs are returned to the sender almost > immediately (delay ACK adds some uncertanity here) also one don't need > to synchronize clocks. > > Here I get unsure about what to do with the received timestamps, I > guess you can compute a delta between sent and received timestamp but > unless you have exactly synchronized clocks in sender(s) and > receiver(s), you will have an unknown offset that can possibly also > drift due to clock skew. > As Stefan says - since we measure ~a moving average of difference between the (receive timestamp - send timestamp) of successive packets, not an absolute transit time, value, this is not likely to be an issue. I have a hard time imagining clock drift so severe that it will significantly influence the deltas of packets that are sent less than a second apart. Clock jumps (like leap seconds) may be a measurable, but extremely transient, influence. --------------090400060101070609070304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:

Hi

 

I believe that it can make sense to use a separate timestamp for congestion control but I may need to read and understand some more. A few reflections though.

 

Unless I miss something, this is quite close to the TCP timestamps which are used for congestion avoidance in TCP Vegas and LEDBAT.

The problem in Vegas is that it is sensitive to congestion in the feedback path, not shure though how much concern that should be.

If we keep a model of computation-at-receiver, it's not a problem at all.

LEDBAT modifies this and implement the concept of base delay, but suffers from late comers advantage.

Both the above assume that one ACKs are returned to the sender almost immediately (delay ACK adds some uncertanity here) also one don’t need to synchronize clocks.

Here I get unsure about what to do with the received timestamps, I guess you can compute a delta between sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown offset that can possibly also drift due to clock skew.


As Stefan says - since we measure ~a moving average of difference between the (receive timestamp - send timestamp) of successive packets, not an absolute transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will significantly influence the deltas of packets that are sent less than a second apart. Clock jumps (like leap seconds) may be a measurable, but extremely transient, influence.

--------------090400060101070609070304-- From mzanaty@cisco.com Mon Dec 17 12:15:42 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A821F8971 for ; Mon, 17 Dec 2012 12:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDy9e0NtT5SU for ; Mon, 17 Dec 2012 12:15:37 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C771821F8946 for ; Mon, 17 Dec 2012 12:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31511; q=dns/txt; s=iport; t=1355775337; x=1356984937; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lKILqK8cAKYls/SRTndm6ZWvgkaJFtKQmAem6V0oH9A=; b=kEryNGAv74sxxT2SlN4Ss3Yuep5Qulma27itWYKTPkYswF1qj7flWYAA S9tEYgyGR1aFioKTiykndOIfNBQd2HnABiJYvsSlXvpUS4ZRDefpaNzc6 Kl3OuCb6NI9fo1yct/lvooorLqHlxBF1RUkBv6b7oMIRIevRNAlUTQtCf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAER8z1CtJV2b/2dsb2JhbABFgkmySAGJFRZzgh4BAQEDAS07CgcFCwIBCBEEAQELFgEGBzIUCQgCBAENBQiIBQYMuhCMXYNiYQOSV4RPjyyCc4FkBzc X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208,217";a="153940601" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Dec 2012 20:15:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBHKFP0h011684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 20:15:25 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 14:15:24 -0600 From: "Mo Zanaty (mzanaty)" To: Harald Alvestrand , "Stefan Holmer (holmer@google.com)" Thread-Topic: [rmcat] Send timestamps Thread-Index: AQHN0gHghOHemZI0p0CqIdxtCIphjpgbkKuAgAG7dICAAAGcgP//4IVA Date: Mon, 17 Dec 2012 20:15:24 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> In-Reply-To: <50CEFCBD.9030104@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.231] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F647D5Bxmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:15:43 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F647D5Bxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So we're back to two pendulums two months after deciding multi-hop is initi= ally out of scope. I'm glad, because it will likely be a major (or perhaps = even dominant) deployment scenario, which we should not defer based on comp= lexity alone. If we introduce a new send timestamp extension (which I'm unsure of the ben= efits over RFC 5450), I think it should be in NTP units not RTP media clock= units. There is a precedent (in RTCP) for NTP timestamps that are synced a= cross multiple RTP sessions, but there is no such precedent for synced RTP = timestamps. Different media types with different media clocks would also pr= esent problems for synced RTP timestamps. But even with this new send timestamp extension (using absolute synced NTP = timestamps), I don't think it avoids Stefan's problem of rewriting every RT= P and RTCP packet at the server. Every RTP packet must still be rewritten w= ith the new extension using the server's NTP time, and every RTCP SR packet= must still be rewritten for several reasons beyond congestion control. So I really don't see any benefit that a new extension would provide beyond= RFC 5450. Perhaps I'm missing it. I'm also missing why you need to convert to NTP time in order to "jointly p= rocess all RTP streams", because only the deltas really matter not the actu= al NTP time, and RFC 5450 gives you all you need for deltas. > If we want to jointly process all RTP streams from A to B (at the receive= r, B) we can convert the RTP timestamps of all streams to NTP using the (RT= P timestamp, NTP timestamp) tuple in the RTCP SR report. Mo From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of H= arald Alvestrand Sent: Monday, December 17, 2012 6:07 AM To: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps Separating the timestamp used as a congestion signal from timestamps that m= ay be used for other purposes would seem to me to be an advantage in terms = of architectural cleanliness. RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient. Given that we won't have all systems deploying the new extension from Day O= ne, we need to be able to fall back to the RTP timestamp (it's better than = nothing), but it seems we shouldn't marry it more than we have to. Harald On 12/17/2012 12:00 PM, Stefan Holmer wrote: I'll try to clarify with an example: Let's say we have two clients (A and B) in a call. We want to estimate the = bandwidth from A to B by looking at the variations in one-way delay, which = we can measure by comparing deltas in RTP timestamp to deltas in receive-ti= me. The problem with using RTP timestamps is that those represent capture t= ime and not the send time of a frame, so we get a lot of noise related to v= ariations in, e.g., video encoding time. To get around that we introduce RF= C 5450 and now we can measure something= much closer to actual network time. If we want to jointly process all RTP = streams from A to B (at the receiver, B) we can convert the RTP timestamps = of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the= RTCP SR report. Now let's add a server (let's call it S) in between client A and B. This se= rver simply relays RTP packets (and might do some rewriting as well). Now w= e want to estimate the bandwidth between A and S, and between S and B. S wi= ll have to change the timestamp offset (RFC 5450) of the RTP packets to cor= respond to its send-time, but besides that all is fine. Now let's add a third client (C). S will relay packets from both A and C to= B, so ideally we should jointly process all of those packets when estimati= ng the bandwidth between S to B. However, packets sent from A will be based= on the tuple (RTP timestamp A, NTP timestamp A) and packets sent from C wi= ll be based on (RTP timestamp C, NTP timestamp C), so we can't just convert= to NTP at B and compare them. This can be solved in the server by rewritin= g RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relay= ing to B, which requires rewriting both RTP packets and RTCP packets. This = is fine as long as you rewrite _all_ streams from the same sending client i= n the same way, otherwise you won't be able to synchronize them. Therefore = all streams must go through the same server. I'm suggesting that we could introduce a new "send timestamp" which doesn't= relate to the RTP timestamp (which is used for synchronized playback). Whe= never a packet is sent (no matter if it's sent from A, C or S) it will be s= tamped with the send-time taken from the clock of that sender, for instance= at 1 kHz or 90 kHz. Since it's not related to the RTP timestamp we won't h= ave to rewrite the (RTP, NTP) tuple, and actually, we don't even have to co= nvert to NTP at the receiver since all send timestamps are taken directly f= rom the same clock. Removing the relation to the RTP timestamp is what I me= an with an "absolute" timestamp (i.e., not relative to RTP timestamp). /Stefan On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > wrote: Please clarify "absolute". Do you mean another RTP timestamp using the same= units but a random offset from the main RTP timestamp, and no implied sync= across multiple RTP sessions? Or NTP timestamps with NTP units and implied= sync across all RTP sessions (within the same sync domain, currently defin= ed to be CNAME)? Please also clarify "relay conference server", as there are many RTP topolo= gies for conferencing. I think you are probably referring to a source proje= ction mixer. Rewriting RTCP is standard practice for those, as well as most= mixers. In fact, I can't envision when it would be possible to blindly rel= ay RTCP in any mixer/topology. So I'm not sure what complications you see a= rising from the use of RFC 5450. Mo From: rmcat-bounces@ietf.org [mailto:rmcat-b= ounces@ietf.org] On Behalf Of Stefan Holmer Sent: Tuesday, December 04, 2012 4:23 AM To: rmcat WG Subject: [rmcat] Send timestamps Hi, In draft-alvestrand-rtcweb-congestion-01 we proposed using a send timestamp RTP head= er extension for measuring the packet inter-arrival time offset. In 02 this was revi= sed to instead reference RFC 5450, whic= h specifies a header extension for specifying the send timestamp as an offs= et relative to the RTP timestamp. Thinking further about this, there seems to be a couple of benefits with de= fining a new, absolute, send timestamp header extension. If a relay approac= h to conference servers are used, the relaying server can simply rewrite th= e send timestamp of a packet to correspond to the time it was relayed. Doin= g so the receiver can jointly process all streams being received from the r= elay server, even though they were initially captured and sent by different= senders (with different clocks). With a send timestamp offset, accomplishing the same thing would require re= writing both the timestamp offset and the NTP time in the corresponding RTC= P SR reports. And to keep video synchronized with audio the RTCP packet for= the audio streams must also be rewritten in a similar way. This may not ev= en be possible if the audio stream is relayed through a different server. Do you see any problems with using an RTP header extension with absolute se= nd timestamps? Are there any benefits with the send timestamp offset header= extension I might be missing? /Stefan --_000_3879D71E758A7E4AA99A35DD8D41D3D90F647D5Bxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So we’re back to= two pendulums two months after deciding multi-hop is initially out of scop= e. I’m glad, because it will likely be a major (or perhaps even dominant) deployment scenario, which we should not defer based on complexi= ty alone.

 

If we introduce a new = send timestamp extension (which I’m unsure of the benefits over RFC 5= 450), I think it should be in NTP units not RTP media clock units. There is a precedent (in RTCP) for NTP timestamps that are synced across m= ultiple RTP sessions, but there is no such precedent for synced RTP timesta= mps. Different media types with different media clocks would also present p= roblems for synced RTP timestamps.

 

But even with this new= send timestamp extension (using absolute synced NTP timestamps), I donR= 17;t think it avoids Stefan’s problem of rewriting every RTP and RTCP packet at the server. Every RTP packet must still be rewritten with t= he new extension using the server’s NTP time, and every RTCP SR packe= t must still be rewritten for several reasons beyond congestion control.

 

So I really don’= t see any benefit that a new extension would provide beyond RFC 5450. Perha= ps I’m missing it.

 

I’m also missing= why you need to convert to NTP time in order to “jointly process all= RTP streams”, because only the deltas really matter not the actual NTP time, and RFC 5450 gives you all you need for deltas.

 

> If we want to joi= ntly process all RTP streams from A to B (at the receiver, B) we can conver= t the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report.

 

Mo

 

 

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf= .org] On Behalf Of Harald Alvestrand
Sent: Monday, December 17, 2012 6:07 AM
To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

Separating the timestamp used as a congestion signal= from timestamps that may be used for other purposes would seem to me to be= an advantage in terms of architectural cleanliness.

RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from Day O= ne, we need to be able to fall back to the RTP timestamp (it's better than = nothing), but it seems we shouldn't marry it more than we have to.

            &nb= sp; Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:

I'll try to clarify with an example:

 

Let's say we have two clients (A and B) i= n a call. We want to estimate the bandwidth from A to B by looking at the v= ariations in one-way delay, which we can measure by comparing deltas in RTP timestamp to deltas in receive-time. The problem with using = RTP timestamps is that those represent capture time and not the send time o= f a frame, so we get a lot of noise related to variations in, e.g., video e= ncoding time. To get around that we introduce RFC 5450 and now we can measure something much closer to = actual network time. If we want to jointly process all RTP streams from A t= o B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) = tuple in the RTCP SR report.

 

Now let's add a server (let's call it S) = in between client A and B. This server simply relays RTP packets (and might= do some rewriting as well). Now we want to estimate the bandwidth between A and S, and between S and B. S will have to change the = timestamp offset (RFC 5450) of the RTP packets to correspond to its send-ti= me, but besides that all is fine.

 

Now let's add a third client (C). S will = relay packets from both A and C to B, so ideally we should jointly process = all of those packets when estimating the bandwidth between S to B. However, packets sent from A will be based on the tuple (RTP times= tamp A, NTP timestamp A) and packets sent from C will be based on (RTP time= stamp C, NTP timestamp C), so we can't just convert to NTP at B and compare= them. This can be solved in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timest= amp S) before relaying to B, which requires rewriting both RTP packets and = RTCP packets. This is fine as long as you rewrite _all_ streams from the sa= me sending client in the same way, otherwise you won't be able to synchronize them. Therefore all streams mus= t go through the same server.

 

I'm suggesting that we could introduce a = new "send timestamp" which doesn't relate to the RTP timestamp (w= hich is used for synchronized playback). Whenever a packet is sent (no matter if it's sent from A, C or S) it will be stamped with the send-t= ime taken from the clock of that sender, for instance at 1 kHz or 90 kHz. S= ince it's not related to the RTP timestamp we won't have to rewrite the (RT= P, NTP) tuple, and actually, we don't even have to convert to NTP at the receiver since all send timestamp= s are taken directly from the same clock. Removing the relation to the RTP = timestamp is what I mean with an "absolute" timestamp (i.e., not = relative to RTP timestamp).

 

/Stefan

 = ;

On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanat= y (mzanaty) <mzan= aty@cisco.com> wrote:

Please clarify “absolute”. Do you mean an= other RTP timestamp using the same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or N= TP timestamps with NTP units and implied sync across all RTP sessions (with= in the same sync domain, currently defined to be CNAME)?=

 

Please also clarify “relay conference server= 221;, as there are many RTP topologies for conferencing. I think you are probably referring to a source projection mixer. Rewriting RTCP is standar= d practice for those, as well as most mixers. In fact, I can’t envisi= on when it would be possible to blindly relay RTCP in any mixer/topology. S= o I’m not sure what complications you see arising from the use of RFC 5450.<= /p>

 

Mo

 

From: rmcat-bounces@i= etf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps=

 

Hi,

 

In draft-alvestrand-rtcweb-congestion-01 we proposed using a send tim= estamp RTP header extension for measuring the packet inter-arrival time off= set. In 02 this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send ti= mestamp as an offset relative to the RTP timestamp.

 

Thinking further about this, there seems to be a couple= of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the = relaying server can simply rewrite the send timestamp of a packet to corres= pond to the time it was relayed. Doing so the receiver can jointly process = all streams being received from the relay server, even though they were initially captured and sent by dif= ferent senders (with different clocks). 

 

With a send timestamp offset, accomplishing the same th= ing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synch= ronized with audio the RTCP packet for the audio streams must also be rewri= tten in a similar way. This may not even be possible if the audio stream is= relayed through a different server.

 

Do you see any problems with using an RTP header extens= ion with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?

 

/Stefan

 

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F647D5Bxmbrcdx14ciscoc_-- From michawe@ifi.uio.no Mon Dec 17 12:43:35 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31E521F8450 for ; Mon, 17 Dec 2012 12:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeXAs6DP4Kn1 for ; Mon, 17 Dec 2012 12:43:34 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6F21F8438 for ; Mon, 17 Dec 2012 12:43:33 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TkhX8-0001cb-FS; Mon, 17 Dec 2012 21:43:30 +0100 Received: from 120.169.202.84.customer.cdi.no ([84.202.169.120] helo=[192.168.0.193]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TkhX7-0002oP-Mg; Mon, 17 Dec 2012 21:43:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> Date: Mon, 17 Dec 2012 21:43:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E958515-E11E-4767-9737-0731A44DB219@ifi.uio.no> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> To: Mo Zanaty (mzanaty) X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 906 max rcpts/h 20 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: CF0F79A0078E96ECA762DCB99E66B640C2C41D3C X-UiO-SPAM-Test: remote_host: 84.202.169.120 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 106 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: "Stefan Holmer \(holmer@google.com\)" , Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:43:35 -0000 +1 to what harald and stefan said, from a transport perspective. (i'll leave it to the rtp experts to say if that makes sense or not) as for the two pendulums thing: i think it's okay, and probably = important, for us to consider if signalling functions would also work in = a multi-hop case; this is a necessity to build a two- (or n-)pendulum = system. surely we don't want to exclude such deployment scenarios later on! when we talked about two pendulums, i think the point was to defer = looking into two-pendulum-dynamics, which i'd translate into: the buffer = management at an intermediate rtp hop. cheers michael On Dec 17, 2012, at 9:15 PM, Mo Zanaty (mzanaty) = wrote: > So we=92re back to two pendulums two months after deciding multi-hop = is initially out of scope. I=92m glad, because it will likely be a major = (or perhaps even dominant) deployment scenario, which we should not = defer based on complexity alone. > =20 > If we introduce a new send timestamp extension (which I=92m unsure of = the benefits over RFC 5450), I think it should be in NTP units not RTP = media clock units. There is a precedent (in RTCP) for NTP timestamps = that are synced across multiple RTP sessions, but there is no such = precedent for synced RTP timestamps. Different media types with = different media clocks would also present problems for synced RTP = timestamps. > =20 > But even with this new send timestamp extension (using absolute synced = NTP timestamps), I don=92t think it avoids Stefan=92s problem of = rewriting every RTP and RTCP packet at the server. Every RTP packet must = still be rewritten with the new extension using the server=92s NTP time, = and every RTCP SR packet must still be rewritten for several reasons = beyond congestion control. > =20 > So I really don=92t see any benefit that a new extension would provide = beyond RFC 5450. Perhaps I=92m missing it. > =20 > I=92m also missing why you need to convert to NTP time in order to = =93jointly process all RTP streams=94, because only the deltas really = matter not the actual NTP time, and RFC 5450 gives you all you need for = deltas. > =20 > > If we want to jointly process all RTP streams from A to B (at the = receiver, B) we can convert the RTP timestamps of all streams to NTP = using the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report. > =20 > Mo > =20 > =20 > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf = Of Harald Alvestrand > Sent: Monday, December 17, 2012 6:07 AM > To: rmcat@ietf.org > Subject: Re: [rmcat] Send timestamps > =20 > Separating the timestamp used as a congestion signal from timestamps = that may be used for other purposes would seem to me to be an advantage = in terms of architectural cleanliness. >=20 > RTP timestamps need to reflect media time. In a situation with relay = nodes and changing paths, this may have uncomfortable amounts of = variation from the time the packets enter the last hop to the recipient. >=20 > Given that we won't have all systems deploying the new extension from = Day One, we need to be able to fall back to the RTP timestamp (it's = better than nothing), but it seems we shouldn't marry it more than we = have to. >=20 > Harald >=20 > On 12/17/2012 12:00 PM, Stefan Holmer wrote: > I'll try to clarify with an example: > =20 > Let's say we have two clients (A and B) in a call. We want to estimate = the bandwidth from A to B by looking at the variations in one-way delay, = which we can measure by comparing deltas in RTP timestamp to deltas in = receive-time. The problem with using RTP timestamps is that those = represent capture time and not the send time of a frame, so we get a lot = of noise related to variations in, e.g., video encoding time. To get = around that we introduce RFC 5450 and now we can measure something much = closer to actual network time. If we want to jointly process all RTP = streams from A to B (at the receiver, B) we can convert the RTP = timestamps of all streams to NTP using the (RTP timestamp, NTP = timestamp) tuple in the RTCP SR report. > =20 > Now let's add a server (let's call it S) in between client A and B. = This server simply relays RTP packets (and might do some rewriting as = well). Now we want to estimate the bandwidth between A and S, and = between S and B. S will have to change the timestamp offset (RFC 5450) = of the RTP packets to correspond to its send-time, but besides that all = is fine. > =20 > Now let's add a third client (C). S will relay packets from both A and = C to B, so ideally we should jointly process all of those packets when = estimating the bandwidth between S to B. However, packets sent from A = will be based on the tuple (RTP timestamp A, NTP timestamp A) and = packets sent from C will be based on (RTP timestamp C, NTP timestamp C), = so we can't just convert to NTP at B and compare them. This can be = solved in the server by rewriting RTP and NTP timestamps to (RTP = timestamp S, NTP timestamp S) before relaying to B, which requires = rewriting both RTP packets and RTCP packets. This is fine as long as you = rewrite _all_ streams from the same sending client in the same way, = otherwise you won't be able to synchronize them. Therefore all streams = must go through the same server. > =20 > I'm suggesting that we could introduce a new "send timestamp" which = doesn't relate to the RTP timestamp (which is used for synchronized = playback). Whenever a packet is sent (no matter if it's sent from A, C = or S) it will be stamped with the send-time taken from the clock of that = sender, for instance at 1 kHz or 90 kHz. Since it's not related to the = RTP timestamp we won't have to rewrite the (RTP, NTP) tuple, and = actually, we don't even have to convert to NTP at the receiver since all = send timestamps are taken directly from the same clock. Removing the = relation to the RTP timestamp is what I mean with an "absolute" = timestamp (i.e., not relative to RTP timestamp). > =20 > /Stefan > =20 >=20 > On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) = wrote: > Please clarify =93absolute=94. Do you mean another RTP timestamp using = the same units but a random offset from the main RTP timestamp, and no = implied sync across multiple RTP sessions? Or NTP timestamps with NTP = units and implied sync across all RTP sessions (within the same sync = domain, currently defined to be CNAME)? > =20 > Please also clarify =93relay conference server=94, as there are many = RTP topologies for conferencing. I think you are probably referring to a = source projection mixer. Rewriting RTCP is standard practice for those, = as well as most mixers. In fact, I can=92t envision when it would be = possible to blindly relay RTCP in any mixer/topology. So I=92m not sure = what complications you see arising from the use of RFC 5450. > =20 > Mo > =20 > From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf = Of Stefan Holmer > Sent: Tuesday, December 04, 2012 4:23 AM > To: rmcat WG > Subject: [rmcat] Send timestamps > =20 > Hi, > =20 > In draft-alvestrand-rtcweb-congestion-01 we proposed using a send = timestamp RTP header extension for measuring the packet inter-arrival = time offset. In 02 this was revised to instead reference RFC 5450, which = specifies a header extension for specifying the send timestamp as an = offset relative to the RTP timestamp. > =20 > Thinking further about this, there seems to be a couple of benefits = with defining a new, absolute, send timestamp header extension. If a = relay approach to conference servers are used, the relaying server can = simply rewrite the send timestamp of a packet to correspond to the time = it was relayed. Doing so the receiver can jointly process all streams = being received from the relay server, even though they were initially = captured and sent by different senders (with different clocks).=20 > =20 > With a send timestamp offset, accomplishing the same thing would = require rewriting both the timestamp offset and the NTP time in the = corresponding RTCP SR reports. And to keep video synchronized with audio = the RTCP packet for the audio streams must also be rewritten in a = similar way. This may not even be possible if the audio stream is = relayed through a different server. > =20 > Do you see any problems with using an RTP header extension with = absolute send timestamps? Are there any benefits with the send timestamp = offset header extension I might be missing? > =20 > /Stefan > =20 > =20 From holmer@google.com Mon Dec 17 13:20:42 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A279621F88A3 for ; Mon, 17 Dec 2012 13:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pehg+-Z1PAtG for ; Mon, 17 Dec 2012 13:20:41 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBA21F8832 for ; Mon, 17 Dec 2012 13:20:39 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so3049272bku.31 for ; Mon, 17 Dec 2012 13:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7cQPl8q3LIL0r0K5e4IYSNrCGk7qgf2zOTef5P8r+aU=; b=Km095giSSwtgMGwuZGpaseK/J6efxLXQxeRRPUPhjpmfQ/ijWb+pFYwzdS2kJRX9sY F6ZrI99vhHIJAYLDaAAH/KaeaTJ1caEpx/RzX2byDn83tqrxWEXaCc8y13+IrR40jFGo UG9oLuIplr/ubI6DCVB44+q43iTdTOzGQ7dOtMpqJdcjIGFWi66dOoPLJVLmJIKTFMSU XWqcG2FpFvvktzNtnwZiAHYQz+GPsne2+wwxMQgA/TyxgGz9Remz7Qbod95zX58MBTxu IEUFLpU4GqgIrQvXD6oI2Y9bRD6nOc5aM3CVUu4BKo9sW2ims1OXM8sfFlAvsIACa/XX 4iMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7cQPl8q3LIL0r0K5e4IYSNrCGk7qgf2zOTef5P8r+aU=; b=CmwPvEpAAlJgMShnGad/cJm/omTBJ6IoeH3Ut2hfZ4qsxI2Td7h6O+MWTSF/BrlkPK +S3hLTH4Gl0EZ44aspZxt3sLIbwMFSYbP6h0czn44thgZ5qGByT4+O+NowLQIk7mHwis 8a6/0YMwYfOzqaX/u1LstqQ5X4TymIfL3p5Fm0+WpwoXjue8752quWCZLixllx0uTkPv MQYTyCSdkQ2KgLRKLhrpz6fPMFn2NcERCMLNMTV+yDAiwTAlj6C85Fyc/SivCS5v5tnq qjQ5ci82NHlxsS3kp/un0O82weTDVDPSXfn5qr1UihgyqUfHcsqSgfzheDohKmj8+aEM ETNQ== MIME-Version: 1.0 Received: by 10.204.156.139 with SMTP id x11mr6209027bkw.128.1355779234683; Mon, 17 Dec 2012 13:20:34 -0800 (PST) Received: by 10.204.99.210 with HTTP; Mon, 17 Dec 2012 13:20:34 -0800 (PST) In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> Date: Mon, 17 Dec 2012 22:20:34 +0100 Message-ID: From: Stefan Holmer To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=0015175dd714ad5cca04d112f303 X-Gm-Message-State: ALoCoQn8giwRnGcub+wQiw9xkMxJmTXFMMqVDXWQI2+0rNS9f4jnnHlJnRUmHcbgEPODyqGZc7lGH50JVzju/TO7RjiBvcJZnsdf9+MfHvnwCyAZrK+i4GXOxPwysb/gT2NfY0rD+AGjig5bUmBX+R7hDFWJi0cmioJZfshqQvypLi1taSZwalBBiXGUp072cLzxUv4+Ae7Y Cc: Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:20:42 -0000 --0015175dd714ad5cca04d112f303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Dec 17, 2012 at 9:15 PM, Mo Zanaty (mzanaty) wro= te: > So we=92re back to two pendulums two months after deciding multi-hop is > initially out of scope. I=92m glad, because it will likely be a major (or > perhaps even dominant) deployment scenario, which we should not defer bas= ed > on complexity alone.**** > > ** ** > > If we introduce a new send timestamp extension (which I=92m unsure of the > benefits over RFC 5450), I think it should be in NTP units not RTP media > clock units. There is a precedent (in RTCP) for NTP timestamps that are > synced across multiple RTP sessions, but there is no such precedent for > synced RTP timestamps. Different media types with different media clocks > would also present problems for synced RTP timestamps.**** > > ** ** > > But even with this new send timestamp extension (using absolute synced NT= P > timestamps), I don=92t think it avoids Stefan=92s problem of rewriting ev= ery > RTP and RTCP packet at the server. Every RTP packet must still be rewritt= en > with the new extension using the server=92s NTP time, and every RTCP SR > packet must still be rewritten for several reasons beyond congestion > control. > Perhaps. I don't see why rewriting the full (RTP timestamp, NTP timestamp) tuple is necessary for other reasons though. The problem as I see it is when we, at the receiving client B, are to compute the delta between packets generated by A and packets generated by C. Even if we convert them both to NTP, their NTP timestamps aren't likely to be in sync. They can be if S has rewritten the RTCP SRs so that the NTP timestamp of streams from A and C now are based on the clock of S (NTP timestamp S). But when that has been done we also have to rewrite the RTCP SR of all other streams from A and C which we at some point would like to have synchronized playback with, which will require all those streams to also go through S. So basically we will not be able to have to servers, S1 and S2, which for example handle video and audio streams respectively. Maybe not a big issue, but to me it feels like a limitation without benefits. I don't see the point of requiring that timestamps used for congestion control should be set in relation to the RTP timestamps which is meant for doing synchronized playback. > **** > > ** ** > > So I really don=92t see any benefit that a new extension would provide > beyond RFC 5450. Perhaps I=92m missing it.**** > > ** ** > > I=92m also missing why you need to convert to NTP time in order to =93joi= ntly > process all RTP streams=94, because only the deltas really matter not the > actual NTP time, and RFC 5450 gives you all you need for deltas. > The deltas only have a meaning in relation to the corresponding RTP timestamp. RTP timestamps of different streams (SSRCs) have different random offsets, and therefore can't be compared before converted to NTP. At least if you want to calculate the delta between packets belonging from two different streams. > **** > > ** ** > > > If we want to jointly process all RTP streams from A to B (at the > receiver, B) we can convert the RTP timestamps of all streams to NTP usin= g > the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report.**** > > ** ** > > Mo**** > > ** ** > > ** ** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Harald Alvestrand > *Sent:* Monday, December 17, 2012 6:07 AM > > *To:* rmcat@ietf.org > *Subject:* Re: [rmcat] Send timestamps**** > > ** ** > > Separating the timestamp used as a congestion signal from timestamps that > may be used for other purposes would seem to me to be an advantage in ter= ms > of architectural cleanliness. > > > RTP timestamps need to reflect media time. In a situation with relay node= s > and changing paths, this may have uncomfortable amounts of variation from > the time the packets enter the last hop to the recipient. > > Given that we won't have all systems deploying the new extension from Day > One, we need to be able to fall back to the RTP timestamp (it's better th= an > nothing), but it seems we shouldn't marry it more than we have to. > > Harald > > On 12/17/2012 12:00 PM, Stefan Holmer wrote:**** > > I'll try to clarify with an example: **** > > ** ** > > Let's say we have two clients (A and B) in a call. We want to estimate th= e > bandwidth from A to B by looking at the variations in one-way delay, whic= h > we can measure by comparing deltas in RTP timestamp to deltas in > receive-time. The problem with using RTP timestamps is that those represe= nt > capture time and not the send time of a frame, so we get a lot of noise > related to variations in, e.g., video encoding time. To get around that w= e > introduce RFC 5450 and now we can > measure something much closer to actual network time. If we want to joint= ly > process all RTP streams from A to B (at the receiver, B) we can convert t= he > RTP timestamps of all streams to NTP using the (RTP timestamp, NTP > timestamp) tuple in the RTCP SR report.**** > > ** ** > > Now let's add a server (let's call it S) in between client A and B. This > server simply relays RTP packets (and might do some rewriting as well). N= ow > we want to estimate the bandwidth between A and S, and between S and B. S > will have to change the timestamp offset (RFC 5450) of the RTP packets to > correspond to its send-time, but besides that all is fine.**** > > ** ** > > Now let's add a third client (C). S will relay packets from both A and C > to B, so ideally we should jointly process all of those packets when > estimating the bandwidth between S to B. However, packets sent from A wil= l > be based on the tuple (RTP timestamp A, NTP timestamp A) and packets sent > from C will be based on (RTP timestamp C, NTP timestamp C), so we can't > just convert to NTP at B and compare them. This can be solved in the serv= er > by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) > before relaying to B, which requires rewriting both RTP packets and RTCP > packets. This is fine as long as you rewrite _all_ streams from the same > sending client in the same way, otherwise you won't be able to synchroniz= e > them. Therefore all streams must go through the same server.**** > > ** ** > > I'm suggesting that we could introduce a new "send timestamp" which > doesn't relate to the RTP timestamp (which is used for synchronized > playback). Whenever a packet is sent (no matter if it's sent from A, C or > S) it will be stamped with the send-time taken from the clock of that > sender, for instance at 1 kHz or 90 kHz. Since it's not related to the RT= P > timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we > don't even have to convert to NTP at the receiver since all send timestam= ps > are taken directly from the same clock. Removing the relation to the RTP > timestamp is what I mean with an "absolute" timestamp (i.e., not relative > to RTP timestamp).**** > > ** ** > > /Stefan**** > > ** ** > > On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > wrote:**** > > Please clarify =93absolute=94. Do you mean another RTP timestamp using th= e > same units but a random offset from the main RTP timestamp, and no implie= d > sync across multiple RTP sessions? Or NTP timestamps with NTP units and > implied sync across all RTP sessions (within the same sync domain, > currently defined to be CNAME)?**** > > **** > > Please also clarify =93relay conference server=94, as there are many RTP > topologies for conferencing. I think you are probably referring to a sour= ce > projection mixer. Rewriting RTCP is standard practice for those, as well = as > most mixers. In fact, I can=92t envision when it would be possible to bli= ndly > relay RTCP in any mixer/topology. So I=92m not sure what complications yo= u > see arising from the use of RFC 5450.**** > > **** > > Mo**** > > **** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Stefan Holmer > *Sent:* Tuesday, December 04, 2012 4:23 AM > *To:* rmcat WG > *Subject:* [rmcat] Send timestamps**** > > **** > > Hi,**** > > **** > > In draft-alvestrand-rtcweb-congestion-01 we > proposed using a send timestamp RTP header extension for measuring the > packet inter-arrival time offset. In 02 this > was revised to instead reference RFC 5450, > which specifies a header extension for specifying the send timestamp as a= n > offset relative to the RTP timestamp.**** > > **** > > Thinking further about this, there seems to be a couple of benefits with > defining a new, absolute, send timestamp header extension. If a relay > approach to conference servers are used, the relaying server can simply > rewrite the send timestamp of a packet to correspond to the time it was > relayed. Doing so the receiver can jointly process all streams being > received from the relay server, even though they were initially captured > and sent by different senders (with different clocks). **** > > **** > > With a send timestamp offset, accomplishing the same thing would require > rewriting both the timestamp offset and the NTP time in the corresponding > RTCP SR reports. And to keep video synchronized with audio the RTCP packe= t > for the audio streams must also be rewritten in a similar way. This may n= ot > even be possible if the audio stream is relayed through a different serve= r. > **** > > **** > > Do you see any problems with using an RTP header extension with absolute > send timestamps? Are there any benefits with the send timestamp offset > header extension I might be missing?**** > > **** > > /Stefan**** > > ** ** > > ** ** > --0015175dd714ad5cca04d112f303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">


On Mon, Dec 17, 2012 at 9:15 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

So we=92re back to two= pendulums two months after deciding multi-hop is initially out of scope. I= =92m glad, because it will likely be a major (or perhaps even dominant) deployment scenario, which we should not defer based on complexi= ty alone.

=A0

If we introduce a new = send timestamp extension (which I=92m unsure of the benefits over RFC 5450)= , I think it should be in NTP units not RTP media clock units. There is a precedent (in RTCP) for NTP timestamps that are synced across m= ultiple RTP sessions, but there is no such precedent for synced RTP timesta= mps. Different media types with different media clocks would also present p= roblems for synced RTP timestamps.

=A0

But even with this new= send timestamp extension (using absolute synced NTP timestamps), I don=92t= think it avoids Stefan=92s problem of rewriting every RTP and RTCP packet at the server. Every RTP packet must still be rewritten with t= he new extension using the server=92s NTP time, and every RTCP SR packet mu= st still be rewritten for several reasons beyond congestion control.=


Perhaps. I don't see= why rewriting the full (RTP timestamp, NTP timestamp) tuple is necessary f= or other reasons though.

The problem a= s I see it is when we, at the receiving client B, are to compute the delta = between packets generated by A and packets generated by C. Even if we conve= rt them both to NTP, their NTP timestamps aren't likely to be in sync. = They can be if S has rewritten the RTCP SRs so that the NTP timestamp of st= reams from A and C now are based on the clock of S (NTP timestamp S). But w= hen that has been done we also have to rewrite the RTCP SR of all other str= eams from A and C which we at some point would like to have synchronized pl= ayback with, which will require all those streams to also go through S. So = basically we will not be able to have to servers, S1 and S2, which for exam= ple handle video and audio streams respectively.

Maybe not a big issue, but to me it feels l= ike a limitation without benefits. I don't see the point of requiring t= hat timestamps used for congestion control should be set in relation to the= RTP timestamps which is meant for doing synchronized playback.
=A0

=A0

So I really don=92t se= e any benefit that a new extension would provide beyond RFC 5450. Perhaps I= =92m missing it.

=A0

I=92m also missing why= you need to convert to NTP time in order to =93jointly process all RTP str= eams=94, because only the deltas really matter not the actual NTP time, and RFC 5450 gives you all you need for deltas.

=

The deltas only have a meaning= in relation to the corresponding RTP timestamp. RTP timestamps of differen= t streams (SSRCs) have different random offsets, and therefore can't be= compared before converted to NTP. At least if you want to calculate the de= lta between packets belonging from two different streams.
=A0

=A0

> If we want to joi= ntly process all RTP streams from A to B (at the receiver, B) we can conver= t the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the RTCP SR report.

=A0

Mo=

=A0

=A0

From: rmcat-bounces@ietf.org [mailto:rmcat-bou= nces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, December 17, 2012 6:07 AM

=
To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

=A0

Separating the timestamp used as a congestion signal= from timestamps that may be used for other purposes would seem to me to be= an advantage in terms of architectural cleanliness.



RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from D= ay One, we need to be able to fall back to the RTP timestamp (it's bett= er than nothing), but it seems we shouldn't marry it more than we have = to.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:

I'll try to clarify with an example:

=A0

Let's say we have two clients (A and = B) in a call. We want to estimate the bandwidth from A to B by looking at t= he variations in one-way delay, which we can measure by comparing deltas in RTP timestamp to deltas in receive-time. The problem with using = RTP timestamps is that those represent capture time and not the send time o= f a frame, so we get a lot of noise related to variations in, e.g., video e= ncoding time. To get around that we introduce=A0RFC 5450=A0and now we can measure something much= closer to actual network time. If we want to jointly process all RTP strea= ms from A to B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) = tuple in the RTCP SR report.

=A0

Now let's add a server (let's cal= l it S) in between client A and B. This server simply relays RTP packets (a= nd might do some rewriting as well). Now we want to estimate the bandwidth between A and S, and between S and B. S will have to change the = timestamp offset (RFC 5450) of the RTP packets to correspond to its send-ti= me, but besides that all is fine.

=A0

Now let's add a third client (C). S w= ill relay packets from both A and C to B, so ideally we should jointly proc= ess all of those packets when estimating the bandwidth between S to B. However, packets sent from A will be based on the tuple (RTP times= tamp A, NTP timestamp A) and packets sent from C will be based on (RTP time= stamp C, NTP timestamp C), so we can't just convert to NTP at B and com= pare them. This can be solved in the server by rewriting RTP and NTP timestamps to (RTP timestamp S, NTP timest= amp S) before relaying to B, which requires rewriting both RTP packets and = RTCP packets. This is fine as long as you rewrite _all_ streams from the sa= me sending client in the same way, otherwise you won't be able to synchronize them. Therefore all streams= must go through the same server.

=A0

I'm suggesting that we could introduc= e a new "send timestamp" which doesn't relate to the RTP time= stamp (which is used for synchronized playback). Whenever a packet is sent (no matter if it's sent from A, C or S) it will be stamped with the se= nd-time taken from the clock of that sender, for instance at 1 kHz or 90 kH= z. Since it's not related to the RTP timestamp we won't have to rew= rite the (RTP, NTP) tuple, and actually, we don't even have to convert to NTP at the receiver since all send times= tamps are taken directly from the same clock. Removing the relation to the = RTP timestamp is what I mean with an "absolute" timestamp (i.e., = not relative to RTP timestamp).

=A0

/Stefan

=A0=

On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanat= y (mzanaty) <mzanaty@cisco.com> wrote:

Please clarify =93absolute=94. Do you m= ean another RTP timestamp using the same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or N= TP timestamps with NTP units and implied sync across all RTP sessions (with= in the same sync domain, currently defined to be CNAME)?=

=A0

Please also clarify =93relay conference= server=94, as there are many RTP topologies for conferencing. I think you = are probably referring to a source projection mixer. Rewriting RTCP is standar= d practice for those, as well as most mixers. In fact, I can=92t envision w= hen it would be possible to blindly relay RTCP in any mixer/topology. So I= =92m not sure what complications you see arising from the use of RFC 5450.

=A0

Mo

=A0

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

=A0

Hi,

=A0

In draft-alvestrand-rtcweb-congestion-01=A0we proposed using a send timest= amp RTP header extension for measuring the packet inter-arrival time offset= . In 02=A0this was revised to instead reference RFC 5450, which specifies a header extension for specifying the send ti= mestamp as an offset relative to the RTP timestamp.

=A0

Thinking further about this, there seems = to be a couple of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the = relaying server can simply rewrite the send timestamp of a packet to corres= pond to the time it was relayed. Doing so the receiver can jointly process = all streams being received from the relay server, even though they were initially captured and sent by dif= ferent senders (with different clocks).=A0

=A0

With a send timestamp offset, accomplishi= ng the same thing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synch= ronized with audio the RTCP packet for the audio streams must also be rewri= tten in a similar way. This may not even be possible if the audio stream is= relayed through a different server.

=A0

Do you see any problems with using an RTP= header extension with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?=

=A0

/Stefan

=A0

=A0


--0015175dd714ad5cca04d112f303-- From ingemar.s.johansson@ericsson.com Tue Dec 18 01:50:07 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14E721F87AB for ; Tue, 18 Dec 2012 01:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk3GuYsiddfM for ; Tue, 18 Dec 2012 01:50:05 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6127E21F8735 for ; Tue, 18 Dec 2012 01:50:04 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-1b-50d03c4b9898 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 24.7E.04318.B4C30D05; Tue, 18 Dec 2012 10:50:03 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.209]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 10:50:02 +0100 From: Ingemar Johansson S To: Harald Alvestrand , "holmer@google.com" Thread-Topic: Sender or Receiver based CC (was RE: [rmcat] Send timestamps) Thread-Index: Ac3dA9Zw8/BFewn3R0+mrhZpb3iLGg== Date: Tue, 18 Dec 2012 09:50:02 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DDBAESESSMB205ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja63zYUAgyXrRSyO9XWxWVzdf47F YvXND2wOzB5XJlxh9ViwqdRjyZKfTAHMUVw2Kak5mWWpRfp2CVwZx/8fZS44PJ2xYv3ddywN jPNaGLsYOTkkBEwkNp88xgRhi0lcuLeerYuRi0NI4BCjxNW1O9ghnCWMEi/OPWYBqWITsJFY eeg7WLeIQLhE68XzQHEODmaBeIl9C5RAwsICbhK7fs9ihSjxlth+4BQzhK0nMX3RBDYQm0VA VeLYs1/sIK28QDUTvpSAhBkFZCXuf78HtolZQFzi1pP5ULcJSCzZc54ZwhaVePn4HyuErSjx 8dU+Roj6fIlDh0+zg9i8AoISJ2c+YZnAKDwLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x9 5sBjJmTxBYzsqxjZcxMzc9LLzTcxAuPm4JbfBjsYN90XO8QozcGiJM6rp7rfX0ggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVAPjAT6hmvt/BFg4RWs4pVkcTXaYhP3tPMLpJvF89XujZXO+tV9w vcXcJp16JVIngCPPpiH4e3q7YEXNPLbHu89tcyuamjKV5Vzp7W3zfm58edOoY0ppVI5P3cmq nFs1WyVufP3FHu+QuFPHbG74b/YX137cSHReq+T+Oeg0z5I5JwM/NGyKrfZRYinOSDTUYi4q TgQAqqmhPGkCAAA= Cc: Ingemar Johansson S , "rmcat@ietf.org" Subject: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:50:08 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DDBAESESSMB205ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thanks Harald and Stefan OK, understand. The concept is then to do atleast the delay based rate adap= tation in the receiving end. The feedback the sender would then be either a= n absolute bitrate value or a relative increase/decrease value depending on= the algorithm. Change subject line as I deviate from the original thread a little. I believe this has been discussed before but repeat it. What about packet loss and ECN marks ? , bufferbloat will eventually go a= way, may take 5 years, 10 years, 20 years, don't know. I see it unlikely th= at a delay based algo will be able to tune it self such that it will effici= ently avoid packet drops, for instance a queue with the CoDel algorithm may= drop/mark packets even at very low queue depths because of its inherent de= sign. So the algo needs to be reactive to packet loss/marks (not a particul= arly controversial point) Here one can chose two paths for the packet loss/mark based rate adaptation= . Sender based rate adaptation: Requires feedback of packet drops/mark, the a= ccuracy depends on how the feedback is used. Receiver based rate adaptation: Feedback is only a rate command. It would seems like the receiver based algo is to prefer. There are however= at least two reasons to why a sender based algo is to prefer. 1) Ack-clocking, while TCP is not 100% perfect it has sofar avoided co= llapsing the internet completely. A big reason is ack-clocking meaning tha= t sudden increases of RTT is reacted to quite fast. At the same time that p= acket loss/marks are reported, it is also possible to report back successfu= lly received packets. Only a receiver based algo may be too slow in this re= spect. For the ack-clocking to work some timeliness of the feedback is requ= ired, RTCP may be too infrequent, inband feedback has been suggested as a s= olution earlier. 2) ConEx: I believe that the future will require that applications exp= ose the congestion that they cause. A ConEx enabled endpoint is required to= state caused congestion, this means that the receiver must feedback the pa= cket loss/marks accurately, inband feedback may be to prefer here as it is = more timely than RTCP. Both of the statements above implines that one may as well to the packet lo= ss/mark based rate adaptation the sender side. I have deliberately only considered communication between two peers in this= email. More advanced cases may of course add other concerns. /Ingemar From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 17 december 2012 20:37 To: Ingemar Johansson S Cc: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: Hi I believe that it can make sense to use a separate timestamp for congestion= control but I may need to read and understand some more. A few reflections= though. Unless I miss something, this is quite close to the TCP timestamps which ar= e used for congestion avoidance in TCP Vegas and LEDBAT. The problem in Vegas is that it is sensitive to congestion in the feedback = path, not shure though how much concern that should be. If we keep a model of computation-at-receiver, it's not a problem at all. LEDBAT modifies this and implement the concept of base delay, but suffers f= rom late comers advantage. Both the above assume that one ACKs are returned to the sender almost immed= iately (delay ACK adds some uncertanity here) also one don't need to synchr= onize clocks. Here I get unsure about what to do with the received timestamps, I guess yo= u can compute a delta between sent and received timestamp but unless you ha= ve exactly synchronized clocks in sender(s) and receiver(s), you will have = an unknown offset that can possibly also drift due to clock skew. As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue. I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence. --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DDBAESESSMB205ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

Thanks Harald and Stefan<= o:p>

OK, understand. The conce= pt is then to do atleast the delay based rate adaptation in the receiving e= nd. The feedback the sender would then be either an absolute bitrate value or a relative increase/decrease value depending on the algor= ithm.

 <= /p>

Change subject line as I = deviate from the original thread a little.

I believe this has been d= iscussed before but repeat it.

 <= /p>

What about packet loss &n= bsp;and ECN marks ? ,  bufferbloat will eventually go away, may take 5= years, 10 years, 20 years, don’t know. I see it unlikely that a dela= y based algo will be able to tune it self such that it will efficiently avoi= d packet drops, for instance a queue with the CoDel algorithm may drop/mark= packets even at very low queue depths because of its inherent design. So t= he algo needs to be reactive to packet loss/marks (not a particularly controversial point)

 <= /p>

Here one can chose two pa= ths for the packet loss/mark based rate adaptation.

Sender based rate adaptat= ion: Requires feedback of packet drops/mark, the accuracy depends on how th= e feedback is used.

Receiver based rate adapt= ation: Feedback is only a rate command.

 <= /p>

It would seems like the r= eceiver based algo is to prefer. There are however at least two reasons to = why a sender based algo is to prefer.

1)&nbs= p;     Ack-clocking, whi= le TCP is not 100% perfect it has sofar avoided collapsing the internet com= pletely.  A big reason is ack-clocking meaning that sudden increases of RTT is reacted to quite fast. At the same time that packet lo= ss/marks are reported, it is also possible to report back successfully rece= ived packets. Only a receiver based algo may be too slow in this respect. F= or the ack-clocking to work some timeliness of the feedback is required, RTCP may be too infrequent, inband= feedback has been suggested as a solution earlier.

2)&nbs= p;     ConEx: I believe = that the future will require that applications expose the congestion that t= hey cause. A ConEx enabled endpoint is required to state caused congestion, this means that the receiver must feedback the packet l= oss/marks accurately, inband feedback may be to prefer here as it is more t= imely than RTCP.

Both of the statements ab= ove implines that one may as well to the packet loss/mark based rate adapta= tion the sender side.

 <= /p>

I have deliberately only = considered communication between two peers in this email. More advanced cas= es may of course add other concerns.

 <= /p>

/Ingemar

 <= /p>

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: den 17 december 2012 20:37
To: Ingemar Johansson S
Cc: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:

Hi

 <= /p>

I believe that it can mak= e sense to use a separate timestamp for congestion control but I may need t= o read and understand some more. A few reflections though.

 <= /p>

Unless I miss something, = this is quite close to the TCP timestamps which are used for congestion avo= idance in TCP Vegas and LEDBAT.

The problem in Vegas is t= hat it is sensitive to congestion in the feedback path, not shure though ho= w much concern that should be.

If we keep a model of computation-at-receiver, it's = not a problem at all.

LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers advantage= .

Both the above assume tha= t one ACKs are returned to the sender almost immediately (delay ACK adds so= me uncertanity here) also one don’t need to synchronize clocks.

Here I get unsure about w= hat to do with the received timestamps, I guess you can compute a delta bet= ween sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.


As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence.

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DDBAESESSMB205ericsso_-- From michawe@ifi.uio.no Tue Dec 18 02:05:51 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A737321F882B for ; Tue, 18 Dec 2012 02:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o4B6qJbRMDW for ; Tue, 18 Dec 2012 02:05:50 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id A6F2221F880C for ; Tue, 18 Dec 2012 02:05:49 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Tku3X-0000i5-78; Tue, 18 Dec 2012 11:05:47 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Tku3W-0005c4-B9; Tue, 18 Dec 2012 11:05:47 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_437C694D-0102-4257-9C47-BB184AFA724E" From: Michael Welzl In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> Date: Tue, 18 Dec 2012 11:05:45 +0100 Message-Id: <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 917 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1A63F9C6FC0480FEB4ABDCF0FB4E3542330D6452 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 318 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: "holmer@google.com" , Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 10:05:51 -0000 --Apple-Mail=_437C694D-0102-4257-9C47-BB184AFA724E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, In line: On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: > Hi > Thanks Harald and Stefan > OK, understand. The concept is then to do atleast the delay based rate = adaptation in the receiving end. The feedback the sender would then be = either an absolute bitrate value or a relative increase/decrease value = depending on the algorithm. > =20 > Change subject line as I deviate from the original thread a little. > I believe this has been discussed before but repeat it. > =20 > What about packet loss and ECN marks ? , bufferbloat will eventually = go away, may take 5 years, 10 years, 20 years, don=92t know. I see it = unlikely that a delay based algo will be able to tune it self such that = it will efficiently avoid packet drops, for instance a queue with the = CoDel algorithm may drop/mark packets even at very low queue depths = because of its inherent design. So the algo needs to be reactive to = packet loss/marks (not a particularly controversial point) Indeed, I think we all agree on this? > =20 > Here one can chose two paths for the packet loss/mark based rate = adaptation. > Sender based rate adaptation: Requires feedback of packet drops/mark, = the accuracy depends on how the feedback is used. > Receiver based rate adaptation: Feedback is only a rate command. > =20 > It would seems like the receiver based algo is to prefer. There are = however at least two reasons to why a sender based algo is to prefer. > 1) Ack-clocking, while TCP is not 100% perfect it has sofar = avoided collapsing the internet completely. A big reason is = ack-clocking meaning that sudden increases of RTT is reacted to quite = fast. At the same time that packet loss/marks are reported, it is also = possible to report back successfully received packets. Only a receiver = based algo may be too slow in this respect. For the ack-clocking to work = some timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution earlier. I think that ACK clocking is not really an option for a rate based = scheme with reasonably limited feedback anyway. You say that = ACK-clocking is a big reason for TCP preventing the Internet from = collapsing. I challenge that notion (I can hear the sound from the = audience...). Yes it has been said again and again that ACK-clocking has = that seminal role, but show me some proof. I don't remember seeing a = paper which convincingly shows exactly that. We can, on the other hand, say that rate based congestion controls (as = used at the app layer in UDP based apps already) haven't yet driven the = Internet into collapse... I would argue that the more important thing seems to be to have a = timeout, reacting on a reasonable RTT based time scale, and that can be = achieved with a rate based scheme. > 2) ConEx: I believe that the future will require that = applications expose the congestion that they cause. A ConEx enabled = endpoint is required to state caused congestion, this means that the = receiver must feedback the packet loss/marks accurately, inband feedback = may be to prefer here as it is more timely than RTCP. I would suggest to standardize RMCAT extensions for ConEx later, when we = see a need due to widespread ConEx deployment ;-) > Both of the statements above implines that one may as well to the = packet loss/mark based rate adaptation the sender side. > =20 > I have deliberately only considered communication between two peers in = this email. More advanced cases may of course add other concerns. > =20 > /Ingemar Cheers, Michael > =20 > =20 > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: den 17 december 2012 20:37 > To: Ingemar Johansson S > Cc: rmcat@ietf.org > Subject: Re: [rmcat] Send timestamps > =20 > On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: > Hi > =20 > I believe that it can make sense to use a separate timestamp for = congestion control but I may need to read and understand some more. A = few reflections though. > =20 > Unless I miss something, this is quite close to the TCP timestamps = which are used for congestion avoidance in TCP Vegas and LEDBAT. > The problem in Vegas is that it is sensitive to congestion in the = feedback path, not shure though how much concern that should be. > If we keep a model of computation-at-receiver, it's not a problem at = all. >=20 > LEDBAT modifies this and implement the concept of base delay, but = suffers from late comers advantage. > Both the above assume that one ACKs are returned to the sender almost = immediately (delay ACK adds some uncertanity here) also one don=92t need = to synchronize clocks. > Here I get unsure about what to do with the received timestamps, I = guess you can compute a delta between sent and received timestamp but = unless you have exactly synchronized clocks in sender(s) and = receiver(s), you will have an unknown offset that can possibly also = drift due to clock skew. >=20 > As Stefan says - since we measure ~a moving average of difference = between the (receive timestamp - send timestamp) of successive packets, = not an absolute transit time, value, this is not likely to be an issue. >=20 > I have a hard time imagining clock drift so severe that it will = significantly influence the deltas of packets that are sent less than a = second apart. Clock jumps (like leap seconds) may be a measurable, but = extremely transient, influence. >=20 --Apple-Mail=_437C694D-0102-4257-9C47-BB184AFA724E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

In = line:


On 18. des. 2012, at 10:50, = Ingemar Johansson S wrote:

Thanks Harald and Stefan
OK, = understand. The concept is then to do atleast the delay based rate = adaptation in the receiving end. The feedback the sender would then be = either an absolute bitrate value or a relative increase/decrease value = depending on the algorithm.
Change subject line as I deviate from the original = thread a little.
I believe this has been discussed before but repeat = it.
 
What about = packet loss  and ECN marks ? ,  bufferbloat will eventually go = away, may take 5 years, 10 years, 20 years, don=92t know. I see it = unlikely that a delay based algo will be able to tune it self such that = it will efficiently avoid packet drops, for instance a queue with the = CoDel algorithm may drop/mark packets even at very low queue depths = because of its inherent design. So the algo needs to be reactive to = packet loss/marks (not a particularly controversial = point)

Indeed, = I think we all agree on this?

Here one can chose two paths for the packet = loss/mark based rate adaptation.
Sender = based rate adaptation: Requires feedback of packet drops/mark, the = accuracy depends on how the feedback is = used.
Receiver based rate adaptation: Feedback is only a = rate command.
 
It would = seems like the receiver based algo is to prefer. There are however at = least two reasons to why a sender based algo is to = prefer.
1) Ack-clocking, while TCP is not 100% perfect it has = sofar avoided collapsing the internet completely.  A big reason is = ack-clocking meaning that sudden increases of RTT is reacted to quite = fast. At the same time that packet loss/marks are reported, it is also = possible to report back successfully received packets. Only a receiver = based algo may be too slow in this respect. For the ack-clocking to work = some timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution = earlier.

I= think that ACK clocking is not really an option for a rate based scheme = with reasonably limited feedback anyway. You say that ACK-clocking is a = big reason for TCP preventing the Internet from collapsing. I challenge = that notion (I can hear the sound from the audience...). Yes it has been = said again and again that ACK-clocking has that seminal role, but show = me some proof. I don't remember seeing a paper which convincingly shows = exactly that.

We can, on the other hand, say = that rate based congestion controls (as used at the app layer in UDP = based apps already) haven't yet driven the Internet into = collapse...

I would argue that the more = important thing seems to be to have a timeout, reacting on a reasonable = RTT based time scale, and that can be achieved with a rate based = scheme.


2) ConEx: I believe that the future will require that = applications expose the congestion that they cause. A ConEx enabled = endpoint is required to state caused congestion, this means that the = receiver must feedback the packet loss/marks accurately, inband feedback = may be to prefer here as it is more timely than = RTCP.

I would = suggest to standardize RMCAT extensions for ConEx later, when we see a = need due to widespread ConEx deployment   = ;-)


Both of the statements above implines that = one may as well to the packet loss/mark based rate adaptation the sender = side.
 
I have = deliberately only considered communication between two peers in this = email. More advanced cases may of course add other = concerns.
 
 
 Harald Alvestrand = [mailto:harald@alvestrand.no] 
Sent: den 17 december 2012 = 20:37
To: Ingemar Johansson = S
Cc: rmcat@ietf.org
Subject: Re: [rmcat] Send = timestamps
On = 12/17/2012 03:45 PM, Ingemar Johansson S = wrote:
 
I believe = that it can make sense to use a separate timestamp for congestion = control but I may need to read and understand some more. A few = reflections though.
 
Unless I = miss something, this is quite close to the TCP timestamps which are used = for congestion avoidance in TCP Vegas and = LEDBAT.
The problem in Vegas is that it is sensitive to = congestion in the feedback path, not shure though how much concern that = should be.
LEDBAT modifies this and implement the concept of = base delay, but suffers from late comers = advantage.
Both the above assume that one ACKs are returned to = the sender almost immediately (delay ACK adds some uncertanity here) = also one don=92t need to synchronize clocks.
Here I get = unsure about what to do with the received timestamps, I guess you can = compute a delta between sent and received timestamp but unless you have = exactly synchronized clocks in sender(s) and receiver(s), you will have = an unknown offset that can possibly also drift due to clock = skew.

, Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 10:31:17 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DE8DESESSMB205ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As regards to ACK-clocking What comes into mind is the work on TWFC http://www.slideshare.net/soohyunc/pfld-ne-t09 There should be full paper somewhere, don't find it though. ConEx: Yes, need to see it fly, might take a while, might take like forever= .... I put this as a future consideration. If we build something completely rece= iver based however we may end up with a headache in the future if ConEx fli= es as one will then anyway need to feed back packet loss/marks to the sende= r. /Ingemar From: Michael Welzl [mailto:michawe@ifi.uio.no] Sent: den 18 december 2012 11:06 To: Ingemar Johansson S Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) Hi, In line: On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: Hi Thanks Harald and Stefan OK, understand. The concept is then to do atleast the delay based rate adap= tation in the receiving end. The feedback the sender would then be either a= n absolute bitrate value or a relative increase/decrease value depending on= the algorithm. Change subject line as I deviate from the original thread a little. I believe this has been discussed before but repeat it. What about packet loss and ECN marks ? , bufferbloat will eventually go a= way, may take 5 years, 10 years, 20 years, don't know. I see it unlikely th= at a delay based algo will be able to tune it self such that it will effici= ently avoid packet drops, for instance a queue with the CoDel algorithm may= drop/mark packets even at very low queue depths because of its inherent de= sign. So the algo needs to be reactive to packet loss/marks (not a particul= arly controversial point) Indeed, I think we all agree on this? Here one can chose two paths for the packet loss/mark based rate adaptation= . Sender based rate adaptation: Requires feedback of packet drops/mark, the a= ccuracy depends on how the feedback is used. Receiver based rate adaptation: Feedback is only a rate command. It would seems like the receiver based algo is to prefer. There are however= at least two reasons to why a sender based algo is to prefer. 1) Ack-clocking, while TCP is not 100% perfect it has sofar avoided co= llapsing the internet completely. A big reason is ack-clocking meaning tha= t sudden increases of RTT is reacted to quite fast. At the same time that p= acket loss/marks are reported, it is also possible to report back successfu= lly received packets. Only a receiver based algo may be too slow in this re= spect. For the ack-clocking to work some timeliness of the feedback is requ= ired, RTCP may be too infrequent, inband feedback has been suggested as a s= olution earlier. I think that ACK clocking is not really an option for a rate based scheme w= ith reasonably limited feedback anyway. You say that ACK-clocking is a big = reason for TCP preventing the Internet from collapsing. I challenge that no= tion (I can hear the sound from the audience...). Yes it has been said agai= n and again that ACK-clocking has that seminal role, but show me some proof= . I don't remember seeing a paper which convincingly shows exactly that. We can, on the other hand, say that rate based congestion controls (as used= at the app layer in UDP based apps already) haven't yet driven the Interne= t into collapse... I would argue that the more important thing seems to be to have a timeout, = reacting on a reasonable RTT based time scale, and that can be achieved wit= h a rate based scheme. 2) ConEx: I believe that the future will require that applications exp= ose the congestion that they cause. A ConEx enabled endpoint is required to= state caused congestion, this means that the receiver must feedback the pa= cket loss/marks accurately, inband feedback may be to prefer here as it is = more timely than RTCP. I would suggest to standardize RMCAT extensions for ConEx later, when we se= e a need due to widespread ConEx deployment ;-) Both of the statements above implines that one may as well to the packet lo= ss/mark based rate adaptation the sender side. I have deliberately only considered communication between two peers in this= email. More advanced cases may of course add other concerns. /Ingemar Cheers, Michael From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 17 december 2012 20:37 To: Ingemar Johansson S Cc: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: Hi I believe that it can make sense to use a separate timestamp for congestion= control but I may need to read and understand some more. A few reflections= though. Unless I miss something, this is quite close to the TCP timestamps which ar= e used for congestion avoidance in TCP Vegas and LEDBAT. The problem in Vegas is that it is sensitive to congestion in the feedback = path, not shure though how much concern that should be. If we keep a model of computation-at-receiver, it's not a problem at all. LEDBAT modifies this and implement the concept of base delay, but suffers f= rom late comers advantage. Both the above assume that one ACKs are returned to the sender almost immed= iately (delay ACK adds some uncertanity here) also one don't need to synchr= onize clocks. Here I get unsure about what to do with the received timestamps, I guess yo= u can compute a delta between sent and received timestamp but unless you ha= ve exactly synchronized clocks in sender(s) and receiver(s), you will have = an unknown offset that can possibly also drift due to clock skew. As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue. I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence. --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DE8DESESSMB205ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

As regards to ACK-clockin= g

What comes into mind is t= he work on TWFC

http://www.slideshare.net/soohyunc/pfld-n= e-t09

There should be full pape= r somewhere, don’t find it though.  

 <= /p>

ConEx: Yes, need to see i= t fly, might take a while, might take like forever....

I put this as a future co= nsideration. If we build something completely receiver based however we may= end up with a headache in the future if ConEx flies as one will then anyway need to feed back packet loss/marks to the sender.

 <= /p>

/Ingemar

 <= /p>

From: Michael = Welzl [mailto:michawe@ifi.uio.no]
Sent: den 18 december 2012 11:06
To: Ingemar Johansson S
Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org
Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send times= tamps)

 

Hi,

 

In line:

 

 

On 18. des. 2012, at 10:50, Ingemar Johansson S wrot= e:



Hi

Thanks Harald and Stefan<= /span>

OK, understand. The conce= pt is then to do atleast the delay based rate adaptation in the receiving e= nd. The feedback the sender would then be either an absolute bitrate value or a relative increase/decrease value depending on the algor= ithm.

 

Change subject line as I = deviate from the original thread a little.

I believe this has been d= iscussed before but repeat it.

 

What about packet loss &n= bsp;and ECN marks ? ,  bufferbloat will eventually go away, may take 5= years, 10 years, 20 years, don’t know. I see it unlikely that a dela= y based algo will be able to tune it self such that it will efficiently avoi= d packet drops, for instance a queue with the CoDel algorithm may drop/mark= packets even at very low queue depths because of its inherent design. So t= he algo needs to be reactive to packet loss/marks (not a particularly controversial point)

 

Indeed, I think we all agree on this?

 

 

Here one can chose two pa= ths for the packet loss/mark based rate adaptation.

Sender based rate adaptat= ion: Requires feedback of packet drops/mark, the accuracy depends on how th= e feedback is used.

Receiver based rate adapt= ation: Feedback is only a rate command.<= o:p>

 

It would seems like the r= eceiver based algo is to prefer. There are however at least two reasons to = why a sender based algo is to prefer.

1)  &nb= sp;   Ack-clocking, while TCP is not 100% perfect it has sofar avoided collapsing the internet= completely.  A big reason is ack-clocking meaning that sudden increas= es of RTT is reacted to quite fast. At the same time that packet loss/marks= are reported, it is also possible to report back successfully received packets. Only a receiver based algo may = be too slow in this respect. For the ack-clocking to work some timeliness o= f the feedback is required, RTCP may be too infrequent, inband feedback has= been suggested as a solution earlier.

 

I think that ACK clocking is not really an option fo= r a rate based scheme with reasonably limited feedback anyway. You say that= ACK-clocking is a big reason for TCP preventing the Internet from collapsi= ng. I challenge that notion (I can hear the sound from the audience...). Yes it has been said again and again= that ACK-clocking has that seminal role, but show me some proof. I don't r= emember seeing a paper which convincingly shows exactly that.

 

We can, on the other hand, say that rate based conge= stion controls (as used at the app layer in UDP based apps already) haven't= yet driven the Internet into collapse...

 

I would argue that the more important thing seems to= be to have a timeout, reacting on a reasonable RTT based time scale, and t= hat can be achieved with a rate based scheme.

 <= /p>

 <= /p>

 



2)  &nb= sp;   ConEx: I believe that the future will require that applications expose the conges= tion that they cause. A ConEx enabled endpoint is required to state caused = congestion, this means that the receiver must feedback the packet loss/mark= s accurately, inband feedback may be to prefer here as it is more timely than RTCP.

 

I would suggest to standardize RMCAT extensions for = ConEx later, when we see a need due to widespread ConEx deployment   ;= -)

 



Both of the statements ab= ove implines that one may as well to the packet loss/mark based rate adapta= tion the sender side.<= /p>

 

I have deliberately only = considered communication between two peers in this email. More advanced cas= es may of course add other concerns.

 

/Ingemar

 

Cheers,

Michael

 

 



 

 

From: Harald Alvestrand [mailto:harald= @alvestrand.no] 
Sent: den 17 decem= ber 2012 20:37
To: Ingemar Johans= son S
Cc: rmcat@ietf.org
Subject: Re: [rmca= t] Send timestamps

 =

On 12/17/2012 03:45 PM, = Ingemar Johansson S wrote:

Hi

 

I believe that it can mak= e sense to use a separate timestamp for congestion control but I may need t= o read and understand some more. A few reflections though.

 

Unless I miss something, = this is quite close to the TCP timestamps which are used for congestion avo= idance in TCP Vegas and LEDBAT.

The problem in Vegas is t= hat it is sensitive to congestion in the feedback path, not shure though ho= w much concern that should be.

If we keep a model of co= mputation-at-receiver, it's not a problem at all.


LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers advantage= .

Both the above assume tha= t one ACKs are returned to the sender almost immediately (delay ACK adds so= me uncertanity here) also one don’t need to synchronize clocks.

Here I get unsure about w= hat to do with the received timestamps, I guess you can compute a delta bet= ween sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.


As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence.

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA06DE8DESESSMB205ericsso_-- From saverio.mascolo@gmail.com Tue Dec 18 02:39:50 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB021F884C for ; Tue, 18 Dec 2012 02:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnGRXC1V+I6w for ; Tue, 18 Dec 2012 02:39:48 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 40D2E21F854A for ; Tue, 18 Dec 2012 02:39:47 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id gj3so485885lbb.25 for ; Tue, 18 Dec 2012 02:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=B95P2oZfxyycfS4UbzSlauivy75Bf7Nf8o96gt94G30=; b=A3Hpbv7Lfz2ZCU+8M1jBWWHf6BdoXBjR7GvYwqP2xSgj28o0VsjAfwKQ2P+vnWC0yX po0UiKqaoA1+9aJcli6Bnc/6WhKc2WpYhGCmGAUFB87T7bskq6ctEw96+ZjZhcu7ZIMX CABwtk/ixkKvBf4jivnNbzjRbdHp6HtKU9mpYtAYnwvs1joxoWLzgP1FHx43P5sZBlUB Kl/gzJFhWkZlBM4pxORKuC9Po1QebxDCgF2a9A3db8P3IqN0mmIoW0r7IZ2MjMjgr+4P 05ZpQ5GG7eOD2npTX5IjCt/CmSAQBBPKGbDumdDtjATLCfd0h8cvMSiDgc+eA6GxbS1U 27vg== Received: by 10.152.104.240 with SMTP id gh16mr1368853lab.56.1355827186151; Tue, 18 Dec 2012 02:39:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.80.199 with HTTP; Tue, 18 Dec 2012 02:39:24 -0800 (PST) In-Reply-To: <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> From: Saverio Mascolo Date: Tue, 18 Dec 2012 11:39:24 +0100 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=f46d04088e11ceaf7104d11e1daf Cc: Ingemar Johansson S , "holmer@google.com" , "rmcat@ietf.org" , Harald Alvestrand Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 10:39:50 -0000 --f46d04088e11ceaf7104d11e1daf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable dear michael, we showed in a 1999 paper entitled "Congestion control in high-speed communication networks using the Smith principle": http://c3lab.poliba.it/images/3/3a/Automatica.pdf that ack clocking is equivalent to implement a Smith predictor, which is important to react fast. In other ways, ack clocking takes into account the in flight packets that can be a lot (=3Dbandwith times rtt). This need was also recognized in the second version of TFRC. Regards, Saverio On Tue, Dec 18, 2012 at 11:05 AM, Michael Welzl wrote: > Hi, > > In line: > > > On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: > > Hi**** > Thanks Harald and Stefan**** > OK, understand. The concept is then to do atleast the delay based rate > adaptation in the receiving end. The feedback the sender would then be > either an absolute bitrate value or a relative increase/decrease value > depending on the algorithm.**** > ** ** > Change subject line as I deviate from the original thread a little.**** > I believe this has been discussed before but repeat it.**** > ** ** > What about packet loss and ECN marks ? , bufferbloat will eventually go > away, may take 5 years, 10 years, 20 years, don=92t know. I see it unlike= ly > that a delay based algo will be able to tune it self such that it will > efficiently avoid packet drops, for instance a queue with the CoDel > algorithm may drop/mark packets even at very low queue depths because of > its inherent design. So the algo needs to be reactive to packet loss/mark= s > (not a particularly controversial point) > > > Indeed, I think we all agree on this? > > ** ** > Here one can chose two paths for the packet loss/mark based rate > adaptation.**** > Sender based rate adaptation: Requires feedback of packet drops/mark, the > accuracy depends on how the feedback is used.**** > Receiver based rate adaptation: Feedback is only a rate command. > > **** > ** ** > It would seems like the receiver based algo is to prefer. There are > however at least two reasons to why a sender based algo is to prefer.**** > 1) Ack-clocking, while TCP is not 100% perfect it has sofar avoided > collapsing the internet completely. A big reason is ack-clocking meaning > that sudden increases of RTT is reacted to quite fast. At the same time > that packet loss/marks are reported, it is also possible to report back > successfully received packets. Only a receiver based algo may be too slow > in this respect. For the ack-clocking to work some timeliness of the > feedback is required, RTCP may be too infrequent, inband feedback has bee= n > suggested as a solution earlier. > > > I think that ACK clocking is not really an option for a rate based scheme > with reasonably limited feedback anyway. You say that ACK-clocking is a b= ig > reason for TCP preventing the Internet from collapsing. I challenge that > notion (I can hear the sound from the audience...). Yes it has been said > again and again that ACK-clocking has that seminal role, but show me some > proof. I don't remember seeing a paper which convincingly shows exactly > that. > > We can, on the other hand, say that rate based congestion controls (as > used at the app layer in UDP based apps already) haven't yet driven the > Internet into collapse... > > I would argue that the more important thing seems to be to have a timeout= , > reacting on a reasonable RTT based time scale, and that can be achieved > with a rate based scheme. > > > **** > 2) ConEx: I believe that the future will require that applications > expose the congestion that they cause. A ConEx enabled endpoint is requir= ed > to state caused congestion, this means that the receiver must feedback th= e > packet loss/marks accurately, inband feedback may be to prefer here as it > is more timely than RTCP. > > > I would suggest to standardize RMCAT extensions for ConEx later, when we > see a need due to widespread ConEx deployment ;-) > > > **** > Both of the statements above implines that one may as well to the packet > loss/mark based rate adaptation the sender side. > > **** > ** ** > I have deliberately only considered communication between two peers in > this email. More advanced cases may of course add other concerns.**** > ** ** > /Ingemar**** > > > Cheers, > Michael > > > > ** ** > ** ** > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* den 17 december 2012 20:37 > *To:* Ingemar Johansson S > *Cc:* rmcat@ietf.org > *Subject:* Re: [rmcat] Send timestamps**** > ** ** > On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:**** > > Hi**** > **** > I believe that it can make sense to use a separate timestamp for > congestion control but I may need to read and understand some more. A few > reflections though.**** > **** > Unless I miss something, this is quite close to the TCP timestamps which > are used for congestion avoidance in TCP Vegas and LEDBAT.**** > The problem in Vegas is that it is sensitive to congestion in the feedbac= k > path, not shure though how much concern that should be.**** > > If we keep a model of computation-at-receiver, it's not a problem at all. > > **** > LEDBAT modifies this and implement the concept of base delay, but suffers > from late comers advantage.**** > Both the above assume that one ACKs are returned to the sender almost > immediately (delay ACK adds some uncertanity here) also one don=92t need = to > synchronize clocks.**** > Here I get unsure about what to do with the received timestamps, I guess > you can compute a delta between sent and received timestamp but unless yo= u > have exactly synchronized clocks in sender(s) and receiver(s), you will > have an unknown offset that can possibly also drift due to clock skew.***= * > > > As Stefan says - since we measure ~a moving average of difference between > the (receive timestamp - send timestamp) of successive packets, not an > absolute transit time, value, this is not likely to be an issue. > > I have a hard time imagining clock drift so severe that it will > significantly influence the deltas of packets that are sent less than a > second apart. Clock jumps (like leap seconds) may be a measurable, but > extremely transient, influence.**** > > > --=20 Saverio Mascolo, Full Professor Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it http://c3lab.poliba.it =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material i= n this message, and any attachments to the message, is strictly forbidden. --f46d04088e11ceaf7104d11e1daf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable dear michael,

we showed in a 1999 paper entitled "<= span style=3D"font-family:'Bitstream Vera Sans',Verdana,Times,sans-= serif">Congestion control in high-speed communication networks using the Sm= ith principle":


=
=A0=A0that ack clocking is equivalent to implement a Smith predi= ctor, which is =A0important to react fast. In other ways, ack clocking =A0t= akes into account the in flight packets that can be a lot (=3Dbandwith time= s rtt).

This need was also recognized in the second version of = TFRC.

Regards,
Saverio
On Tue, Dec 18, 2012 at 11:05 AM, Michael Welz= l <michawe@ifi.uio.no> wrote:
Hi,
=
In line:


On 18. des. 2012, at 10:50, Ingemar Johansson S wrote:

= Hi
Thanks Harald and Stefan
OK, understand. The concept is then to do atleast the delay based rate a= daptation in the receiving end. The feedback the sender would then be eithe= r an absolute bitrate value or a relative increase/decrease value depending= on the algorithm.
=A0
Change subject line as I deviate from the original thread a little.
I believe this has been discussed before but repeat it.
=A0
What about packet loss =A0and ECN marks ? ,=A0 bufferbloat will eventual= ly go away, may take 5 years, 10 years, 20 years, don=92t know. I see it un= likely that a delay based algo will be able to tune it self such that it wi= ll efficiently avoid packet drops, for instance a queue with the CoDel algo= rithm may drop/mark packets even at very low queue depths because of its in= herent design. So the algo needs to be reactive to packet loss/marks (not a= particularly controversial point)

Indeed, I think we all= agree on this?

= =A0
Here one can chose two paths for the packet loss/mark based rate adaptat= ion.
Sender based rate adaptation: Requires feedback of packet drops/mark, th= e accuracy depends on how the feedback is used.
Receiver based rate adaptation: Feedback is only a rate command.<= /div>
=
=A0
It would seems like the receiver based algo is to prefer. There are howe= ver at least two reasons to why a sender based algo is to prefer.=
1)=A0=A0=A0=A0=A0=A0Ack-clocking, while TCP is not 100% perfect it has sofar avoided collapsin= g the internet completely.=A0 A big reason is ack-clocking meaning that sud= den increases of RTT is reacted to quite fast. At the same time that packet= loss/marks are reported, it is also possible to report back successfully r= eceived packets. Only a receiver based algo may be too slow in this respect= . For the ack-clocking to work some timeliness of the feedback is required,= RTCP may be too infrequent, inband feedback has been suggested as a soluti= on earlier.

I think that ACK = clocking is not really an option for a rate based scheme with reasonably li= mited feedback anyway. You say that ACK-clocking is a big reason for TCP pr= eventing the Internet from collapsing. I challenge that notion (I can hear = the sound from the audience...). Yes it has been said again and again that = ACK-clocking has that seminal role, but show me some proof. I don't rem= ember seeing a paper which convincingly shows exactly that.

We can, on the other hand, say that rate based congesti= on controls (as used at the app layer in UDP based apps already) haven'= t yet driven the Internet into collapse...

I would= argue that the more important thing seems to be to have a timeout, reactin= g on a reasonable RTT based time scale, and that can be achieved with a rat= e based scheme.


2)=A0=A0=A0=A0=A0=A0ConEx: I believe that the future will require that applications expose the= congestion that they cause. A ConEx enabled endpoint is required to state = caused congestion, this means that the receiver must feedback the packet lo= ss/marks accurately, inband feedback may be to prefer here as it is more ti= mely than RTCP.

I would suggest to sta= ndardize RMCAT extensions for ConEx later, when we see a need due to widesp= read ConEx deployment =A0 ;-)

=
Both of the statements above implines that one may as well to the packet= loss/mark based rate adaptation the sender side.
=
=A0
I have deliberately only considered communication between two peers in t= his email. More advanced cases may of course add other concerns.<= /u>
=A0
/Ingemar

Cheers,
Mich= ael



= =A0
=A0
From:=A0Harald Alvestrand [mailto:harald@alvestrand.no]=A0
Sent:=A0den 17 december 2012 20:37
To:= =A0Ingemar Johansson S
Cc:=A0rmcat@ietf.org
Subject:=A0Re: [rmcat] Send timestamps
=A0
On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:
Hi
=A0
I believe that it can make sense to use a separate timestamp for congest= ion control but I may need to read and understand some more. A few reflecti= ons though.
=A0
Unless I miss something, this is quite close to the TCP timestamps which= are used for congestion avoidance in TCP Vegas and LEDBAT.
The problem in Vegas is that it is sensitive to congestion in the feedba= ck path, not shure though how much concern that should be.=
If we keep a model of computation-at-receiver, it's not a probl= em at all.

LEDBAT modifies this and implement the concept o= f base delay, but suffers from late comers advantage.<= /div>
Both the above assume that one ACKs are returned to the sender almost im= mediately (delay ACK adds some uncertanity here) also one don=92t need to s= ynchronize clocks.
Here I get unsure about what to do with the received timestamps, I guess= you can compute a delta between sent and received timestamp but unless you= have exactly synchronized clocks in sender(s) and receiver(s), you will ha= ve an unknown offset that can possibly also drift due to clock skew.=


As Stefan says - since we measure ~a moving average of differe= nce between the (receive timestamp - send timestamp) of successive packets,= not an absolute transit time, value, this is not likely to be an issue.
I have a hard time imagining clock drift so severe that it will signifi= cantly influence the deltas of packets that are sent less than a second apa= rt. Clock jumps (like leap seconds) may be a measurable, but extremely tran= sient, influence.





--
Saverio Mascolo, Full= Professor
Dipartimento di Elettrotecnica ed Elettronica
Politecnico = di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 596= 3410
emai= l:mascolo@poliba.it
=A0
http://c3lab.poliba.it


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0This message may contain confidenti= al and/or legally privileged information.
=A0 If you are not the intende= d recipient of the message, please destroy it.
=A0Any unauthorized disse= mination, distribution, or copying of the material in
=A0this message, and any attachments to the message, is strictly forbidden.=
--f46d04088e11ceaf7104d11e1daf-- From michawe@ifi.uio.no Tue Dec 18 02:45:33 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E004121F861B for ; Tue, 18 Dec 2012 02:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1pMbpoFEl5w for ; Tue, 18 Dec 2012 02:45:32 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 350A921F85BA for ; Tue, 18 Dec 2012 02:45:31 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Tkufx-0004to-0x; Tue, 18 Dec 2012 11:45:29 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Tkufw-0006Uu-2T; Tue, 18 Dec 2012 11:45:28 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0ECC0CC8-908A-4C6E-9030-671D6E14CBAD" From: Michael Welzl In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> Date: Tue, 18 Dec 2012 11:45:27 +0100 Message-Id: References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 12 sum msgs/h 6 total rcpts 924 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BD9BDFAD4F8D79F0D20B809DFFE511BD4D239762 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 322 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: "holmer@google.com" , Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 10:45:34 -0000 --Apple-Mail=_0ECC0CC8-908A-4C6E-9030-671D6E14CBAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18. des. 2012, at 11:31, Ingemar Johansson S wrote: > Hi > =20 > As regards to ACK-clocking > What comes into mind is the work on TWFC > http://www.slideshare.net/soohyunc/pfld-ne-t09 > There should be full paper somewhere, don=92t find it though. =20 Oh yes, you totally have a point there. The thesis surely has all the = details, it is at: http://tfwc.hackerslab.eu/docs (It seems that the pfldnet2009 page doesn't work anymore. I was on the = org. committee, and at the conference, so that paper is in fact on my = shelves somewhere... :-) ) Anyway, this isn't making the point that ACK clocking is "a big reason = for TCP preventing the Internet from collapsing". Sure it's a benefit, = and of course we can find situations where ACK-clocked protocols do = better, no doubt about that. > ConEx: Yes, need to see it fly, might take a while, might take like = forever.... > I put this as a future consideration. If we build something completely = receiver based however we may end up with a headache in the future if = ConEx flies as one will then anyway need to feed back packet loss/marks = to the sender. So this is where we differ: I don't believe that this would be a major = headache. The point of keeping stuff at the receiver is just to reduce = the feedback frequency. Inevitably, if you need the sender to have a = more up-to-date picture of things, you'll have to increase that = frequency, and possibly you'd also want to somehow extend the feedback = format for ConEx. I don't think that's going to be such a big deal to = retrofit, if it really becomes necessary. Cheers, Michael > =20 > /Ingemar > =20 > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: den 18 december 2012 11:06 > To: Ingemar Johansson S > Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org > Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send = timestamps) > =20 > Hi, > =20 > In line: > =20 > =20 > On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: >=20 >=20 > Hi > Thanks Harald and Stefan > OK, understand. The concept is then to do atleast the delay based rate = adaptation in the receiving end. The feedback the sender would then be = either an absolute bitrate value or a relative increase/decrease value = depending on the algorithm. > =20 > Change subject line as I deviate from the original thread a little. > I believe this has been discussed before but repeat it. > =20 > What about packet loss and ECN marks ? , bufferbloat will eventually = go away, may take 5 years, 10 years, 20 years, don=92t know. I see it = unlikely that a delay based algo will be able to tune it self such that = it will efficiently avoid packet drops, for instance a queue with the = CoDel algorithm may drop/mark packets even at very low queue depths = because of its inherent design. So the algo needs to be reactive to = packet loss/marks (not a particularly controversial point) > =20 > Indeed, I think we all agree on this? > =20 > =20 > Here one can chose two paths for the packet loss/mark based rate = adaptation. > Sender based rate adaptation: Requires feedback of packet drops/mark, = the accuracy depends on how the feedback is used. > Receiver based rate adaptation: Feedback is only a rate command. > =20 > It would seems like the receiver based algo is to prefer. There are = however at least two reasons to why a sender based algo is to prefer. > 1) Ack-clocking, while TCP is not 100% perfect it has sofar = avoided collapsing the internet completely. A big reason is = ack-clocking meaning that sudden increases of RTT is reacted to quite = fast. At the same time that packet loss/marks are reported, it is also = possible to report back successfully received packets. Only a receiver = based algo may be too slow in this respect. For the ack-clocking to work = some timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution earlier. > =20 > I think that ACK clocking is not really an option for a rate based = scheme with reasonably limited feedback anyway. You say that = ACK-clocking is a big reason for TCP preventing the Internet from = collapsing. I challenge that notion (I can hear the sound from the = audience...). Yes it has been said again and again that ACK-clocking has = that seminal role, but show me some proof. I don't remember seeing a = paper which convincingly shows exactly that. > =20 > We can, on the other hand, say that rate based congestion controls (as = used at the app layer in UDP based apps already) haven't yet driven the = Internet into collapse... > =20 > I would argue that the more important thing seems to be to have a = timeout, reacting on a reasonable RTT based time scale, and that can be = achieved with a rate based scheme. > =20 > =20 > =20 >=20 >=20 > 2) ConEx: I believe that the future will require that = applications expose the congestion that they cause. A ConEx enabled = endpoint is required to state caused congestion, this means that the = receiver must feedback the packet loss/marks accurately, inband feedback = may be to prefer here as it is more timely than RTCP. > =20 > I would suggest to standardize RMCAT extensions for ConEx later, when = we see a need due to widespread ConEx deployment ;-) > =20 >=20 >=20 > Both of the statements above implines that one may as well to the = packet loss/mark based rate adaptation the sender side. > =20 > I have deliberately only considered communication between two peers in = this email. More advanced cases may of course add other concerns. > =20 > /Ingemar > =20 > Cheers, > Michael > =20 > =20 >=20 >=20 > =20 > =20 > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: den 17 december 2012 20:37 > To: Ingemar Johansson S > Cc: rmcat@ietf.org > Subject: Re: [rmcat] Send timestamps > =20 > On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: > Hi > =20 > I believe that it can make sense to use a separate timestamp for = congestion control but I may need to read and understand some more. A = few reflections though. > =20 > Unless I miss something, this is quite close to the TCP timestamps = which are used for congestion avoidance in TCP Vegas and LEDBAT. > The problem in Vegas is that it is sensitive to congestion in the = feedback path, not shure though how much concern that should be. > If we keep a model of computation-at-receiver, it's not a problem at = all. >=20 >=20 > LEDBAT modifies this and implement the concept of base delay, but = suffers from late comers advantage. > Both the above assume that one ACKs are returned to the sender almost = immediately (delay ACK adds some uncertanity here) also one don=92t need = to synchronize clocks. > Here I get unsure about what to do with the received timestamps, I = guess you can compute a delta between sent and received timestamp but = unless you have exactly synchronized clocks in sender(s) and = receiver(s), you will have an unknown offset that can possibly also = drift due to clock skew. >=20 > As Stefan says - since we measure ~a moving average of difference = between the (receive timestamp - send timestamp) of successive packets, = not an absolute transit time, value, this is not likely to be an issue. >=20 > I have a hard time imagining clock drift so severe that it will = significantly influence the deltas of packets that are sent less than a = second apart. Clock jumps (like leap seconds) may be a measurable, but = extremely transient, influence. >=20 > =20 --Apple-Mail=_0ECC0CC8-908A-4C6E-9030-671D6E14CBAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 18. des. 2012, at 11:31, Ingemar = Johansson S wrote:

As = regards to ACK-clocking
What comes into mind is the work on = TWFC

Oh = yes, you totally have a point there. The thesis surely has all the = details, it is at:
(It seems that the pfldnet2009 page doesn't work anymore. I = was on the org. committee, and at the conference, so that paper is in = fact on my shelves somewhere...  :-)   = )

Anyway, this isn't making the point that ACK = clocking is "a big reason for TCP preventing the Internet from = collapsing". Sure it's a benefit, and of course we can find = situations where ACK-clocked protocols do better, no doubt about = that.


 ConEx: Yes, need to see it fly, might take a while, = might take like forever....
I put = this as a future consideration. If we build something completely = receiver based however we may end up with a headache in the future if = ConEx flies as one will then anyway need to feed back packet loss/marks = to the = sender.

So this = is where we differ: I don't believe that this would be a major headache. = The point of keeping stuff at the receiver is just to reduce the = feedback frequency. Inevitably, if you need the sender to have a more = up-to-date picture of things, you'll have to increase that frequency, = and possibly you'd also want to somehow extend the feedback format for = ConEx. I don't think that's going to be such a big deal to retrofit, if = it really becomes = necessary.

Cheers,
Michael


From: Michael Welzl = [mailto:michawe@ifi.uio.no] 
Sent: den 18 december 2012 = 11:06
To: Ingemar Johansson = S
Cc: Harald = Alvestrand; holmer@google.com; rmcat@ietf.org
Subject: Re: [rmcat] Sender or = Receiver based CC (was RE: Send = timestamps)
Hi,
 
In line:
 
 
On 18. des. 2012, at 10:50, Ingemar Johansson S = wrote:
OK, = understand. The concept is then to do atleast the delay based rate = adaptation in the receiving end. The feedback the sender would then be = either an absolute bitrate value or a relative increase/decrease value = depending on the algorithm.I = believe this has been discussed before but repeat it.
 
What about packet loss  and ECN marks ? ,  = bufferbloat will eventually go away, may take 5 years, 10 years, 20 = years, don=92t know. I see it unlikely that a delay based algo will be = able to tune it self such that it will efficiently avoid packet drops, = for instance a queue with the CoDel algorithm may drop/mark packets even = at very low queue depths because of its inherent design. So the algo = needs to be reactive to packet loss/marks (not a particularly = controversial point)Indeed, I think we all = agree on this?
Here = one can chose two paths for the packet loss/mark based rate = adaptation.
Receiver based rate adaptation: = Feedback is only a rate command.
 
It would seems like the receiver based algo is to = prefer. There are however at least two reasons to why a sender based = algo is to prefer.
 Ack-clocking, while TCP is not 100% perfect it has = sofar avoided collapsing the internet completely.  A big reason is = ack-clocking meaning that sudden increases of RTT is reacted to quite = fast. At the same time that packet loss/marks are reported, it is also = possible to report back successfully received packets. Only a receiver = based algo may be too slow in this respect. For the ack-clocking to work = some timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution earlier. 
I think that ACK clocking is not really an option for a = rate based scheme with reasonably limited feedback anyway. You say that = ACK-clocking is a big reason for TCP preventing the Internet from = collapsing. I challenge that notion (I can hear the sound from the = audience...). Yes it has been said again and again that ACK-clocking has = that seminal role, but show me some proof. I don't remember seeing a = paper which convincingly shows exactly = that.
We can, on the other = hand, say that rate based congestion controls (as used at the app layer = in UDP based apps already) haven't yet driven the Internet into = collapse...
I would argue that the = more important thing seems to be to have a timeout, reacting on a = reasonable RTT based time scale, and that can be achieved with a rate = based scheme.
 ConEx: I believe that the future will require that = applications expose the congestion that they cause. A ConEx enabled = endpoint is required to state caused congestion, this means that the = receiver must feedback the packet loss/marks accurately, inband feedback = may be to prefer here as it is more timely than RTCP.
 
I would = suggest to standardize RMCAT extensions for ConEx later, when we see a = need due to widespread ConEx deployment   = ;-)
Both = of the statements above implines that one may as well to the packet = loss/mark based rate adaptation the sender side.
 
I have deliberately only considered communication = between two peers in this email. More advanced cases may of course add = other concerns. 
Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: den 17 december 2012 = 20:37
To: Ingemar Johansson = S
Cc: rmcat@ietf.org
Subject: Re: [rmcat] Send = timestampsOn 12/17/2012 03:45 PM, Ingemar Johansson S = wrote:
I = believe that it can make sense to use a separate timestamp for = congestion control but I may need to read and understand some more. A = few reflections though.The = problem in Vegas is that it is sensitive to congestion in the feedback = path, not shure though how much concern that should be.If we keep a model of = computation-at-receiver, it's not a problem at = all.


LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers = advantage.Both = the above assume that one ACKs are returned to the sender almost = immediately (delay ACK adds some uncertanity here) also one don=92t need = to synchronize clocks.Here = I get unsure about what to do with the received timestamps, I guess you = can compute a delta between sent and received timestamp but unless you = have exactly synchronized clocks in sender(s) and receiver(s), you will = have an unknown offset that can possibly also drift due to clock = skew.
As Stefan says - since we = measure ~a moving average of difference between the (receive timestamp - = send timestamp) of successive packets, not an absolute transit time, = value, this is not likely to be an issue.

I have a hard time = imagining clock drift so severe that it will significantly influence the = deltas of packets that are sent less than a second apart. Clock jumps = (like leap seconds) may be a measurable, but extremely transient, = influence.

In-Reply-To: Date: Tue, 18 Dec 2012 11:50:58 +0100 Message-Id: <1B27E876-1F3B-42B7-A818-442715A260DE@ifi.uio.no> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> To: Saverio Mascolo X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 16 msgs/h 6 sum rcpts/h 17 sum msgs/h 7 total rcpts 929 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C7C1B59192976814D26B4B2F8D979B64B1CAA54E X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 323 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: Ingemar Johansson S , "holmer@google.com" , "rmcat@ietf.org" , Harald Alvestrand Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 10:51:04 -0000 --Apple-Mail=_6E697D57-D637-46D8-9F79-A444ACEC9155 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Saverio, "important to react fast" !=3D "prevent the Internet from collapsing". Of course I agree that ACK clocking makes sense, and I understand that = it gives you tight control of the number of packets in flight, which can = make your control much better. What I'm challenging is the notion that = this is an absolute necessity, or else the Internet would melt. Would it = really, if we'd all use e.g. TFRC instead of TCP? (argh, I hate to = imagine that particular scenario :-) TFRC is perhaps not an ideal = example here...) Anyway, I guess that, for reasonable operation in the public Internet, = rate-based control with per-RTT feedback and timeouts based on that, you = can do well enough under most circumstances. That's all I'm saying. Cheers, Michael On 18. des. 2012, at 11:39, Saverio Mascolo wrote: > dear michael, >=20 > we showed in a 1999 paper entitled "Congestion control in high-speed = communication networks using the Smith principle": >=20 > http://c3lab.poliba.it/images/3/3a/Automatica.pdf >=20 > that ack clocking is equivalent to implement a Smith predictor, = which is important to react fast. In other ways, ack clocking takes = into account the in flight packets that can be a lot (=3Dbandwith times = rtt). >=20 > This need was also recognized in the second version of TFRC. >=20 > Regards, > Saverio >=20 > On Tue, Dec 18, 2012 at 11:05 AM, Michael Welzl = wrote: > Hi, >=20 > In line: >=20 >=20 > On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: >=20 >> Hi >> Thanks Harald and Stefan >> OK, understand. The concept is then to do atleast the delay based = rate adaptation in the receiving end. The feedback the sender would then = be either an absolute bitrate value or a relative increase/decrease = value depending on the algorithm. >> =20 >> Change subject line as I deviate from the original thread a little. >> I believe this has been discussed before but repeat it. >> =20 >> What about packet loss and ECN marks ? , bufferbloat will = eventually go away, may take 5 years, 10 years, 20 years, don=92t know. = I see it unlikely that a delay based algo will be able to tune it self = such that it will efficiently avoid packet drops, for instance a queue = with the CoDel algorithm may drop/mark packets even at very low queue = depths because of its inherent design. So the algo needs to be reactive = to packet loss/marks (not a particularly controversial point) >=20 > Indeed, I think we all agree on this? >=20 >> =20 >> Here one can chose two paths for the packet loss/mark based rate = adaptation. >> Sender based rate adaptation: Requires feedback of packet drops/mark, = the accuracy depends on how the feedback is used. >> Receiver based rate adaptation: Feedback is only a rate command. >> =20 >> It would seems like the receiver based algo is to prefer. There are = however at least two reasons to why a sender based algo is to prefer. >> 1) Ack-clocking, while TCP is not 100% perfect it has sofar = avoided collapsing the internet completely. A big reason is = ack-clocking meaning that sudden increases of RTT is reacted to quite = fast. At the same time that packet loss/marks are reported, it is also = possible to report back successfully received packets. Only a receiver = based algo may be too slow in this respect. For the ack-clocking to work = some timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution earlier. >=20 > I think that ACK clocking is not really an option for a rate based = scheme with reasonably limited feedback anyway. You say that = ACK-clocking is a big reason for TCP preventing the Internet from = collapsing. I challenge that notion (I can hear the sound from the = audience...). Yes it has been said again and again that ACK-clocking has = that seminal role, but show me some proof. I don't remember seeing a = paper which convincingly shows exactly that. >=20 > We can, on the other hand, say that rate based congestion controls (as = used at the app layer in UDP based apps already) haven't yet driven the = Internet into collapse... >=20 > I would argue that the more important thing seems to be to have a = timeout, reacting on a reasonable RTT based time scale, and that can be = achieved with a rate based scheme. >=20 >=20 >> 2) ConEx: I believe that the future will require that = applications expose the congestion that they cause. A ConEx enabled = endpoint is required to state caused congestion, this means that the = receiver must feedback the packet loss/marks accurately, inband feedback = may be to prefer here as it is more timely than RTCP. >=20 > I would suggest to standardize RMCAT extensions for ConEx later, when = we see a need due to widespread ConEx deployment ;-) >=20 >=20 >> Both of the statements above implines that one may as well to the = packet loss/mark based rate adaptation the sender side. >> =20 >> I have deliberately only considered communication between two peers = in this email. More advanced cases may of course add other concerns. >> =20 >> /Ingemar >=20 > Cheers, > Michael >=20 >=20 >=20 >> =20 >> =20 >> From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 >> Sent: den 17 december 2012 20:37 >> To: Ingemar Johansson S >> Cc: rmcat@ietf.org >> Subject: Re: [rmcat] Send timestamps >> =20 >> On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: >> Hi >> =20 >> I believe that it can make sense to use a separate timestamp for = congestion control but I may need to read and understand some more. A = few reflections though. >> =20 >> Unless I miss something, this is quite close to the TCP timestamps = which are used for congestion avoidance in TCP Vegas and LEDBAT. >> The problem in Vegas is that it is sensitive to congestion in the = feedback path, not shure though how much concern that should be. >> If we keep a model of computation-at-receiver, it's not a problem at = all. >>=20 >> LEDBAT modifies this and implement the concept of base delay, but = suffers from late comers advantage. >> Both the above assume that one ACKs are returned to the sender almost = immediately (delay ACK adds some uncertanity here) also one don=92t need = to synchronize clocks. >> Here I get unsure about what to do with the received timestamps, I = guess you can compute a delta between sent and received timestamp but = unless you have exactly synchronized clocks in sender(s) and = receiver(s), you will have an unknown offset that can possibly also = drift due to clock skew. >>=20 >> As Stefan says - since we measure ~a moving average of difference = between the (receive timestamp - send timestamp) of successive packets, = not an absolute transit time, value, this is not likely to be an issue. >>=20 >> I have a hard time imagining clock drift so severe that it will = significantly influence the deltas of packets that are sent less than a = second apart. Clock jumps (like leap seconds) may be a measurable, but = extremely transient, influence. >>=20 >=20 >=20 >=20 >=20 > --=20 > Saverio Mascolo, Full Professor > Dipartimento di Elettrotecnica ed Elettronica > Politecnico di Bari > Via Orabona 4, 70125 Bari Italy > Tel. +39 080 5963621 > Fax. +39 080 5963410 > email:mascolo@poliba.it > =20 > http://c3lab.poliba.it >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This message may contain confidential and/or legally privileged = information. > If you are not the intended recipient of the message, please destroy = it. > Any unauthorized dissemination, distribution, or copying of the = material in > this message, and any attachments to the message, is strictly = forbidden. --Apple-Mail=_6E697D57-D637-46D8-9F79-A444ACEC9155 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Saverio,

"important to react fast" !=3D "prevent the = Internet from collapsing".

Of course I agree = that ACK clocking makes sense, and I understand that it gives you tight = control of the number of packets in flight, which can make your control = much better. What I'm challenging is the notion that this is an absolute = necessity, or else the Internet would melt. Would it really, if we'd all = use e.g. TFRC instead of TCP?  (argh, I hate to imagine that = particular scenario  :-)   TFRC is perhaps not an ideal = example here...)

Anyway, I guess that, for = reasonable operation in the public Internet, rate-based control with = per-RTT feedback and timeouts based on that, you can do well enough = under most circumstances. That's all I'm = saying.

Cheers,
Michael

<= /div>

On 18. des. 2012, at 11:39, Saverio Mascolo = wrote:

dear michael,

we showed in a 1999 paper = entitled "Congestion control in high-speed = communication networks using the Smith principle":


 &nbs= p;that ack clocking is equivalent to implement a Smith predictor, which = is  important to react fast. In other ways, ack clocking =  takes into account the in flight packets that can be a lot = (=3Dbandwith times rtt).

This need was also recognized in the second version = of = TFRC.

Regards,
Saverio
<= br>
On Tue, Dec 18, 2012 at 11:05 AM, Michael = Welzl <michawe@ifi.uio.no> wrote:
Hi,

In = line:


On 18. des. 2012, at 10:50, Ingemar Johansson S = wrote:

Hi
Thanks Harald and Stefan
OK, understand. The concept is then to do atleast the delay based = rate adaptation in the receiving end. The feedback the sender would then = be either an absolute bitrate value or a relative increase/decrease = value depending on the algorithm.
 
Change subject line as I deviate from the original thread a = little.
I believe this has been discussed before but repeat = it.
 
What about packet loss  and ECN marks ? ,  bufferbloat will = eventually go away, may take 5 years, 10 years, 20 years, don=92t know. = I see it unlikely that a delay based algo will be able to tune it self = such that it will efficiently avoid packet drops, for instance a queue = with the CoDel algorithm may drop/mark packets even at very low queue = depths because of its inherent design. So the algo needs to be reactive = to packet loss/marks (not a particularly controversial = point)

Indeed, I think we = all agree on this?

 
Here one can chose two paths for the packet loss/mark based rate = adaptation.
Sender based rate adaptation: Requires feedback of packet drops/mark, = the accuracy depends on how the feedback is = used.
Receiver based rate adaptation: Feedback is only a rate = command.
 
It would seems like the receiver based algo is to prefer. There are = however at least two reasons to why a sender based algo is to = prefer.
1)      Ack-clocking, while TCP is not 100% perfect it has sofar avoided = collapsing the internet completely.  A big reason is ack-clocking = meaning that sudden increases of RTT is reacted to quite fast. At the = same time that packet loss/marks are reported, it is also possible to = report back successfully received packets. Only a receiver based algo = may be too slow in this respect. For the ack-clocking to work some = timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution earlier.

I think that = ACK clocking is not really an option for a rate based scheme with = reasonably limited feedback anyway. You say that ACK-clocking is a big = reason for TCP preventing the Internet from collapsing. I challenge that = notion (I can hear the sound from the audience...). Yes it has been said = again and again that ACK-clocking has that seminal role, but show me = some proof. I don't remember seeing a paper which convincingly shows = exactly that.

We can, on the other hand, say that rate based = congestion controls (as used at the app layer in UDP based apps already) = haven't yet driven the Internet into = collapse...

I would argue that the more = important thing seems to be to have a timeout, reacting on a reasonable = RTT based time scale, and that can be achieved with a rate based = scheme.


2)      ConEx: I believe that the future will require that applications = expose the congestion that they cause. A ConEx enabled endpoint is = required to state caused congestion, this means that the receiver must = feedback the packet loss/marks accurately, inband feedback may be to = prefer here as it is more timely than RTCP.

I would suggest to = standardize RMCAT extensions for ConEx later, when we see a need due to = widespread ConEx deployment   ;-)


Both of the statements above implines that one may as well to the = packet loss/mark based rate adaptation the sender side.
 
I have deliberately only considered communication between two peers = in this email. More advanced cases may of course add other = concerns.
 
/Ingemar
=

Cheers,
Mic= hael



 
 
Fr= om: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: den 17 december 2012 = 20:37
To: Ingemar Johansson = S
Cc: rmcat@ietf.org
Subject: Re: [rmcat] Send = timestamps
 
On 12/17/2012 = 03:45 PM, Ingemar Johansson S wrote:
Hi
 
I believe that it can make sense to use a separate timestamp for = congestion control but I may need to read and understand some more. A = few reflections though.
 
Unless I miss something, this is quite close to the TCP timestamps = which are used for congestion avoidance in TCP Vegas and = LEDBAT.
The problem in Vegas is that it is sensitive to congestion in the = feedback path, not shure though how much concern that should = be.
If we keep a = model of computation-at-receiver, it's not a problem at all.

LEDBAT modifies this and implement the concept of base delay, but = suffers from late comers advantage.
Both the above assume that one ACKs are returned to the sender almost = immediately (delay ACK adds some uncertanity here) also one don=92t need = to synchronize clocks.
Here I get unsure about what to do with the received timestamps, I = guess you can compute a delta between sent and received timestamp but = unless you have exactly synchronized clocks in sender(s) and = receiver(s), you will have an unknown offset that can possibly also = drift due to clock skew.


As Stefan says = - since we measure ~a moving average of difference between the (receive = timestamp - send timestamp) of successive packets, not an absolute = transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will = significantly influence the deltas of packets that are sent less than a = second apart. Clock jumps (like leap seconds) may be a measurable, but = extremely transient, influence.

=




--
Saverio Mascolo, = Full Professor
Dipartimento di Elettrotecnica ed = Elettronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 = 5963410
email:mascolo@poliba.it
 
http://c3lab.poliba.it


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 This message may contain = confidential and/or legally privileged information.
  If you are = not the intended recipient of the message, please destroy = it.
 Any unauthorized dissemination, distribution, or copying of = the material in
 this message, and any attachments to the message, is strictly = forbidden.

= --Apple-Mail=_6E697D57-D637-46D8-9F79-A444ACEC9155-- From mramalho@cisco.com Tue Dec 18 07:19:22 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075B421F8866 for ; Tue, 18 Dec 2012 07:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8C7tWvjmnxP for ; Tue, 18 Dec 2012 07:19:19 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80821F8A2F for ; Tue, 18 Dec 2012 07:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14763; q=dns/txt; s=iport; t=1355843959; x=1357053559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ld4Bw6C2TmCNA3hFOulal1r+hvpX/L2JfRg71DQM2WM=; b=SwT2nMw1ZVmU0F7B+FO/dy6Cvn2iuA8Qcchln4mxCkRVDGrNgVvzOZRf U+0oNOShSwzOsr0hfJe6kXvJToQ+1ST8UUGMPQgJUMWjwI5tcq4kAo2xB Yayj3+ogFie4WLiOdwsljTz+wb584ZJcVcJIPDrCPx/7liXxDp9PLyjLT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABGJ0FCtJXHB/2dsb2JhbABEgkm7XRZzgh4BAQEELUwQAgEIEQQBAQsdBzIUCQgCBAENBQiIC6glkEWMSQuDV2EDplKCc4FtNQ X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208,217";a="153979661" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 18 Dec 2012 15:18:56 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBIFIurr008570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 15:18:56 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.15]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 09:18:56 -0600 From: "Michael Ramalho (mramalho)" To: Harald Alvestrand , Ingemar Johansson S Thread-Topic: [rmcat] Send timestamps Thread-Index: AQFp1qsmc/iz7p8QDa1Dm2vi5bzEBZjj9aEAgAFNK4CAAAGdgIAAPSoAgABRVICAAONqkA== Date: Tue, 18 Dec 2012 15:18:55 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> <50CF7445.60907@alvestrand.no> In-Reply-To: <50CF7445.60907@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.89] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B9103154A8DECxmbrcdx12ciscoc_" MIME-Version: 1.0 Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:19:22 -0000 --_000_D21571530BF9644D9A443D6BD95B9103154A8DECxmbrcdx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Re: "As Stefan says - since we measure ~a moving average of difference betw= een the (receive timestamp - send timestamp) of successive packets, not an = absolute transit time, value, this is not likely to be an issue." I think this discussion is heading in the right direction ... that is, an a= bsolute, transport-not-media-capture-related ability to generate one-way de= lay DIFFERENCES ... without a need to keep track of absolute time (e.g., NT= P) or detailed knowledge about the capture time. We are interested in conge= stion measures here, not play out information in this discussion. As one may recall, the discussion started from a premise of inter-arrival t= ime differences ... which I didn't think was wise or appropriate (even thou= gh a particular vendor happened to design a control based on inter-arrival = time). I preferred a mechanism to measure the relative one-way time delay d= ifferences from which an inter-arrival time measure could be calculated (if= you wanted one). The issue I have with the above is that I also think it is silly to compute= a moving average of the differences based on my original email on this thr= ead (knowing the delay histogram is one sided and that we can EXPECT outlie= rs). If there was non-linear filtering PRIOR TO a moving average metric ...= then I would be happier ... but that also doesn't need to be specified in = what we are trying to do with the timestamps on the wire. I can do that non= -linear filtering with the timestamps as we are proposing in this thread. Regards, Michael Ramalho, Ph.D. PS - Harold, until we specify what we need, a close approximation is to tak= e the RTP timestamp of the FIRST packet of a multi-packet video frame. You = will still have the OS and processing delay in there ... but it is better t= han nothing. From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of H= arald Alvestrand Sent: Monday, December 17, 2012 2:37 PM To: Ingemar Johansson S Cc: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: Hi I believe that it can make sense to use a separate timestamp for congestion= control but I may need to read and understand some more. A few reflections= though. Unless I miss something, this is quite close to the TCP timestamps which ar= e used for congestion avoidance in TCP Vegas and LEDBAT. The problem in Vegas is that it is sensitive to congestion in the feedback = path, not shure though how much concern that should be. If we keep a model of computation-at-receiver, it's not a problem at all. LEDBAT modifies this and implement the concept of base delay, but suffers f= rom late comers advantage. Both the above assume that one ACKs are returned to the sender almost immed= iately (delay ACK adds some uncertanity here) also one don't need to synchr= onize clocks. Here I get unsure about what to do with the received timestamps, I guess yo= u can compute a delta between sent and received timestamp but unless you ha= ve exactly synchronized clocks in sender(s) and receiver(s), you will have = an unknown offset that can possibly also drift due to clock skew. As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue. I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence. --_000_D21571530BF9644D9A443D6BD95B9103154A8DECxmbrcdx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 <= /p>

Re: “As Stef= an says - since we measure ~a moving average of difference between the (rec= eive timestamp - send timestamp) of successive packets, not an absolute transit time, value, this is not likely to be an issue.”

 <= /p>

I think this discussion i= s heading in the right direction … that is, an absolute, transport-no= t-media-capture-related ability to generate one-way delay DIFFERENCES … without a need to keep track of absolute time (e.g., NTP) or detai= led knowledge about the capture time. We are interested in congestion measu= res here, not play out information in this discussion.

 <= /p>

As one may recall, the di= scussion started from a premise of inter-arrival time differences … w= hich I didn’t think was wise or appropriate (even though a particular vendor happened to design a control based on inter-arrival time). I prefer= red a mechanism to measure the relative one-way time delay differences from= which an inter-arrival time measure could be calculated (if you wanted one= ).

 <= /p>

The issue I have with the= above is that I also think it is silly to compute a moving average of the = differences based on my original email on this thread (knowing the delay histogram is one sided and that we can EXPECT outliers). If ther= e was non-linear filtering PRIOR TO a moving average metric … then I = would be happier … but that also doesn’t need to be specified i= n what we are trying to do with the timestamps on the wire. I can do that non-linear filtering with the timestamps as we are= proposing in this thread.

 <= /p>

Regards,

 <= /p>

Michael Ramalho, Ph.D.

 <= /p>

PS – Harold, until = we specify what we need, a close approximation is to take the RTP timestamp= of the FIRST packet of a multi-packet video frame. You will still have the OS and processing delay in there … but it is better than no= thing.

 <= /p>

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf= .org] On Behalf Of Harald Alvestrand
Sent: Monday, December 17, 2012 2:37 PM
To: Ingemar Johansson S
Cc: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:

Hi

 <= /p>

I believe that it can mak= e sense to use a separate timestamp for congestion control but I may need t= o read and understand some more. A few reflections though.

 <= /p>

Unless I miss something, = this is quite close to the TCP timestamps which are used for congestion avo= idance in TCP Vegas and LEDBAT.

The problem in Vegas is t= hat it is sensitive to congestion in the feedback path, not shure though ho= w much concern that should be.

If we keep a model of computation-at-receiver, it's = not a problem at all.

LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers advantage= .

Both the above assume tha= t one ACKs are returned to the sender almost immediately (delay ACK adds so= me uncertanity here) also one don’t need to synchronize clocks.

Here I get unsure about w= hat to do with the received timestamps, I guess you can compute a delta bet= ween sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.


As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence.

--_000_D21571530BF9644D9A443D6BD95B9103154A8DECxmbrcdx12ciscoc_-- From ingemar.s.johansson@ericsson.com Wed Dec 19 05:21:06 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C437921F8B0E for ; Wed, 19 Dec 2012 05:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH52+dUQeb0r for ; Wed, 19 Dec 2012 05:21:01 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0970121F8B2B for ; Wed, 19 Dec 2012 05:21:00 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-9a-50d1bf3b50c1 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.76.10459.B3FB1D05; Wed, 19 Dec 2012 14:20:59 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.209]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 14:20:59 +0100 From: Ingemar Johansson S To: Michael Welzl Thread-Topic: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) Thread-Index: AQHN3QdC0ry1BsgEGkW/frId/wvZe5geWIPQ///2P4CAAczX0A== Date: Wed, 19 Dec 2012 13:20:58 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA06EA7FESESSMB205ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvja71/osBBo2fDS2O9XWxWVzdf47F 4sfZnawWq29+YHNg8bgy4Qqrx4JNpR5Llvxk8li9+iFzAEsUl01Kak5mWWqRvl0CV8bSa3OY C1bNZarY2HmduYFxy3fGLkZODgkBE4mevxPYIWwxiQv31rN1MXJxCAkcYpSY/nYRlLOEUeLk rY+sIFVsAjYSKw9BdIsIqEmcWL6aDcRmFqiSmHH5CliNsIC3xN6ZB1kganwk+taeYYOwnSQ2 f+xgBrFZBFQl5l/bDlTDwcELVH/igBTErq+MEv8mbwWbzylgJ7Fw0yKwmYwCshL3v99jgdgl LnHryXwmiKsFJJbsOc8MYYtKvHz8jxXCVpT4+GofI0R9vsTh83/AvuQVEJQ4OfMJywRG0VlI Rs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxciem5iZk15uuIkRGH8Ht/zW 3cF46pzIIUZpDhYlcd4w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi9rDI+nd99lkFr 9/YNAmF96duDdJOfHbz6w9ah71Uoh3Z9aOcrjeN2Xn9kTNIsxXM3+ZgcnfxoXuff8J+HrnfO SLL3Xf3Ny/VcnTTrw/vLCgyu9FRPKEgXZ105Y1utqM1xL9+MgC6e+fmPbFX37i/LbWl5nep8 9s5P7y+Xfb/3X25bGB94bbMSS3FGoqEWc1FxIgDYnnAqjQIAAA== Cc: "holmer@google.com" , Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:21:06 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06EA7FESESSMB205ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yes, you are probably right, I should probably have avoided the term "colla= pse", Question is if ack-clocking provides a benefit large enough to motivate the= higher feedback rate (even though the feedback can perhaps be inband?). One possible use case is wireless access such as LTE uplink where congestio= n can build up quite quickly, don't have any proof that ack-clocking can im= prove things here however. /Ingemar From: Michael Welzl [mailto:michawe@ifi.uio.no] Sent: den 18 december 2012 11:45 To: Ingemar Johansson S Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) On 18. des. 2012, at 11:31, Ingemar Johansson S wrote: Hi As regards to ACK-clocking What comes into mind is the work on TWFC http://www.slideshare.net/soohyunc/pfld-ne-t09 There should be full paper somewhere, don't find it though. Oh yes, you totally have a point there. The thesis surely has all the detai= ls, it is at: http://tfwc.hackerslab.eu/docs (It seems that the pfldnet2009 page doesn't work anymore. I was on the org.= committee, and at the conference, so that paper is in fact on my shelves s= omewhere... :-) ) Anyway, this isn't making the point that ACK clocking is "a big reason for = TCP preventing the Internet from collapsing". Sure it's a benefit, and of c= ourse we can find situations where ACK-clocked protocols do better, no doub= t about that. ConEx: Yes, need to see it fly, might take a while, might take like foreve= r.... I put this as a future consideration. If we build something completely rece= iver based however we may end up with a headache in the future if ConEx fli= es as one will then anyway need to feed back packet loss/marks to the sende= r. So this is where we differ: I don't believe that this would be a major head= ache. The point of keeping stuff at the receiver is just to reduce the feed= back frequency. Inevitably, if you need the sender to have a more up-to-dat= e picture of things, you'll have to increase that frequency, and possibly y= ou'd also want to somehow extend the feedback format for ConEx. I don't thi= nk that's going to be such a big deal to retrofit, if it really becomes nec= essary. Cheers, Michael /Ingemar From: Michael Welzl [mailto:michawe@ifi.uio.no] Sent: den 18 december 2012 11:06 To: Ingemar Johansson S Cc: Harald Alvestrand; holmer@google.com; rmcat@i= etf.org Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) Hi, In line: On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: Hi Thanks Harald and Stefan OK, understand. The concept is then to do atleast the delay based rate adap= tation in the receiving end. The feedback the sender would then be either a= n absolute bitrate value or a relative increase/decrease value depending on= the algorithm. Change subject line as I deviate from the original thread a little. I believe this has been discussed before but repeat it. What about packet loss and ECN marks ? , bufferbloat will eventually go a= way, may take 5 years, 10 years, 20 years, don't know. I see it unlikely th= at a delay based algo will be able to tune it self such that it will effici= ently avoid packet drops, for instance a queue with the CoDel algorithm may= drop/mark packets even at very low queue depths because of its inherent de= sign. So the algo needs to be reactive to packet loss/marks (not a particul= arly controversial point) Indeed, I think we all agree on this? Here one can chose two paths for the packet loss/mark based rate adaptation= . Sender based rate adaptation: Requires feedback of packet drops/mark, the a= ccuracy depends on how the feedback is used. Receiver based rate adaptation: Feedback is only a rate command. It would seems like the receiver based algo is to prefer. There are however= at least two reasons to why a sender based algo is to prefer. 1) Ack-clocking, while TCP is not 100% perfect it has sofar avoided co= llapsing the internet completely. A big reason is ack-clocking meaning tha= t sudden increases of RTT is reacted to quite fast. At the same time that p= acket loss/marks are reported, it is also possible to report back successfu= lly received packets. Only a receiver based algo may be too slow in this re= spect. For the ack-clocking to work some timeliness of the feedback is requ= ired, RTCP may be too infrequent, inband feedback has been suggested as a s= olution earlier. I think that ACK clocking is not really an option for a rate based scheme w= ith reasonably limited feedback anyway. You say that ACK-clocking is a big = reason for TCP preventing the Internet from collapsing. I challenge that no= tion (I can hear the sound from the audience...). Yes it has been said agai= n and again that ACK-clocking has that seminal role, but show me some proof= . I don't remember seeing a paper which convincingly shows exactly that. We can, on the other hand, say that rate based congestion controls (as used= at the app layer in UDP based apps already) haven't yet driven the Interne= t into collapse... I would argue that the more important thing seems to be to have a timeout, = reacting on a reasonable RTT based time scale, and that can be achieved wit= h a rate based scheme. 2) ConEx: I believe that the future will require that applications exp= ose the congestion that they cause. A ConEx enabled endpoint is required to= state caused congestion, this means that the receiver must feedback the pa= cket loss/marks accurately, inband feedback may be to prefer here as it is = more timely than RTCP. I would suggest to standardize RMCAT extensions for ConEx later, when we se= e a need due to widespread ConEx deployment ;-) Both of the statements above implines that one may as well to the packet lo= ss/mark based rate adaptation the sender side. I have deliberately only considered communication between two peers in this= email. More advanced cases may of course add other concerns. /Ingemar Cheers, Michael From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 17 december 2012 20:37 To: Ingemar Johansson S Cc: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: Hi I believe that it can make sense to use a separate timestamp for congestion= control but I may need to read and understand some more. A few reflections= though. Unless I miss something, this is quite close to the TCP timestamps which ar= e used for congestion avoidance in TCP Vegas and LEDBAT. The problem in Vegas is that it is sensitive to congestion in the feedback = path, not shure though how much concern that should be. If we keep a model of computation-at-receiver, it's not a problem at all. LEDBAT modifies this and implement the concept of base delay, but suffers f= rom late comers advantage. Both the above assume that one ACKs are returned to the sender almost immed= iately (delay ACK adds some uncertanity here) also one don't need to synchr= onize clocks. Here I get unsure about what to do with the received timestamps, I guess yo= u can compute a delta between sent and received timestamp but unless you ha= ve exactly synchronized clocks in sender(s) and receiver(s), you will have = an unknown offset that can possibly also drift due to clock skew. As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue. I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence. --_000_81564C0D7D4D2A4B9A86C8C7404A13DA06EA7FESESSMB205ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

Yes, you are probably rig= ht, I should probably have avoided the term “collapse”,

Question is if ack-clocki= ng provides a benefit large enough to motivate the higher feedback rate (ev= en though the feedback can perhaps be inband?).

One possible use case is = wireless access such as LTE uplink where congestion can build up quite quic= kly, don’t have any proof that ack-clocking can improve things here however.

 <= /p>

 <= /p>

/Ingemar

 <= /p>

From: Michael = Welzl [mailto:michawe@ifi.uio.no]
Sent: den 18 december 2012 11:45
To: Ingemar Johansson S
Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org
Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send times= tamps)

 

 

On 18. des. 2012, at 11:31, Ingemar Johansson S wrot= e:



Hi

 <= /p>

As regards to ACK-clockin= g

What comes into mind is t= he work on TWFC

There should be full pape= r somewhere, don’t find it though.  

 

Oh yes, you totally have a point there. The thesis s= urely has all the details, it is at:

(It seems that the pfldnet2009 page doesn't work any= more. I was on the org. committee, and at the conference, so that paper is = in fact on my shelves somewhere...  :-)   )

 

Anyway, this isn't making the point that ACK clockin= g is "a big reason for TCP preventing the Internet from collapsing&quo= t;. Sure it's a benefit, and of course we can find situations where AC= K-clocked protocols do better, no doubt about that.

 

 

 ConEx: Yes, need to see it fly, might ta= ke a while, might take like forever....

I put this as a future co= nsideration. If we build something completely receiver based however we may= end up with a headache in the future if ConEx flies as one will then anyway need to feed back packet loss/marks to the sender.

 

So this is where we differ: I don't believe that thi= s would be a major headache. The point of keeping stuff at the receiver is = just to reduce the feedback frequency. Inevitably, if you need the sender t= o have a more up-to-date picture of things, you'll have to increase that frequency, and possibly you'd also wa= nt to somehow extend the feedback format for ConEx. I don't think that's go= ing to be such a big deal to retrofit, if it really becomes necessary.=

 

Cheers,

Michael

 

 



 <= /p>

/Ingemar

 <= /p>

From: Michael Welzl [mailto:michawe@ifi.u= io.no] 
Sent: den 18 decem= ber 2012 11:06
To: Ingemar Johans= son S
Cc: Harald Alvestr= and; holmer@google.com; rmcat@ietf.org
Subject: Re: [rmca= t] Sender or Receiver based CC (was RE: Send timestamps)<= /p>

 

Hi,

 

In line:

 

 

On 18. des. 2012, at 10:50, Ingemar Johansson S wrot= e:




Hi

Thanks Harald and Stefan<= /span>

OK, understand. The conce= pt is then to do atleast the delay based rate adaptation in the receiving e= nd. The feedback the sender would then be either an absolute bitrate value or a relative increase/decrease value depending on the algor= ithm.

 <= /p>

Change subject line as I = deviate from the original thread a little.

I believe this has been d= iscussed before but repeat it.

 <= /p>

What about packet loss &n= bsp;and ECN marks ? ,  bufferbloat will eventually go away, may take 5= years, 10 years, 20 years, don’t know. I see it unlikely that a dela= y based algo will be able to tune it self such that it will efficiently avoi= d packet drops, for instance a queue with the CoDel algorithm may drop/mark= packets even at very low queue depths because of its inherent design. So t= he algo needs to be reactive to packet loss/marks (not a particularly controversial point)

 

Indeed, I think we all agree on this?

 

 <= /p>

Here one can chose two pa= ths for the packet loss/mark based rate adaptation.

Sender based rate adaptat= ion: Requires feedback of packet drops/mark, the accuracy depends on how th= e feedback is used.

Receiver based rate adapt= ation: Feedback is only a rate command.

 <= /p>

It would seems like the r= eceiver based algo is to prefer. There are however at least two reasons to = why a sender based algo is to prefer.

1)  &nb= sp;   Ack-clocking, while TCP is not 100% perfect it has sofar avoided collapsing the internet= completely.  A big reason is ack-clocking meaning that sudden increas= es of RTT is reacted to quite fast. At the same time that packet loss/marks= are reported, it is also possible to report back successfully received packets. Only a receiver based algo may = be too slow in this respect. For the ack-clocking to work some timeliness o= f the feedback is required, RTCP may be too infrequent, inband feedback has= been suggested as a solution earlier.

 

I think that ACK clocking is not really an option fo= r a rate based scheme with reasonably limited feedback anyway. You say that= ACK-clocking is a big reason for TCP preventing the Internet from collapsi= ng. I challenge that notion (I can hear the sound from the audience...). Yes it has been said again and again= that ACK-clocking has that seminal role, but show me some proof. I don't r= emember seeing a paper which convincingly shows exactly that.

 

We can, on the other hand, say that rate based conge= stion controls (as used at the app layer in UDP based apps already) haven't= yet driven the Internet into collapse...

 

I would argue that the more important thing seems to= be to have a timeout, reacting on a reasonable RTT based time scale, and t= hat can be achieved with a rate based scheme.

 <= /p>

 <= /p>

 




2)  &nb= sp;   ConEx: I believe that the future will require that applications expose the conges= tion that they cause. A ConEx enabled endpoint is required to state caused = congestion, this means that the receiver must feedback the packet loss/mark= s accurately, inband feedback may be to prefer here as it is more timely than RTCP.

 

I would suggest to standardize RMCAT extensions for = ConEx later, when we see a need due to widespread ConEx deployment   ;= -)

 




Both of the statements ab= ove implines that one may as well to the packet loss/mark based rate adapta= tion the sender side.

 <= /p>

I have deliberately only = considered communication between two peers in this email. More advanced cas= es may of course add other concerns.

 <= /p>

/Ingemar

 

Cheers,

Michael

 

 




 <= /p>

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: den 17 decem= ber 2012 20:37
To: Ingemar Johans= son S
Cc: rmcat@ietf.org
Subject: Re: [rmca= t] Send timestamps

 =

On 12/17/2012 03:45 PM, = Ingemar Johansson S wrote:

Hi

 <= /p>

I believe that it can mak= e sense to use a separate timestamp for congestion control but I may need t= o read and understand some more. A few reflections though.

 <= /p>

Unless I miss something, = this is quite close to the TCP timestamps which are used for congestion avo= idance in TCP Vegas and LEDBAT.

The problem in Vegas is t= hat it is sensitive to congestion in the feedback path, not shure though ho= w much concern that should be.

If we keep a model of co= mputation-at-receiver, it's not a problem at all.



LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers advantage= .

Both the above assume tha= t one ACKs are returned to the sender almost immediately (delay ACK adds so= me uncertanity here) also one don’t need to synchronize clocks.

Here I get unsure about w= hat to do with the received timestamps, I guess you can compute a delta bet= ween sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.


As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence.

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA06EA7FESESSMB205ericsso_-- From michawe@ifi.uio.no Wed Dec 19 07:42:23 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DF821F888C for ; Wed, 19 Dec 2012 07:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDZdzkWxKt2F for ; Wed, 19 Dec 2012 07:42:18 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 7047C21F882E for ; Wed, 19 Dec 2012 07:42:16 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TlLmg-0000sv-NZ; Wed, 19 Dec 2012 16:42:14 +0100 Received: from 120.169.202.84.customer.cdi.no ([84.202.169.120] helo=[192.168.0.193]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TlLmf-0007JS-RJ; Wed, 19 Dec 2012 16:42:14 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> Date: Wed, 19 Dec 2012 16:42:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <17902979-B5DD-4447-838A-FCA0C5B8C1E3@ifi.uio.no> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 8 sum msgs/h 4 total rcpts 968 max rcpts/h 20 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: BC97341639E7D77E09E7FEEE40D49916721EE4F8 X-UiO-SPAM-Test: remote_host: 84.202.169.120 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 124 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: "holmer@google.com" , Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:42:23 -0000 On Dec 19, 2012, at 2:20 PM, Ingemar Johansson S = wrote: > Hi > =20 > Yes, you are probably right, I should probably have avoided the term = =93collapse=94, > Question is if ack-clocking provides a benefit large enough to = motivate the higher feedback rate (even though the feedback can perhaps = be inband?). exactly! spot on > One possible use case is wireless access such as LTE uplink where = congestion can build up quite quickly, don=92t have any proof that = ack-clocking can improve things here however. =85. but other wireless links actually make a point for feedback = reduction (on wlans, in typical mostly-download scenarios, most of the = collisions are your data + your acks=85. > =20 > =20 > /Ingemar > =20 > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: den 18 december 2012 11:45 > To: Ingemar Johansson S > Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org > Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send = timestamps) > =20 > =20 > On 18. des. 2012, at 11:31, Ingemar Johansson S wrote: >=20 >=20 > Hi > =20 > As regards to ACK-clocking > What comes into mind is the work on TWFC > http://www.slideshare.net/soohyunc/pfld-ne-t09 > There should be full paper somewhere, don=92t find it though. =20 > =20 > Oh yes, you totally have a point there. The thesis surely has all the = details, it is at: > http://tfwc.hackerslab.eu/docs > (It seems that the pfldnet2009 page doesn't work anymore. I was on the = org. committee, and at the conference, so that paper is in fact on my = shelves somewhere... :-) ) > =20 > Anyway, this isn't making the point that ACK clocking is "a big reason = for TCP preventing the Internet from collapsing". Sure it's a benefit, = and of course we can find situations where ACK-clocked protocols do = better, no doubt about that. > =20 > =20 > ConEx: Yes, need to see it fly, might take a while, might take like = forever.... > I put this as a future consideration. If we build something completely = receiver based however we may end up with a headache in the future if = ConEx flies as one will then anyway need to feed back packet loss/marks = to the sender. > =20 > So this is where we differ: I don't believe that this would be a major = headache. The point of keeping stuff at the receiver is just to reduce = the feedback frequency. Inevitably, if you need the sender to have a = more up-to-date picture of things, you'll have to increase that = frequency, and possibly you'd also want to somehow extend the feedback = format for ConEx. I don't think that's going to be such a big deal to = retrofit, if it really becomes necessary. > =20 > Cheers, > Michael > =20 > =20 >=20 >=20 > =20 > /Ingemar > =20 > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: den 18 december 2012 11:06 > To: Ingemar Johansson S > Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org > Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send = timestamps) > =20 > Hi, > =20 > In line: > =20 > =20 > On 18. des. 2012, at 10:50, Ingemar Johansson S wrote: >=20 >=20 >=20 > Hi > Thanks Harald and Stefan > OK, understand. The concept is then to do atleast the delay based rate = adaptation in the receiving end. The feedback the sender would then be = either an absolute bitrate value or a relative increase/decrease value = depending on the algorithm. > =20 > Change subject line as I deviate from the original thread a little. > I believe this has been discussed before but repeat it. > =20 > What about packet loss and ECN marks ? , bufferbloat will eventually = go away, may take 5 years, 10 years, 20 years, don=92t know. I see it = unlikely that a delay based algo will be able to tune it self such that = it will efficiently avoid packet drops, for instance a queue with the = CoDel algorithm may drop/mark packets even at very low queue depths = because of its inherent design. So the algo needs to be reactive to = packet loss/marks (not a particularly controversial point) > =20 > Indeed, I think we all agree on this? > =20 > =20 > Here one can chose two paths for the packet loss/mark based rate = adaptation. > Sender based rate adaptation: Requires feedback of packet drops/mark, = the accuracy depends on how the feedback is used. > Receiver based rate adaptation: Feedback is only a rate command. > =20 > It would seems like the receiver based algo is to prefer. There are = however at least two reasons to why a sender based algo is to prefer. > 1) Ack-clocking, while TCP is not 100% perfect it has sofar = avoided collapsing the internet completely. A big reason is = ack-clocking meaning that sudden increases of RTT is reacted to quite = fast. At the same time that packet loss/marks are reported, it is also = possible to report back successfully received packets. Only a receiver = based algo may be too slow in this respect. For the ack-clocking to work = some timeliness of the feedback is required, RTCP may be too infrequent, = inband feedback has been suggested as a solution earlier. > =20 > I think that ACK clocking is not really an option for a rate based = scheme with reasonably limited feedback anyway. You say that = ACK-clocking is a big reason for TCP preventing the Internet from = collapsing. I challenge that notion (I can hear the sound from the = audience...). Yes it has been said again and again that ACK-clocking has = that seminal role, but show me some proof. I don't remember seeing a = paper which convincingly shows exactly that. > =20 > We can, on the other hand, say that rate based congestion controls (as = used at the app layer in UDP based apps already) haven't yet driven the = Internet into collapse... > =20 > I would argue that the more important thing seems to be to have a = timeout, reacting on a reasonable RTT based time scale, and that can be = achieved with a rate based scheme. > =20 > =20 > =20 >=20 >=20 >=20 > 2) ConEx: I believe that the future will require that = applications expose the congestion that they cause. A ConEx enabled = endpoint is required to state caused congestion, this means that the = receiver must feedback the packet loss/marks accurately, inband feedback = may be to prefer here as it is more timely than RTCP. > =20 > I would suggest to standardize RMCAT extensions for ConEx later, when = we see a need due to widespread ConEx deployment ;-) > =20 >=20 >=20 >=20 > Both of the statements above implines that one may as well to the = packet loss/mark based rate adaptation the sender side. > =20 > I have deliberately only considered communication between two peers in = this email. More advanced cases may of course add other concerns. > =20 > /Ingemar > =20 > Cheers, > Michael > =20 > =20 >=20 >=20 >=20 > =20 > =20 > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: den 17 december 2012 20:37 > To: Ingemar Johansson S > Cc: rmcat@ietf.org > Subject: Re: [rmcat] Send timestamps > =20 > On 12/17/2012 03:45 PM, Ingemar Johansson S wrote: > Hi > =20 > I believe that it can make sense to use a separate timestamp for = congestion control but I may need to read and understand some more. A = few reflections though. > =20 > Unless I miss something, this is quite close to the TCP timestamps = which are used for congestion avoidance in TCP Vegas and LEDBAT. > The problem in Vegas is that it is sensitive to congestion in the = feedback path, not shure though how much concern that should be. > If we keep a model of computation-at-receiver, it's not a problem at = all. >=20 >=20 >=20 > LEDBAT modifies this and implement the concept of base delay, but = suffers from late comers advantage. > Both the above assume that one ACKs are returned to the sender almost = immediately (delay ACK adds some uncertanity here) also one don=92t need = to synchronize clocks. > Here I get unsure about what to do with the received timestamps, I = guess you can compute a delta between sent and received timestamp but = unless you have exactly synchronized clocks in sender(s) and = receiver(s), you will have an unknown offset that can possibly also = drift due to clock skew. >=20 > As Stefan says - since we measure ~a moving average of difference = between the (receive timestamp - send timestamp) of successive packets, = not an absolute transit time, value, this is not likely to be an issue. >=20 > I have a hard time imagining clock drift so severe that it will = significantly influence the deltas of packets that are sent less than a = second apart. Clock jumps (like leap seconds) may be a measurable, but = extremely transient, influence. >=20 > =20 > =20 From saverio.mascolo@gmail.com Wed Dec 19 09:53:50 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809AA21F8475 for ; Wed, 19 Dec 2012 09:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brpXb2IbConC for ; Wed, 19 Dec 2012 09:53:49 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3F21F842C for ; Wed, 19 Dec 2012 09:53:46 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id p5so1680714lag.5 for ; Wed, 19 Dec 2012 09:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=baNLq9PeQE355YARFYlN2zN1qOx9fQ53QAN7vQupG64=; b=VSHzi4mDQXTMGGkvFpG6HDJ8j3EZGM0pivn5Y6uBdxRGgs5/6RKDi6Aj/9erTdbX2y FwLpuNhUeMZe6FEogODXVy0ypTTnxerTgRPVRmGwMEadMFfatf1pneAD3GHtdHoTwoBc MvUs9yFgfss6sIrzNVcunOHduFaZVfw8a20NdBDMgIESbxBrOJj8Mlcwc/CH77fMmc/l 5Z6rIRqn/k2ihWG/MI6r5UpTrMSAXIxERGvEHVZlR/zeo2oQrPWeKta3jW68UVRil4eV Fc4ywjgt/exyWokG/UD3IehIll5NguoNPKhPs0b2XY1m5yTPR0XzfOTrdak0D7tD9s96 rRGw== MIME-Version: 1.0 Received: by 10.112.9.135 with SMTP id z7mr2644229lba.66.1355939625607; Wed, 19 Dec 2012 09:53:45 -0800 (PST) Received: by 10.112.80.199 with HTTP; Wed, 19 Dec 2012 09:53:45 -0800 (PST) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> Date: Wed, 19 Dec 2012 18:53:45 +0100 Message-ID: From: Saverio Mascolo To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=e0cb4efe2f7eb8a4a404d1384ba2 Cc: "holmer@google.com" , Harald Alvestrand , Michael Welzl , "rmcat@ietf.org" Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:53:50 -0000 --e0cb4efe2f7eb8a4a404d1384ba2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ack clocking is fundamental since it is an intrinsic stabilizer of the network, one packet out - one packet in. This out-in is also executed at the right time, "real time" as it has to be for dynamic control. Saverio On Wednesday, December 19, 2012, Ingemar Johansson S wrote: > Hi**** > > ** ** > > Yes, you are probably right, I should probably have avoided the term > =93collapse=94, **** > > Question is if ack-clocking provides a benefit large enough to motivate > the higher feedback rate (even though the feedback can perhaps be inband?= ). > **** > > One possible use case is wireless access such as LTE uplink where > congestion can build up quite quickly, don=92t have any proof that > ack-clocking can improve things here however.**** > > ** ** > > ** ** > > /Ingemar**** > > ** ** > > *From:* Michael Welzl [mailto:michawe@ifi.uio.no 'cvml', 'michawe@ifi.uio.no');>] > *Sent:* den 18 december 2012 11:45 > *To:* Ingemar Johansson S > *Cc:* Harald Alvestrand; holmer@google.com 'holmer@google.com');>; rmcat@ietf.org 'rmcat@ietf.org');> > *Subject:* Re: [rmcat] Sender or Receiver based CC (was RE: Send > timestamps)**** > > ** ** > > ** ** > > On 18. des. 2012, at 11:31, Ingemar Johansson S wrote:**** > > > > **** > > Hi**** > > **** > > As regards to ACK-clocking**** > > What comes into mind is the work on TWFC**** > > http://www.slideshare.net/soohyunc/pfld-ne-t09**** > > There should be full paper somewhere, don=92t find it though. **** > > ** ** > > Oh yes, you totally have a point there. The thesis surely has all the > details, it is at:**** > > http://tfwc.hackerslab.eu/docs**** > > (It seems that the pfldnet2009 page doesn't work anymore. I was on the > org. committee, and at the conference, so that paper is in fact on my > shelves somewhere... :-) )**** > > ** ** > > Anyway, this isn't making the point that ACK clocking is "a big reason fo= r > TCP preventing the Internet from collapsing". Sure it's a benefit, and of > course we can find situations where ACK-clocked protocols do better, no > doubt about that.**** > > ** ** > > ** ** > > ConEx: Yes, need to see it fly, might take a while, might take like > forever....**** > > I put this as a future consideration. If we build something completely > receiver based however we may end up with a headache in the future if Con= Ex > flies as one will then anyway need to feed back packet loss/marks to the > sender.**** > > ** ** > > So this is where we differ: I don't believe that this would be a major > headache. The point of keeping stuff at the receiver is just to reduce th= e > feedback frequency. Inevitably, if you need the sender to have a more > up-to-date picture of things, you'll have to increase that frequency, and > possibly you'd also want to somehow extend the feedback format for ConEx.= I > don't think that's going to be such a big deal to retrofit, if it really > becomes necessary.**** > > ** ** > > Cheers,**** > > Michael**** > > ** ** > > ** ** > > > > **** > > **** > > /Ingemar**** > > **** > > *From* > --=20 Saverio Mascolo, Full Professor Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it http://c3lab.poliba.it =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material i= n this message, and any attachments to the message, is strictly forbidden. --e0cb4efe2f7eb8a4a404d1384ba2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ack clocking is fundamental since it is an intrinsic stabilizer of the netw= ork, one packet out -=A0one packet in. This out-in is also executed at the = right=A0time, "real time"=A0as it has to be for dynamic control.<= div>
Saverio

On Wednesday, December 19, 2012,= Ingemar Johansson S wrote:

Hi

=A0<= /p>

Yes, you are probably rig= ht, I should probably have avoided the term =93collapse=94,

Question is if ack-clocki= ng provides a benefit large enough to motivate the higher feedback rate (ev= en though the feedback can perhaps be inband?).

One possible use case is = wireless access such as LTE uplink where congestion can build up quite quic= kly, don=92t have any proof that ack-clocking can improve things here however.

=A0<= /p>

=A0<= /p>

/Ingemar

=A0<= /p>

From: Michael = Welzl [mailto:michawe@ifi.uio.no]
Sent: den 18 december 2012 11:45
To: Ingemar Johansson S
Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org
Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send times= tamps)

=A0

=A0

On 18. des. 2012, at 11:31, Ingemar Johansson S wrote:



Hi

=A0

As regards to ACK-clocking

What comes into mind is the work on TWFC

There should be full paper somewhere, don=92t= find it though. =A0

=A0

Oh yes, you totally have a point there. The thesis surely has all the de= tails, it is at:

(It seems that the pfldnet2009 page doesn't work anymore. I was on t= he org. committee, and at the conference, so that paper is in fact on my sh= elves somewhere... =A0:-) =A0 )

=A0

Anyway, this isn't making the point that ACK clocking is "a big= reason for TCP preventing the Internet from collapsing".=A0Sure it= 9;s a benefit, and of course we can find situations where ACK-clocked proto= cols do better, no doubt about that.

=A0

=A0

=A0ConEx: Yes, need= to see it fly, might take a while, might take like forever....

I put this as a future consideration. If we b= uild something completely receiver based however we may end up with a heada= che in the future if ConEx flies as one will then anyway need to feed back packet loss/marks to the sender.

=A0

So this is where we differ: I don't believe that this would be a maj= or headache. The point of keeping stuff at the receiver is just to reduce t= he feedback frequency. Inevitably, if you need the sender to have a more up= -to-date picture of things, you'll have to increase that frequency, and possibly you'd= also want to somehow extend the feedback format for ConEx. I don't thi= nk that's going to be such a big deal to retrofit, if it really becomes= necessary.

=A0

Cheers,

Michael

=A0

=A0



=A0

/Ingemar

=A0

From



--
Saverio Mascolo, Full Professor
Dipart= imento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabo= na 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:mascol= o@poliba.it
=A0
http://c3lab.poliba.it


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0Th= is message may contain confidential and/or legally privileged information.<= br> =A0 If you are not the intended recipient of the message, please destroy it= .
=A0Any unauthorized dissemination, distribution, or copying of the mat= erial in
=A0this message, and any attachments to the message, is strictl= y forbidden.
--e0cb4efe2f7eb8a4a404d1384ba2-- From michawe@ifi.uio.no Wed Dec 19 15:37:13 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0621F88A2 for ; Wed, 19 Dec 2012 15:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H0rczXJxejy for ; Wed, 19 Dec 2012 15:37:12 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id B52AB21F8993 for ; Wed, 19 Dec 2012 15:37:11 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TlTCH-0000Ib-H5; Thu, 20 Dec 2012 00:37:09 +0100 Received: from 120.169.202.84.customer.cdi.no ([84.202.169.120] helo=[192.168.0.193]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TlTCG-0005iq-S1; Thu, 20 Dec 2012 00:37:09 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: Date: Thu, 20 Dec 2012 00:37:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <831287B5-8B56-4FB4-947C-928AAEBBB15F@ifi.uio.no> References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> To: Saverio Mascolo X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 987 max rcpts/h 20 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: 21008CFEE53446339864DE04DE5D6220DA2AAADB X-UiO-SPAM-Test: remote_host: 84.202.169.120 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 136 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: Ingemar Johansson S , "holmer@google.com" , "rmcat@ietf.org" , Harald Alvestrand Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:37:13 -0000 Saverio - all that a rate based protocol does is relax this rule = somewhat. The way you describe it, and the way TCP does it, is on a = per-packet granularity. The question is: what granularity is really = needed? I think Ingemar has precisely phrased the key question: is the = benefit enough to motivate the higher feedback rate? This is an = engineering trade-off, how do we make the right decision here? Here's a pragmatic thought, from looking at = draft-alvestrand-rtcweb-congestion (I'll call it RRTCC in the rest of = this email, but it's high time for a better acronym if you ask me =85 = may I suggest ResiDedi? That stands for "Receiver-side Delay Difference" = :-) ) - with this mechanism, in the absence of feedback (e.g. due to = extremely heavy congestion in both directions), the sender will keep = increasing its rate until a time of 2*t_max_fb_interval is reached. The = value of this parameter is not given - but: if it is larger than TCP's = RTO, competing TCPs along the same paths might be pushed into timeout, = and RRTCC flow would just keep increasing its rate=85 That doesn't seem good to me. Let's say we fix it, by requiring this = interval to be an RTT, which is a conservative lower bound for an RTO - = a case of no RTT variation (probably unrealistic in the presence of = congestion). Now we can ask ourselves: why care about TCPs on the exact = same path only? What about TCPs whose RTT is dramatically different, = e.g. shorter? A TCP with a large RTT will exhibit the same behavior towards a = short-RTT TCP as described for RRTCC above: the short-RTT TCP will = already have a timeout while the long-RTT TCP will still keep = increasing. We could say that the Internet has maintained reasonable = performance with the existing TCP behavior and RTT variations, and so, = mimicking the long-vs-short-RTT thing by requiring RRTCC to timeout = after 1 RTT (or any better resemblance of an RTO we can come up with) = would seem okay. Can we stretch that further? Say, we react after 2 RTTs=85 isn't that = like saying: would we get reasonable Internet service even if RTT = variations were twice as large? Well, if that is the case, then the answer is no, I think - from = anecdotal evidence: Andrew McGregor would tell you that the big RTT = differences people in New Zealand experience make some things work = rather badly, and (if I understood him right) that's what makes him so = excited about FQ_CoDel - being where he is, he really experiences the = difference of FQ (with CoDel limiting the delay). I have heard similar = stories from others, and had similar experiences in Australia. So, would it be reasonable to conclude that RTT variation as it is is = already bad enough, and hence RRTCC's sender timeout shouldn't be more = than 1 RTO, which we could pick to be 1 RTT (note, as an alternative, = e.g. TFRC chooses RTO=3D4*RTT, but without any justification AFAIK)? Then note, of course: if that logic works, it applies to any mechanism, = not just RRTCC... I wonder what people think about this. I suspect that my logic is = broken, in some way, somewhere up there in the text=85 Cheers, Michael On Dec 19, 2012, at 6:53 PM, Saverio Mascolo = wrote: > Ack clocking is fundamental since it is an intrinsic stabilizer of the = network, one packet out - one packet in. This out-in is also executed at = the right time, "real time" as it has to be for dynamic control. >=20 > Saverio >=20 > On Wednesday, December 19, 2012, Ingemar Johansson S wrote: > Hi >=20 > =20 >=20 > Yes, you are probably right, I should probably have avoided the term = =93collapse=94, >=20 > Question is if ack-clocking provides a benefit large enough to = motivate the higher feedback rate (even though the feedback can perhaps = be inband?). >=20 > One possible use case is wireless access such as LTE uplink where = congestion can build up quite quickly, don=92t have any proof that = ack-clocking can improve things here however. >=20 > =20 >=20 > =20 >=20 > /Ingemar >=20 > =20 >=20 > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: den 18 december 2012 11:45 > To: Ingemar Johansson S > Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org > Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send = timestamps) >=20 > =20 >=20 > =20 >=20 > On 18. des. 2012, at 11:31, Ingemar Johansson S wrote: >=20 >=20 >=20 >=20 > Hi >=20 > =20 >=20 > As regards to ACK-clocking >=20 > What comes into mind is the work on TWFC >=20 > http://www.slideshare.net/soohyunc/pfld-ne-t09 >=20 > There should be full paper somewhere, don=92t find it though. =20 >=20 > =20 >=20 > Oh yes, you totally have a point there. The thesis surely has all the = details, it is at: >=20 > http://tfwc.hackerslab.eu/docs >=20 > (It seems that the pfldnet2009 page doesn't work anymore. I was on the = org. committee, and at the conference, so that paper is in fact on my = shelves somewhere... :-) ) >=20 > =20 >=20 > Anyway, this isn't making the point that ACK clocking is "a big reason = for TCP preventing the Internet from collapsing". Sure it's a benefit, = and of course we can find situations where ACK-clocked protocols do = better, no doubt about that. >=20 > =20 >=20 > =20 >=20 > ConEx: Yes, need to see it fly, might take a while, might take like = forever.... >=20 > I put this as a future consideration. If we build something completely = receiver based however we may end up with a headache in the future if = ConEx flies as one will then anyway need to feed back packet loss/marks = to the sender. >=20 > =20 >=20 > So this is where we differ: I don't believe that this would be a major = headache. The point of keeping stuff at the receiver is just to reduce = the feedback frequency. Inevitably, if you need the sender to have a = more up-to-date picture of things, you'll have to increase that = frequency, and possibly you'd also want to somehow extend the feedback = format for ConEx. I don't think that's going to be such a big deal to = retrofit, if it really becomes necessary. >=20 > =20 >=20 > Cheers, >=20 > Michael >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 > =20 >=20 > /Ingemar >=20 > =20 >=20 > From >=20 >=20 >=20 > --=20 > Saverio Mascolo, Full Professor > Dipartimento di Elettrotecnica ed Elettronica > Politecnico di Bari > Via Orabona 4, 70125 Bari Italy > Tel. +39 080 5963621 > Fax. +39 080 5963410 > email:mascolo@poliba.it > =20 > http://c3lab.poliba.it >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This message may contain confidential and/or legally privileged = information. > If you are not the intended recipient of the message, please destroy = it. > Any unauthorized dissemination, distribution, or copying of the = material in > this message, and any attachments to the message, is strictly = forbidden. From harald@alvestrand.no Thu Dec 20 00:23:44 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4F21F87D1 for ; Thu, 20 Dec 2012 00:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB9ty-khhbzg for ; Thu, 20 Dec 2012 00:23:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7021D21F873E for ; Thu, 20 Dec 2012 00:23:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5418539E151; Thu, 20 Dec 2012 09:23:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOthdG8jSLz4; Thu, 20 Dec 2012 09:23:31 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B4ECB39E090; Thu, 20 Dec 2012 09:23:31 +0100 (CET) Message-ID: <50D2CB03.3000004@alvestrand.no> Date: Thu, 20 Dec 2012 09:23:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Welzl References: <81564C0D7D4D2A4B9A86C8C7404A13DA06DDBA@ESESSMB205.ericsson.se> <5EDD9163-37FC-452F-901C-D4B3A01E592D@ifi.uio.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06DE8D@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA06EA7F@ESESSMB205.ericsson.se> <831287B5-8B56-4FB4-947C-928AAEBBB15F@ifi.uio.no> In-Reply-To: <831287B5-8B56-4FB4-947C-928AAEBBB15F@ifi.uio.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ingemar Johansson S , "holmer@google.com" , "rmcat@ietf.org" , Saverio Mascolo Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:23:44 -0000 On 12/20/2012 12:37 AM, Michael Welzl wrote: > Saverio - all that a rate based protocol does is relax this rule somewhat. The way you describe it, and the way TCP does it, is on a per-packet granularity. The question is: what granularity is really needed? I think Ingemar has precisely phrased the key question: is the benefit enough to motivate the higher feedback rate? This is an engineering trade-off, how do we make the right decision here? > > Here's a pragmatic thought, from looking at draft-alvestrand-rtcweb-congestion (I'll call it RRTCC in the rest of this email, but it's high time for a better acronym if you ask me … may I suggest ResiDedi? That stands for "Receiver-side Delay Difference" :-) ) - with this mechanism, in the absence of feedback (e.g. due to extremely heavy congestion in both directions), the sender will keep increasing its rate until a time of 2*t_max_fb_interval is reached. The value of this parameter is not given - but: if it is larger than TCP's RTO, competing TCPs along the same paths might be pushed into timeout, and RRTCC flow would just keep increasing its rate… > > That doesn't seem good to me. No, and it's why the RRTCC algorithm requires a sender-side limiter based on the TFRC equation in addition to the receiver-side estimator. In addition, it makes sense to implement Colin Perkins' "circuit breakers" algorithm, which mandates stopping the flow on two RTCP retransmission intervals without feedback packets. Any receiver-side belt requires *some* sender-side suspenders. Rest of message is beyond easy comprehension for me while on vacation..... > Let's say we fix it, by requiring this interval to be an RTT, which is a conservative lower bound for an RTO - a case of no RTT variation (probably unrealistic in the presence of congestion). Now we can ask ourselves: why care about TCPs on the exact same path only? What about TCPs whose RTT is dramatically different, e.g. shorter? > > A TCP with a large RTT will exhibit the same behavior towards a short-RTT TCP as described for RRTCC above: the short-RTT TCP will already have a timeout while the long-RTT TCP will still keep increasing. We could say that the Internet has maintained reasonable performance with the existing TCP behavior and RTT variations, and so, mimicking the long-vs-short-RTT thing by requiring RRTCC to timeout after 1 RTT (or any better resemblance of an RTO we can come up with) would seem okay. > > Can we stretch that further? Say, we react after 2 RTTs… isn't that like saying: would we get reasonable Internet service even if RTT variations were twice as large? > Well, if that is the case, then the answer is no, I think - from anecdotal evidence: Andrew McGregor would tell you that the big RTT differences people in New Zealand experience make some things work rather badly, and (if I understood him right) that's what makes him so excited about FQ_CoDel - being where he is, he really experiences the difference of FQ (with CoDel limiting the delay). I have heard similar stories from others, and had similar experiences in Australia. > > So, would it be reasonable to conclude that RTT variation as it is is already bad enough, and hence RRTCC's sender timeout shouldn't be more than 1 RTO, which we could pick to be 1 RTT (note, as an alternative, e.g. TFRC chooses RTO=4*RTT, but without any justification AFAIK)? > > Then note, of course: if that logic works, it applies to any mechanism, not just RRTCC... > > I wonder what people think about this. I suspect that my logic is broken, in some way, somewhere up there in the text… > > Cheers, > Michael > > > On Dec 19, 2012, at 6:53 PM, Saverio Mascolo wrote: > >> Ack clocking is fundamental since it is an intrinsic stabilizer of the network, one packet out - one packet in. This out-in is also executed at the right time, "real time" as it has to be for dynamic control. >> >> Saverio >> >> On Wednesday, December 19, 2012, Ingemar Johansson S wrote: >> Hi >> >> >> >> Yes, you are probably right, I should probably have avoided the term “collapse”, >> >> Question is if ack-clocking provides a benefit large enough to motivate the higher feedback rate (even though the feedback can perhaps be inband?). >> >> One possible use case is wireless access such as LTE uplink where congestion can build up quite quickly, don’t have any proof that ack-clocking can improve things here however. >> >> >> >> >> >> /Ingemar >> >> >> >> From: Michael Welzl [mailto:michawe@ifi.uio.no] >> Sent: den 18 december 2012 11:45 >> To: Ingemar Johansson S >> Cc: Harald Alvestrand; holmer@google.com; rmcat@ietf.org >> Subject: Re: [rmcat] Sender or Receiver based CC (was RE: Send timestamps) >> >> >> >> >> >> On 18. des. 2012, at 11:31, Ingemar Johansson S wrote: >> >> >> >> >> Hi >> >> >> >> As regards to ACK-clocking >> >> What comes into mind is the work on TWFC >> >> http://www.slideshare.net/soohyunc/pfld-ne-t09 >> >> There should be full paper somewhere, don’t find it though. >> >> >> >> Oh yes, you totally have a point there. The thesis surely has all the details, it is at: >> >> http://tfwc.hackerslab.eu/docs >> >> (It seems that the pfldnet2009 page doesn't work anymore. I was on the org. committee, and at the conference, so that paper is in fact on my shelves somewhere... :-) ) >> >> >> >> Anyway, this isn't making the point that ACK clocking is "a big reason for TCP preventing the Internet from collapsing". Sure it's a benefit, and of course we can find situations where ACK-clocked protocols do better, no doubt about that. >> >> >> >> >> >> ConEx: Yes, need to see it fly, might take a while, might take like forever.... >> >> I put this as a future consideration. If we build something completely receiver based however we may end up with a headache in the future if ConEx flies as one will then anyway need to feed back packet loss/marks to the sender. >> >> >> >> So this is where we differ: I don't believe that this would be a major headache. The point of keeping stuff at the receiver is just to reduce the feedback frequency. Inevitably, if you need the sender to have a more up-to-date picture of things, you'll have to increase that frequency, and possibly you'd also want to somehow extend the feedback format for ConEx. I don't think that's going to be such a big deal to retrofit, if it really becomes necessary. >> >> >> >> Cheers, >> >> Michael >> >> >> >> >> >> >> >> >> >> >> /Ingemar >> >> >> >> From >> >> >> >> -- >> Saverio Mascolo, Full Professor >> Dipartimento di Elettrotecnica ed Elettronica >> Politecnico di Bari >> Via Orabona 4, 70125 Bari Italy >> Tel. +39 080 5963621 >> Fax. +39 080 5963410 >> email:mascolo@poliba.it >> >> http://c3lab.poliba.it >> >> >> ================================= >> This message may contain confidential and/or legally privileged information. >> If you are not the intended recipient of the message, please destroy it. >> Any unauthorized dissemination, distribution, or copying of the material in >> this message, and any attachments to the message, is strictly forbidden. From zaheduzzaman.sarker@ericsson.com Thu Dec 20 00:53:28 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4936121F85D0 for ; Thu, 20 Dec 2012 00:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en9MjYFi86XJ for ; Thu, 20 Dec 2012 00:53:27 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3065D21F85A7 for ; Thu, 20 Dec 2012 00:53:27 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-bc-50d2d20606e4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DF.A0.24873.602D2D05; Thu, 20 Dec 2012 09:53:26 +0100 (CET) Received: from [150.132.141.56] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 20 Dec 2012 09:53:25 +0100 Message-ID: <50D2D205.8040700@ericsson.com> Date: Thu, 20 Dec 2012 09:53:25 +0100 From: Zaheduzzaman Sarker User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Stefan Holmer References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Rpft0qUAg7/TxSyu7j/HYvHiwRwm i9U3P7A5MHtM+b2R1WPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBlvL3ylb1gk3TFidlzGBsY L4p2MXJySAiYSKw7380CYYtJXLi3nq2LkYtDSOAko0T32gNsIAkhgTWMEkt7NEFsXgFtiSkd b8HiLAKqEjNv/gGyOTjYBGwkHi/2AzFFBYIlug6LQVQLSpyc+QRsvAhQ9fXPyxhBbGYBD4lb 6w6BdQoLqEhcmB8GsfUao8SNGQ/ApnMKBEpcWbuKFaSGWcBe4sHWMohWeYnmrbOZQcJCAroS XS/jJjAKzkKybBZCwywkDQsYmVcxsucmZuaklxttYgSG5sEtv1V3MN45J3KIUZqDRUmcN9z1 QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxl2GLqFLdx9+Zr+EwfKy+Z7Eo43zxLRPT12i lHv+UWPTHXWBxRsnrZ09/aOHnrlcb4nMleL0M2kRlib2LnwMu/NmXYpbGJQyISCc85h47Ra9 dpPYZVFCRi+2+Zr/SJpT8qD+0qv/x2/eLet3PSqYfT8n2mHtdO+kqx2p3GHHG1dt+VObb6EV oMRSnJFoqMVcVJwIAPMi6KcbAgAA Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:53:28 -0000 On 2012-12-17 12:00, Stefan Holmer wrote: > I'll try to clarify with an example: > > Let's say we have two clients (A and B) in a call. We want to estimate > the bandwidth from A to B by looking at the variations in one-way delay, > which we can measure by comparing deltas in RTP timestamp to deltas in > receive-time. The problem with using RTP timestamps is that those > represent capture time and not the send time of a frame, so we get a lot > of noise related to variations in, e.g., video encoding time. How big is this problem? can you show us some data showing where this completely breaks or cause huge problem in estimating bandwidth? > around that we introduce RFC 5450 > and now we can measure something > much closer to actual network time. If we want to jointly process all > RTP streams from A to B (at the receiver, B) we can convert the RTP > timestamps of all streams to NTP using the (RTP timestamp, NTP > timestamp) tuple in the RTCP SR report. > > Now let's add a server (let's call it S) in between client A and B. This > server simply relays RTP packets (and might do some rewriting as well). > Now we want to estimate the bandwidth between A and S, and between S and > B. I think you will have to explain the topology a bit more in details here. What kind of feedback loop you are assuming? why do you need to estimate bandwidth between A-S and S-B separately? as I understand it that a simple relay S will be transparent between A and B and all we need to be concerned about delay visible between A-B. But if you have a different view or requirements on S then this might not be a point to point session we are concern here in RMCAT. S will have to change the timestamp offset (RFC 5450) of the RTP > packets to correspond to its send-time, but besides that all is fine. > > Now let's add a third client (C). S will relay packets from both A and C > to B, so ideally we should jointly process all of those packets when > estimating the bandwidth between S to B. However, packets sent from A > will be based on the tuple (RTP timestamp A, NTP timestamp A) and > packets sent from C will be based on (RTP timestamp C, NTP timestamp C), > so we can't just convert to NTP at B and compare them. This can be > solved in the server by rewriting RTP and NTP timestamps to (RTP > timestamp S, NTP timestamp S) before relaying to B, which requires > rewriting both RTP packets and RTCP packets. This is fine as long as you > rewrite _all_ streams from the same sending client in the same way, > otherwise you won't be able to synchronize them. Therefore all streams > must go through the same server. Again, you will have to explain the relation between A, C, B and S in details? Depending on that relation, it can turned out to be a multicast case, a unicast case with all legs are handled separately or even a multi-party multi-hop case which is out of scope right now. In the later case we should not be so concerned now but if you want to change the charter then you are more than welcomed from my part. BR -- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================ From holmer@google.com Thu Dec 20 01:31:56 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303C021F860D for ; Thu, 20 Dec 2012 01:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECvE8RLBTC8M for ; Thu, 20 Dec 2012 01:31:55 -0800 (PST) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9740C21F862B for ; Thu, 20 Dec 2012 01:31:54 -0800 (PST) Received: by mail-bk0-f53.google.com with SMTP id j5so1500703bkw.12 for ; Thu, 20 Dec 2012 01:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B6FHz3jIVebv65nwQZx736YUrPTjHAkZAW6SoHJikd0=; b=J2k0XvIe0ZTQd/nTtSRjzVglUfcKNZ521BXPFhFWPB0pyT6FyLt4vk6JO1EigM9sMe c0hFkuu9AS/9fWprZCL+yAA6RYLNMYUxItbQYZHHKTdGyoumpcSRjqfdLHSiOsVxQXea 7DcFAxNbB27dFINqo/eITEt91IopU54ovTndsSlG4j1qFnWRsXnYgkQdsWuggSGw3DhW K6TIjuBvu/D81VPsTxfZeMdenMxyg1wUtY8Okdo8EdKXlw2OQ7zVK6/Oaz4a3fYkZJOM Q9VZEw+Kt+vXTv7vwLlAIBragKSR8DqAdtWaGg1zux5s+t14QxSUU6SJUTn2+E3jT0T7 NA7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=B6FHz3jIVebv65nwQZx736YUrPTjHAkZAW6SoHJikd0=; b=YZWDNdgwVYRv2fxkLIKLh+GcSJ1ff29sEcAkJhf3JDf3ioOXLHhi3sIHSyGM5U+OE7 0mPR2p8wK+Fx6SuncoyZJZCAZe2yFTNgM/XQk7XbW7DZZ3Cyjw5g6fFhaLSIIqvsg05U AYcN6Sz7MqsL6UCy1BQ+KnGAPli373jFPmLm3RFMS1beP9NlVEtD7o7YuvPlu1RyMv+S kym6zKr3LcQ1GA33JhbpH/V2lF/4sjMSMo7lvdLWwSik23gpJ79UUmt6NpZqBYxuxpRK mvQrephQDKFVKVfuRI9dKo1Hf+ag8Md2BSEq2lFBpSDLAaKxgsZE6EvAMtge1Q1aukAq gOvA== MIME-Version: 1.0 Received: by 10.204.149.11 with SMTP id r11mr4160888bkv.93.1355995911590; Thu, 20 Dec 2012 01:31:51 -0800 (PST) Received: by 10.205.115.81 with HTTP; Thu, 20 Dec 2012 01:31:51 -0800 (PST) In-Reply-To: <50D2D205.8040700@ericsson.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50D2D205.8040700@ericsson.com> Date: Thu, 20 Dec 2012 10:31:51 +0100 Message-ID: From: Stefan Holmer To: Zaheduzzaman Sarker Content-Type: multipart/alternative; boundary=00151759329ea0925604d1456697 X-Gm-Message-State: ALoCoQn5+L5Wr4vmgt8/n4+qvxp5SuqJAAyiJI+CNNr686Fy6Gsiet1yGB+Z0Q+B+p5BYpWvyRTwCMcYmbB4WkdRs+yHUL3+BRf2vFAo9X+UnKJUjLbNv8giyrmx7491324fmvV+4bKI64zr+SWfb2oIXWtjAViFcOevH2BsSkcadPghiUrYP8lMABKk//KsaC8c3E190eRb Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 09:31:56 -0000 --00151759329ea0925604d1456697 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 20, 2012 at 9:53 AM, Zaheduzzaman Sarker < zaheduzzaman.sarker@ericsson.com> wrote: > On 2012-12-17 12:00, Stefan Holmer wrote: > >> I'll try to clarify with an example: >> >> Let's say we have two clients (A and B) in a call. We want to estimate >> the bandwidth from A to B by looking at the variations in one-way delay, >> which we can measure by comparing deltas in RTP timestamp to deltas in >> receive-time. The problem with using RTP timestamps is that those >> represent capture time and not the send time of a frame, so we get a lot >> of noise related to variations in, e.g., video encoding time. >> > > How big is this problem? can you show us some data showing where this > completely breaks or cause huge problem in estimating bandwidth? > I think it's a fairly big problem. We want to make sure the RTP timestamp is set to correspond to when the frame was captured, while the timestamp used for bandwidth estimation should be as close to sending the frame/packet as possible. For instance if your CPU is temporarily loaded you will get jitter similar to network congestion. I don't have any numbers to show you though. > > > around that we introduce RFC 5450 >> > >> and now we can measure something >> >> much closer to actual network time. If we want to jointly process all >> RTP streams from A to B (at the receiver, B) we can convert the RTP >> timestamps of all streams to NTP using the (RTP timestamp, NTP >> timestamp) tuple in the RTCP SR report. >> >> Now let's add a server (let's call it S) in between client A and B. This >> server simply relays RTP packets (and might do some rewriting as well). >> Now we want to estimate the bandwidth between A and S, and between S and >> B. >> > > I think you will have to explain the topology a bit more in details here. > What kind of feedback loop you are assuming? why do you need to estimate > bandwidth between A-S and S-B separately? as I understand it that a simpl= e > relay S will be transparent between A and B and all we need to be concern= ed > about delay visible between A-B. But if you have a different view or > requirements on S then this might not be a point to point session we are > concern here in RMCAT. I'm thinking of a topology where S is able to shape the outgoing streams to fit the link between S and B you want to be able to estimate the bandwidth on that link. How that shaping is done is of minor interest, but I can imagine both stripping layers and transcoding. > > > > S will have to change the timestamp offset (RFC 5450) of the RTP > >> packets to correspond to its send-time, but besides that all is fine. >> >> Now let's add a third client (C). S will relay packets from both A and C >> to B, so ideally we should jointly process all of those packets when >> estimating the bandwidth between S to B. However, packets sent from A >> will be based on the tuple (RTP timestamp A, NTP timestamp A) and >> packets sent from C will be based on (RTP timestamp C, NTP timestamp C), >> so we can't just convert to NTP at B and compare them. This can be >> solved in the server by rewriting RTP and NTP timestamps to (RTP >> timestamp S, NTP timestamp S) before relaying to B, which requires >> rewriting both RTP packets and RTCP packets. This is fine as long as you >> rewrite _all_ streams from the same sending client in the same way, >> otherwise you won't be able to synchronize them. Therefore all streams >> must go through the same server. >> > > Again, you will have to explain the relation between A, C, B and S in > details? Depending on that relation, it can turned out to be a multicast > case, a unicast case with all legs are handled separately or even a > multi-party multi-hop case which is out of scope right now. In the later > case we should not be so concerned now but if you want to change the > charter then you are more than welcomed from my part. > > BR > > -- > Zahed > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D**=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ANM ZAHEDUZZAMAN SARKER > > > Ericsson AB > Multimedia Technologies (MMT) > Ericsson Research > P.O. Box 920, SE-971 28, Lule=E5, Sweden > Phone +46 10 717 37 43 > Fax +46 920 996 21 > SMS/MMS +46 76 115 37 43 > zaheduzzaman.sarker@ericsson.**com > www.ericsson.com > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D**=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --00151759329ea0925604d1456697 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">


On Thu, Dec 20, 2012 at 9:53 AM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
On 2012-12-17 12:00, Stefa= n Holmer wrote:
I'll try to clarify with an example:

Let's say we have two clients (A and B) in a call. We want to estimate<= br> the bandwidth from A to B by looking at the variations in one-way delay, which we can measure by comparing deltas in RTP timestamp to deltas in
receive-time. The problem with using RTP timestamps is that those
represent capture time and not the send time of a frame, so we get a lot of noise related to variations in, e.g., video encoding time.

How big is this problem? can you show us some data showing where this compl= etely breaks or cause huge problem in estimating bandwidth?

I think it's a fairly big problem. We want t= o make sure the RTP timestamp is set to correspond to when the frame was ca= ptured, while the timestamp used for bandwidth estimation should be as clos= e to sending the frame/packet as possible. For instance if your CPU is temp= orarily loaded you will get jitter similar to network congestion. I don'= ;t have any numbers to show you though.
=A0


around that we introduce RFC 5450
<http://tools.ietf.org/html/rfc5450> and now we ca= n measure something

much closer to actual network time. If we want to jointly process all
RTP streams from A to B (at the receiver, B) we can convert the RTP
timestamps of all streams to NTP using the (RTP timestamp, NTP
timestamp) tuple in the RTCP SR report.

Now let's add a server (let's call it S) in between client A and B.= This
server simply relays RTP packets (and might do some rewriting as well).
Now we want to estimate the bandwidth between A and S, and between S and B.

I think you will have to explain the topology a bit more in details here. W= hat kind of feedback loop you are assuming? why do you need to estimate ban= dwidth between A-S and S-B separately? as I understand it that a simple rel= ay S will be transparent between A and B and all we need to be concerned ab= out delay visible between A-B. But if you have a different view or requirem= ents on S then this might not be a point to point session we are concern he= re in RMCAT.

I'm thinking of a topology where S is able to= shape the outgoing streams to fit the link between S and B you want to be = able to estimate the bandwidth on that link. How that shaping is done is of= minor interest, but I can imagine both stripping layers and transcoding.
=A0



S will have to change the timestamp offset (RFC 5450) of the RTP
packets to correspond to its send-time, but besides that all is fine.

Now let's add a third client (C). S will relay packets from both A and = C
to B, so ideally we should jointly process all of those packets when
estimating the bandwidth between S to B. However, packets sent from A
will be based on the tuple (RTP timestamp A, NTP timestamp A) and
packets sent from C will be based on (RTP timestamp C, NTP timestamp C), so we can't just convert to NTP at B and compare them. This can be
solved in the server by rewriting RTP and NTP timestamps to (RTP
timestamp S, NTP timestamp S) before relaying to B, which requires
rewriting both RTP packets and RTCP packets. This is fine as long as you rewrite _all_ streams from the same sending client in the same way,
otherwise you won't be able to synchronize them. Therefore all streams<= br> must go through the same server.

Again, you will have to explain the relation between A, C, B and S in detai= ls? Depending on that relation, it can turned out to be a multicast case, a= unicast case with all legs are handled separately or even a multi-party mu= lti-hop case which is out of scope right now. In the later case we should n= ot be so concerned now but if you want to change the charter then you are m= ore than welcomed from my part.

BR

--
Zahed

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN SARKER


Ericsson AB
Multimedia Technologies (MMT)
Ericsson Research
P.O. Box 920, SE-971 28, Lule=E5, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
zaheduzzaman.sarker@ericsson.com
www.= ericsson.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--00151759329ea0925604d1456697-- From holmer@google.com Thu Dec 20 01:34:15 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4F21F8651 for ; Thu, 20 Dec 2012 01:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L15646HROKkm for ; Thu, 20 Dec 2012 01:34:15 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3B21F8654 for ; Thu, 20 Dec 2012 01:34:14 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1517907bku.31 for ; Thu, 20 Dec 2012 01:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aJcgmMqPl/9VevuV18QXs4LLucx9I/3E9lvdm+Rv5tE=; b=PuMK7D7kMZF4zPxEq/31i5rZQUoYPt+xjKk+PqoF2tBNh7mPnw/yt6T6ucmWtZL8/n QO/snZouAjgyF6edDxDA7HnYZ4waM0dbcToq4ak0BQcqkAyWvrOc36tKSE4r+KHhIKel 1zPjPNsRQ4nGFvExb8pfKyskC6ocEScv1Kj3PajsPPseVJfWnHYVkASuPS6ZDKkKRRNv BhIqvURwiequXmLUqO9zzvnziqjm924tMwpX9qLIOCVtAYfjMhuYtvgphbLOTlnNl1fX RWoFaY3g4eb28DZ5odWjPggBLR3gmc+Ho9Azzp/iYyR+6qpypsl0KIkELacHgmFOxLZu vuHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=aJcgmMqPl/9VevuV18QXs4LLucx9I/3E9lvdm+Rv5tE=; b=DLkJVmYVKJ3+1uPvc/mPVdHAwnlU2k6mYShhFQtHaBXVWLbwMsMjwfg9lKmm0RscCl 2iqvohrAALl4joaIF9/HCE/LGPrX8DZKm4DHQOVLXutttnKpi+74nzBLCER+BER5111j ybVVx/hYZqSq2QdlPyrJ2pDq4WMvCNyi1zYe5qXSm2XK0IM8OnE+1lRVDYnafFGtHLoX 1oMqYL75MiF6mozLVVyzi+V71hh/uXOcG9IWdLoycpBL8P3f71KwGmTI0txUO1mM6ay/ 4bMzS8lKy5ZAhEqn9THvDozzsrzkEXf1cU36hJyaN7qFZ8Ty9UgSfiKFAV8Wj9+O8h/J bn6w== MIME-Version: 1.0 Received: by 10.204.151.21 with SMTP id a21mr4322425bkw.124.1355996053449; Thu, 20 Dec 2012 01:34:13 -0800 (PST) Sender: holmer@google.com Received: by 10.205.115.81 with HTTP; Thu, 20 Dec 2012 01:34:13 -0800 (PST) In-Reply-To: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <81564C0D7D4D2A4B9A86C8C7404A13DA06C8C9@ESESSMB205.ericsson.se> <50CF7445.60907@alvestrand.no> Date: Thu, 20 Dec 2012 10:34:13 +0100 X-Google-Sender-Auth: 4SJkBCJQdXfLC3q5W9iAl_7TQj8 Message-ID: From: Stefan Holmer To: "Michael Ramalho (mramalho)" Content-Type: multipart/alternative; boundary=0015175d6786152cb904d1456f59 X-Gm-Message-State: ALoCoQk9Ajkv2pWHOQ+miW4Wy6h8MB3iiHd8rfqDYfKDMSGEyhg19nTcsxKzD1Ai28zvcIxb5Ct+5I1zLLlttLnoPDon2xhA7W6xKCjNyjMkVtw/x0+lcT4PiveHPVXXNuRuRRlEBhNT+KKLTUohoggS/G51d3GNhX3ucXy32AxXf16ozM5FDjsMb6WC7fr4eHQR+RbNkHuw Cc: Ingemar Johansson S , Harald Alvestrand , "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 09:34:16 -0000 --0015175d6786152cb904d1456f59 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Dec 18, 2012 at 4:18 PM, Michael Ramalho (mramalho) < mramalho@cisco.com> wrote: > All,**** > > ** ** > > Re: =93As Stefan says - since we measure ~a moving average of difference > between the (receive timestamp - send timestamp) of successive packets, n= ot > an absolute transit time, value, this is not likely to be an issue.=94***= * > > ** ** > > I think this discussion is heading in the right direction =85 that is, an > absolute, transport-not-media-capture-related ability to generate one-way > delay DIFFERENCES =85 without a need to keep track of absolute time (e.g.= , > NTP) or detailed knowledge about the capture time. We are interested in > congestion measures here, not play out information in this discussion.***= * > > ** ** > > As one may recall, the discussion started from a premise of inter-arrival > time differences =85 which I didn=92t think was wise or appropriate (even > though a particular vendor happened to design a control based on > inter-arrival time). I preferred a mechanism to measure the relative > one-way time delay differences from which an inter-arrival time measure > could be calculated (if you wanted one). > What is your definition of "inter-arrival time differences" and "one-way time delay differences"? > **** > > ** ** > > The issue I have with the above is that I also think it is silly to > compute a moving average of the differences based on my original email on > this thread (knowing the delay histogram is one sided and that we can > EXPECT outliers). If there was non-linear filtering PRIOR TO a moving > average metric =85 then I would be happier =85 but that also doesn=92t ne= ed to be > specified in what we are trying to do with the timestamps on the wire. I > can do that non-linear filtering with the timestamps as we are proposing = in > this thread.**** > > ** ** > > Regards,**** > > ** ** > > Michael Ramalho, Ph.D.**** > > ** ** > > PS =96 Harold, until we specify what we need, a close approximation is to > take the RTP timestamp of the FIRST packet of a multi-packet video frame. > You will still have the OS and processing delay in there =85 but it is be= tter > than nothing.**** > > ** ** > > *From:* rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] *On Behalf > Of *Harald Alvestrand > *Sent:* Monday, December 17, 2012 2:37 PM > *To:* Ingemar Johansson S > *Cc:* rmcat@ietf.org > > *Subject:* Re: [rmcat] Send timestamps**** > > ** ** > > On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:**** > > Hi**** > > **** > > I believe that it can make sense to use a separate timestamp for > congestion control but I may need to read and understand some more. A few > reflections though.**** > > **** > > Unless I miss something, this is quite close to the TCP timestamps which > are used for congestion avoidance in TCP Vegas and LEDBAT. **** > > The problem in Vegas is that it is sensitive to congestion in the feedbac= k > path, not shure though how much concern that should be. **** > > If we keep a model of computation-at-receiver, it's not a problem at all. > > **** > > LEDBAT modifies this and implement the concept of base delay, but suffers > from late comers advantage.**** > > Both the above assume that one ACKs are returned to the sender almost > immediately (delay ACK adds some uncertanity here) also one don=92t need = to > synchronize clocks.**** > > Here I get unsure about what to do with the received timestamps, I guess > you can compute a delta between sent and received timestamp but unless yo= u > have exactly synchronized clocks in sender(s) and receiver(s), you will > have an unknown offset that can possibly also drift due to clock skew.***= * > > > As Stefan says - since we measure ~a moving average of difference between > the (receive timestamp - send timestamp) of successive packets, not an > absolute transit time, value, this is not likely to be an issue. > > I have a hard time imagining clock drift so severe that it will > significantly influence the deltas of packets that are sent less than a > second apart. Clock jumps (like leap seconds) may be a measurable, but > extremely transient, influence.**** > --0015175d6786152cb904d1456f59 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">


On Tue, Dec 18, 2012 at 4:18 PM, Michael Ramalho (mramalho) <mramalho@cisco.com> wrote:

All,=

=A0<= /p>

Re: =93As Stefan s= ays - since we measure ~a moving average of difference between the (receive= timestamp - send timestamp) of successive packets, not an absolute transit time, value, this is not likely to be an issue.=94

=A0<= /p>

I think this discussion i= s heading in the right direction =85 that is, an absolute, transport-not-me= dia-capture-related ability to generate one-way delay DIFFERENCES =85 without a need to keep track of absolute time (e.g., NTP) or detailed = knowledge about the capture time. We are interested in congestion measures = here, not play out information in this discussion.

=A0<= /p>

As one may recall, the di= scussion started from a premise of inter-arrival time differences =85 which= I didn=92t think was wise or appropriate (even though a particular vendor happened to design a control based on inter-arrival time). I prefer= red a mechanism to measure the relative one-way time delay differences from= which an inter-arrival time measure could be calculated (if you wanted one= ).


What is your definition = of "inter-arrival time differences" and "one-way time delay = differences"?
=A0
<= p class=3D"MsoNormal">

=A0<= /p>

The issue I have with the= above is that I also think it is silly to compute a moving average of the = differences based on my original email on this thread (knowing the delay histogram is one sided and that we can EXPECT outliers). If ther= e was non-linear filtering PRIOR TO a moving average metric =85 then I woul= d be happier =85 but that also doesn=92t need to be specified in what we ar= e trying to do with the timestamps on the wire. I can do that non-linear filtering with the timestamps as we are= proposing in this thread.

=A0<= /p>

Regards,

=A0<= /p>

Michael Ramalho, Ph.D.=

=A0<= /p>

PS =96 Harold, until we s= pecify what we need, a close approximation is to take the RTP timestamp of = the FIRST packet of a multi-packet video frame. You will still have the OS and processing delay in there =85 but it is better than nothin= g.

=A0<= /p>

From: rmcat-bounces@ietf.org [mailto:rmcat-bou= nces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, December 17, 2012 2:37 PM
To: Ingemar Johansson S
Cc: rmcat@ietf.org


Subject: Re: [rmcat] Send timestamps

=A0

On 12/17/2012 03:45 PM, Ingemar Johansson S wrote:

Hi

=A0<= /p>

I believe that it can mak= e sense to use a separate timestamp for congestion control but I may need t= o read and understand some more. A few reflections though.=

=A0<= /p>

Unless I miss something, = this is quite close to the TCP timestamps which are used for congestion avo= idance in TCP Vegas and LEDBAT.

The problem in Vegas is t= hat it is sensitive to congestion in the feedback path, not shure though ho= w much concern that should be.

If we keep a model of computation-at-receiver, it= 9;s not a problem at all.

LEDBAT modifies this and = implement the concept of base delay, but suffers from late comers advantage= .

Both the above assume tha= t one ACKs are returned to the sender almost immediately (delay ACK adds so= me uncertanity here) also one don=92t need to synchronize clocks.

Here I get unsure about w= hat to do with the received timestamps, I guess you can compute a delta bet= ween sent and received timestamp but unless you have exactly synchronized clocks in sender(s) and receiver(s), you will have an unknown= offset that can possibly also drift due to clock skew.


As Stefan says - since we measure ~a moving average of difference between t= he (receive timestamp - send timestamp) of successive packets, not an absol= ute transit time, value, this is not likely to be an issue.

I have a hard time imagining clock drift so severe that it will significant= ly influence the deltas of packets that are sent less than a second apart. = Clock jumps (like leap seconds) may be a measurable, but extremely transien= t, influence.


--0015175d6786152cb904d1456f59-- From zaheduzzaman.sarker@ericsson.com Fri Dec 21 05:12:20 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D532121F895C for ; Fri, 21 Dec 2012 05:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqqmA1Q4gUuy for ; Fri, 21 Dec 2012 05:12:19 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2064021F8953 for ; Fri, 21 Dec 2012 05:12:18 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-65-50d46031d9b0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2E.D5.04318.13064D05; Fri, 21 Dec 2012 14:12:18 +0100 (CET) Received: from [150.132.141.56] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 21 Dec 2012 14:12:17 +0100 Message-ID: <50D46031.1090207@ericsson.com> Date: Fri, 21 Dec 2012 14:12:17 +0100 From: Zaheduzzaman Sarker User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Stefan Holmer References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50D2D205.8040700@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Rtco4UqAwaE9rBZX959jsXjxYA6T xeqbH9gcmD2m/N7I6rFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyNv70L+gyrFhz5yxjA+NT 5S5GTg4JAROJ/jcdTBC2mMSFe+vZQGwhgZOMElfXl3QxcgHZaxglNq7dD1TEwcEroC0xu5sd pIZFQFXiy9HZbCBhNgEbiceL/UBMUYFgia7DYiAVvAKCEidnPmEBsUWAqq9/XsYIYjMLeEjc WncIrFNYQEXiwvwwiEW7mSSaD7eCXcApEChxad4ZZoh6W4kLc66zQNjyEs1bZzOD9AoJ6Ep0 vYybwCg4C8m2WUg6ZiHpWMDIvIqRPTcxMye93HwTIzA0D275bbCDcdN9sUOM0hwsSuK84a4X AoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwBhv93e2ybPkm7r9L2kyPT7bavLA8cm/8tav/ OhX2ym0zcV16Vdpef/8ziyWRnvqHeQ46vp148ofvzOP6ofePxy865ZLg5NyWsuB9xvmKWdZO P1sz9NKLeZ0VUhLXaWjskF1TxC3E5vhuX/2cTXd/3Q2qE0i87jb5/lejhFs3pVMPbYuYz1Hv oMRSnJFoqMVcVJwIAL9uxZMbAgAA Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 13:12:20 -0000 On 2012-12-20 10:31, Stefan Holmer wrote: > > > > On Thu, Dec 20, 2012 at 9:53 AM, Zaheduzzaman Sarker > > wrote: > > On 2012-12-17 12:00, Stefan Holmer wrote: > > I'll try to clarify with an example: > > Let's say we have two clients (A and B) in a call. We want to > estimate > the bandwidth from A to B by looking at the variations in > one-way delay, > which we can measure by comparing deltas in RTP timestamp to > deltas in > receive-time. The problem with using RTP timestamps is that those > represent capture time and not the send time of a frame, so we > get a lot > of noise related to variations in, e.g., video encoding time. > > > How big is this problem? can you show us some data showing where > this completely breaks or cause huge problem in estimating bandwidth? > > > I think it's a fairly big problem. We want to make sure the RTP > timestamp is set to correspond to when the frame was captured, while the > timestamp used for bandwidth estimation should be as close to sending > the frame/packet as possible. This is where I think we need data to show us what is the percentage of performance gain if we use send timestamp instead of RTP timestamp for bandwidth estimation. For instance if your CPU is temporarily > loaded you will get jitter similar to network congestion. I don't have > any numbers to show you though. what is the worst case here? If I take Google's proposed algorithm then it will result in a temporary "over-use". The sender may have to adapt. But that might be good (specially in case of multi-stream), may be the app itself is causing the CPU load :-). The CPU overload will be visible in other streams as well. Perhaps a smart co-relation can filter those event out, perhaps. > > > > around that we introduce RFC 5450 > > and now we can measure > something > > much closer to actual network time. If we want to jointly > process all > RTP streams from A to B (at the receiver, B) we can convert the RTP > timestamps of all streams to NTP using the (RTP timestamp, NTP > timestamp) tuple in the RTCP SR report. > > Now let's add a server (let's call it S) in between client A and > B. This > server simply relays RTP packets (and might do some rewriting as > well). > Now we want to estimate the bandwidth between A and S, and > between S and > B. > > > I think you will have to explain the topology a bit more in details > here. What kind of feedback loop you are assuming? why do you need > to estimate bandwidth between A-S and S-B separately? as I > understand it that a simple relay S will be transparent between A > and B and all we need to be concerned about delay visible between > A-B. But if you have a different view or requirements on S then this > might not be a point to point session we are concern here in RMCAT. > > > I'm thinking of a topology where S is able to shape the outgoing streams > to fit the link between S and B you want to be able to estimate the > bandwidth on that link. How that shaping is done is of minor interest, > but I can imagine both stripping layers and transcoding. It seems to me that this topology is out of scope of RMCAT. Here, S will have to manage A-S and S-B separately and S will have to handle RTCP report properly to reflect the shaping (I am using your terminology). A multi-hop case. The RMCAT only applies to A-S and S-B separately but not A-B in that picture. If S touches the media it will have to rewrite the RTP header inserting new RTP timestamps and etc. then A-S and S-B have different RTP timestamps to estimate corresponding bandwidth. Even if you think this topology is with in scope of RMCAT then I would again like to know how much we gain in performance by adding a new RTP header extension. If I have missed something, please correct me. > > > > > S will have to change the timestamp offset (RFC 5450) of the RTP > > packets to correspond to its send-time, but besides that all is > fine. > > Now let's add a third client (C). S will relay packets from both > A and C > to B, so ideally we should jointly process all of those packets when > estimating the bandwidth between S to B. However, packets sent > from A > will be based on the tuple (RTP timestamp A, NTP timestamp A) and > packets sent from C will be based on (RTP timestamp C, NTP > timestamp C), > so we can't just convert to NTP at B and compare them. This can be > solved in the server by rewriting RTP and NTP timestamps to (RTP > timestamp S, NTP timestamp S) before relaying to B, which requires > rewriting both RTP packets and RTCP packets. This is fine as > long as you > rewrite _all_ streams from the same sending client in the same way, > otherwise you won't be able to synchronize them. Therefore all > streams > must go through the same server. > > > Again, you will have to explain the relation between A, C, B and S > in details? Depending on that relation, it can turned out to be a > multicast case, a unicast case with all legs are handled separately > or even a multi-party multi-hop case which is out of scope right > now. In the later case we should not be so concerned now but if you > want to change the charter then you are more than welcomed from my part. > -- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================ From mramalho@cisco.com Fri Dec 21 06:16:04 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE37F21F84E8 for ; Fri, 21 Dec 2012 06:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atyWX7cxOreS for ; Fri, 21 Dec 2012 06:16:04 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 20E9121F84E3 for ; Fri, 21 Dec 2012 06:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4704; q=dns/txt; s=iport; t=1356099361; x=1357308961; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+2NoSIlTXjF2b7VrI1dQGsdR8gTdPn/dChgt27vpdDk=; b=IqaqT0EACOgr1Er6vWcd9jbLEqzrUtLuHf8WXHVQg1Jc4YRRI+zwOdi6 epN7rpIyAN7h6JsR1f/vIfxqyAi3ANmfySqcsWEx+3UeG98y9zzjG95+D QdcyDVP8EaaIuDCP+Svs7icfB0GiOTuU+2hnOcu7YLoz9MCN49NQY+giz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOZt1FCtJXG//2dsb2JhbABFvXsWc4IeAQEBBDoyCgMMBAIBCBEEAQEBChQJBzIUCQgCBAENBQgTh3i2OoxXg2JhA6ZTgnSBZAcdGg X-IronPort-AV: E=Sophos;i="4.84,329,1355097600"; d="scan'208";a="155535139" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 21 Dec 2012 14:16:00 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBLEG0NU030449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Dec 2012 14:16:00 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.15]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 08:16:00 -0600 From: "Michael Ramalho (mramalho)" To: Zaheduzzaman Sarker , Stefan Holmer Thread-Topic: [rmcat] Send timestamps Thread-Index: AQFp1qsmc/iz7p8QDa1Dm2vi5bzEBZjj9aEAgAFNK4CABJNkgIAACr2AgAHP64D//6jSsA== Date: Fri, 21 Dec 2012 14:15:59 +0000 Message-ID: References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50D2D205.8040700@ericsson.com> <50D46031.1090207@ericsson.com> In-Reply-To: <50D46031.1090207@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.168.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rmcat WG , "Mo Zanaty \(mzanaty\)" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:16:05 -0000 FWIW - I agree with Stefan. Comments below with "MAR:" Michael Ramalho -----Original Message----- From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of Z= aheduzzaman Sarker Sent: Friday, December 21, 2012 8:12 AM To: Stefan Holmer Cc: rmcat WG; Mo Zanaty (mzanaty) Subject: Re: [rmcat] Send timestamps On 2012-12-20 10:31, Stefan Holmer wrote: > > > > On Thu, Dec 20, 2012 at 9:53 AM, Zaheduzzaman Sarker=20 > > wrote: > > On 2012-12-17 12:00, Stefan Holmer wrote: > > I'll try to clarify with an example: > > Let's say we have two clients (A and B) in a call. We want to > estimate > the bandwidth from A to B by looking at the variations in > one-way delay, > which we can measure by comparing deltas in RTP timestamp to > deltas in > receive-time. The problem with using RTP timestamps is that those > represent capture time and not the send time of a frame, so we > get a lot > of noise related to variations in, e.g., video encoding time. > > > How big is this problem? can you show us some data showing where > this completely breaks or cause huge problem in estimating bandwidth? > > > I think it's a fairly big problem. We want to make sure the RTP=20 > timestamp is set to correspond to when the frame was captured, while=20 > the timestamp used for bandwidth estimation should be as close to=20 > sending the frame/packet as possible. This is where I think we need data to show us what is the percentage of per= formance gain if we use send timestamp instead of RTP timestamp for bandwid= th estimation. MAR: The magnitude of the "problem" depends on how you deal with the proble= m. MAR: Stefan is correct .. the usual RTP timestamp is representative of the = capture time ... ANYTHING in the processing in between the capture time and= the time a particular packet departs your NIC (potentially one of many fro= m that capture instant, I might add) will appear as a random process. OSs b= urp a lot as seen by a particular application process ... oftentimes due to= unrelated processes (such as encryption processes on my corporate machine,= ughh ... but I digress). MAR: Now, if your receive processing is "sophisticated enough", you MAY be = able to discard that "outlier" caused by such processing - but I can assure= you that you MUST EXPECT such outliers ... as there are other network sour= ces of occasional delay (such as what I mentioned at the beginning of this = thread ..sortware-only firewalls doing garbage collection and the like). MAR: So .. how exactly does one show the magnitude of the problem (what you= say as percentage of performance gain), when the "gain" is a function of h= ow intelligent a design is? You can't. MAR: The solution is to de-couple the problems and create a timestamp that = IS MORE representative of the transmit time than what we have now. I say "m= ore representative" because most of what we are proposing here is at the a= pplication, not kernel, level processing. For instance if your CPU is temporarily > loaded you will get jitter similar to network congestion. I don't have=20 > any numbers to show you though. what is the worst case here? If I take Google's proposed algorithm then it = will result in a temporary "over-use". The sender may have to adapt.=20 But that might be good (specially in case of multi-stream), may be the app = itself is causing the CPU load :-). MAR: Unless I am mistaken (the Google folks can correct me here) ... ONE ba= d data point (one packet having additional delay) creates TWO bad "inter-ar= rival datapoint" samples. That is error multiplication. Now unless their de= signers have developed an algorithm that discounts that effect BEFORE perfo= rming normal Euclidean processing on those two bad data points ... they wil= l take them as an "error" and then "square that error" in their estimator. = In other words, the bad data points have now biased the estimator! MAR: Now, hopefully, you will see the importance of getting as accurate of = data as possible - as engineers we don't want to ignore what is going on "b= ehind the math". Simple exponential moving averages work GREAT only for GAU= SSIAN processing - we KNOW we are dealing with one-sided, non-Gaussian PDV = processes. [Ditto for Kalman Filtering, but I don't have a better solution = ;-).] Let's try to get our underlying data as accurate/clean as we can get = it at reasonable (bandwidth/RTP header extension) cost. From mzanaty@cisco.com Sat Dec 22 13:31:56 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDC621F8889 for ; Sat, 22 Dec 2012 13:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scqceor128G4 for ; Sat, 22 Dec 2012 13:31:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 299F221F84DB for ; Sat, 22 Dec 2012 13:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49145; q=dns/txt; s=iport; t=1356211908; x=1357421508; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sFD4MY9t0PtHWJ8FMYWdGAxPuf7UgLua51mVI1T+e/E=; b=Uc888duPM5etH2XJdZbLKwJkQ5m0w7HQac2FFE1pNQ4ZZXTAI4eoVIK3 UY6KZT1L41eW5IG0BJl/iwfADQMiDoTCzJm1UWqsSZc5hFhkzZyTpVRxP KCCfWAVq5/uNq8C0rwYRVJy1iCONVxeTseVxZmLw5UitrCYlKANafipTi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAFMl1lCtJV2b/2dsb2JhbABEgkmyLAGJFhZzgh4BAQEDARoTOwoHBQsCAQgRBAEBCxYBBgcyFAkIAgQOBQgRh3QGDLUVjFeDYmEDklmET48sgnSBZAc3 X-IronPort-AV: E=Sophos;i="4.84,338,1355097600"; d="scan'208,217";a="155668225" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 22 Dec 2012 21:31:46 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBMLVkRo018265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Dec 2012 21:31:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sat, 22 Dec 2012 15:31:46 -0600 From: "Mo Zanaty (mzanaty)" To: Stefan Holmer Thread-Topic: [rmcat] Send timestamps Thread-Index: AQHN0gHghOHemZI0p0CqIdxtCIphjpgbkKuAgAG7dICAAAGcgP//4IVAgADLBAD//6vDMA== Date: Sat, 22 Dec 2012 21:31:45 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D90F6477E1@xmb-rcd-x14.cisco.com> <50CEFCBD.9030104@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F647D5B@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.242.236] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "rmcat@ietf.org" Subject: Re: [rmcat] Send timestamps X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 21:31:56 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stefan, I thought some more about your problem, and I think it is caused by your de= sire to map to NTP. While it may seem intuitively logical to map all receiv= ed packets to a single absolute NTP timeline, this may be unnecessary, and = possibly even harmful. What you really care about computing is d(i)=3Dt(i)-= t(i-1)-(T(i)-T(i-1)). If you map T(i) to NTP before computing deltas, you u= nnecessarily introduce conversion and mapping errors, which may be harmful = or negligible. If you simply compute deltas on T(i) directly, you avoid thi= s. If you want to process multiple streams, just compute deltas per stream = before feeding the computed d(i) into a single filter. Do you agree this wo= uld solve your problem? Some more comments below, but these details are mostly orthogonal to the co= re issue above. > Perhaps. I don't see why rewriting the full (RTP timestamp, NTP timestamp= ) tuple is necessary for other reasons though. The server needs to rewrite NTP in RTCP SR if it wants to compute RTT. Inst= ead of rewriting NTP on the wire, it could rewrite internally (i.e. maintai= n state internally for the NTP offset between source and server, so the NTP= echoed in RTCP RR from receivers can be converted from source to server ti= me). But this seems like equivalent or higher complexity (and possibly frag= ility) to maintain internal rewrites than rewrite on the wire. So I would n= ot consider this an advantage. More fundamental than any timestamps, servers must usually (always?) rewrit= e RTCP SR because they are rarely (never?) blindly forwarding all RTP packe= ts for the life of the session. For example, a source projection mixer that= switches video sources at keyframe boundaries based on active speaker audi= o levels. The source RTCP SRs will be periodic, not on keyframe boundaries,= so what the mixer decides to forward can differ from what the source sent = in that RTCP interval. The mixer effectively terminates and regenerates all= RTCP with rules more complex than its simple RTP forwarding behavior, so i= t can't simply forward RTCP. > The deltas only have a meaning in relation to the corresponding RTP times= tamp. Actually, the RFC 5450 offsets only relate to themselves, not directly to t= he RTP timestamp. See the example in section 3 where "the choice of x is es= sentially arbitrary". Also see the AVT archives circa 2005-2006 (search for= draft-singer-rtp-hdrext) for discussions about "true offset" as defined by= Ron vs. "deviation compared to a static delay" as defined by Magnus (which= is what the final RFC wording reflects). The problem RFC 5450 attempted to solve is exactly the same as RMCAT now wa= nts to solve with send timestamps, to separate source and network jitter, f= or "transmission rate adaptation" (Magnus' words). Happy Holidays! Mo From: Stefan Holmer [mailto:holmer@google.com] Sent: Monday, December 17, 2012 4:21 PM To: Mo Zanaty (mzanaty) Cc: Harald Alvestrand; rmcat@ietf.org Subject: Re: [rmcat] Send timestamps On Mon, Dec 17, 2012 at 9:15 PM, Mo Zanaty (mzanaty) > wrote: So we're back to two pendulums two months after deciding multi-hop is initi= ally out of scope. I'm glad, because it will likely be a major (or perhaps = even dominant) deployment scenario, which we should not defer based on comp= lexity alone. If we introduce a new send timestamp extension (which I'm unsure of the ben= efits over RFC 5450), I think it should be in NTP units not RTP media clock= units. There is a precedent (in RTCP) for NTP timestamps that are synced a= cross multiple RTP sessions, but there is no such precedent for synced RTP = timestamps. Different media types with different media clocks would also pr= esent problems for synced RTP timestamps. But even with this new send timestamp extension (using absolute synced NTP = timestamps), I don't think it avoids Stefan's problem of rewriting every RT= P and RTCP packet at the server. Every RTP packet must still be rewritten w= ith the new extension using the server's NTP time, and every RTCP SR packet= must still be rewritten for several reasons beyond congestion control. Perhaps. I don't see why rewriting the full (RTP timestamp, NTP timestamp) = tuple is necessary for other reasons though. The problem as I see it is when we, at the receiving client B, are to compu= te the delta between packets generated by A and packets generated by C. Eve= n if we convert them both to NTP, their NTP timestamps aren't likely to be = in sync. They can be if S has rewritten the RTCP SRs so that the NTP timest= amp of streams from A and C now are based on the clock of S (NTP timestamp = S). But when that has been done we also have to rewrite the RTCP SR of all = other streams from A and C which we at some point would like to have synchr= onized playback with, which will require all those streams to also go throu= gh S. So basically we will not be able to have to servers, S1 and S2, which= for example handle video and audio streams respectively. Maybe not a big issue, but to me it feels like a limitation without benefit= s. I don't see the point of requiring that timestamps used for congestion c= ontrol should be set in relation to the RTP timestamps which is meant for d= oing synchronized playback. So I really don't see any benefit that a new extension would provide beyond= RFC 5450. Perhaps I'm missing it. I'm also missing why you need to convert to NTP time in order to "jointly p= rocess all RTP streams", because only the deltas really matter not the actu= al NTP time, and RFC 5450 gives you all you need for deltas. The deltas only have a meaning in relation to the corresponding RTP timesta= mp. RTP timestamps of different streams (SSRCs) have different random offse= ts, and therefore can't be compared before converted to NTP. At least if yo= u want to calculate the delta between packets belonging from two different = streams. > If we want to jointly process all RTP streams from A to B (at the receive= r, B) we can convert the RTP timestamps of all streams to NTP using the (RT= P timestamp, NTP timestamp) tuple in the RTCP SR report. Mo From: rmcat-bounces@ietf.org [mailto:rmcat-b= ounces@ietf.org] On Behalf Of Harald Alvestr= and Sent: Monday, December 17, 2012 6:07 AM To: rmcat@ietf.org Subject: Re: [rmcat] Send timestamps Separating the timestamp used as a congestion signal from timestamps that m= ay be used for other purposes would seem to me to be an advantage in terms = of architectural cleanliness. RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient. Given that we won't have all systems deploying the new extension from Day O= ne, we need to be able to fall back to the RTP timestamp (it's better than = nothing), but it seems we shouldn't marry it more than we have to. Harald On 12/17/2012 12:00 PM, Stefan Holmer wrote: I'll try to clarify with an example: Let's say we have two clients (A and B) in a call. We want to estimate the = bandwidth from A to B by looking at the variations in one-way delay, which = we can measure by comparing deltas in RTP timestamp to deltas in receive-ti= me. The problem with using RTP timestamps is that those represent capture t= ime and not the send time of a frame, so we get a lot of noise related to v= ariations in, e.g., video encoding time. To get around that we introduce RF= C 5450 and now we can measure something= much closer to actual network time. If we want to jointly process all RTP = streams from A to B (at the receiver, B) we can convert the RTP timestamps = of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in the= RTCP SR report. Now let's add a server (let's call it S) in between client A and B. This se= rver simply relays RTP packets (and might do some rewriting as well). Now w= e want to estimate the bandwidth between A and S, and between S and B. S wi= ll have to change the timestamp offset (RFC 5450) of the RTP packets to cor= respond to its send-time, but besides that all is fine. Now let's add a third client (C). S will relay packets from both A and C to= B, so ideally we should jointly process all of those packets when estimati= ng the bandwidth between S to B. However, packets sent from A will be based= on the tuple (RTP timestamp A, NTP timestamp A) and packets sent from C wi= ll be based on (RTP timestamp C, NTP timestamp C), so we can't just convert= to NTP at B and compare them. This can be solved in the server by rewritin= g RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relay= ing to B, which requires rewriting both RTP packets and RTCP packets. This = is fine as long as you rewrite _all_ streams from the same sending client i= n the same way, otherwise you won't be able to synchronize them. Therefore = all streams must go through the same server. I'm suggesting that we could introduce a new "send timestamp" which doesn't= relate to the RTP timestamp (which is used for synchronized playback). Whe= never a packet is sent (no matter if it's sent from A, C or S) it will be s= tamped with the send-time taken from the clock of that sender, for instance= at 1 kHz or 90 kHz. Since it's not related to the RTP timestamp we won't h= ave to rewrite the (RTP, NTP) tuple, and actually, we don't even have to co= nvert to NTP at the receiver since all send timestamps are taken directly f= rom the same clock. Removing the relation to the RTP timestamp is what I me= an with an "absolute" timestamp (i.e., not relative to RTP timestamp). /Stefan On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) > wrote: Please clarify "absolute". Do you mean another RTP timestamp using the same= units but a random offset from the main RTP timestamp, and no implied sync= across multiple RTP sessions? Or NTP timestamps with NTP units and implied= sync across all RTP sessions (within the same sync domain, currently defin= ed to be CNAME)? Please also clarify "relay conference server", as there are many RTP topolo= gies for conferencing. I think you are probably referring to a source proje= ction mixer. Rewriting RTCP is standard practice for those, as well as most= mixers. In fact, I can't envision when it would be possible to blindly rel= ay RTCP in any mixer/topology. So I'm not sure what complications you see a= rising from the use of RFC 5450. Mo From: rmcat-bounces@ietf.org [mailto:rmcat-b= ounces@ietf.org] On Behalf Of Stefan Holmer Sent: Tuesday, December 04, 2012 4:23 AM To: rmcat WG Subject: [rmcat] Send timestamps Hi, In draft-alvestrand-rtcweb-congestion-01 we proposed using a send timestamp RTP head= er extension for measuring the packet inter-arrival time offset. In 02 this was revi= sed to instead reference RFC 5450, whic= h specifies a header extension for specifying the send timestamp as an offs= et relative to the RTP timestamp. Thinking further about this, there seems to be a couple of benefits with de= fining a new, absolute, send timestamp header extension. If a relay approac= h to conference servers are used, the relaying server can simply rewrite th= e send timestamp of a packet to correspond to the time it was relayed. Doin= g so the receiver can jointly process all streams being received from the r= elay server, even though they were initially captured and sent by different= senders (with different clocks). With a send timestamp offset, accomplishing the same thing would require re= writing both the timestamp offset and the NTP time in the corresponding RTC= P SR reports. And to keep video synchronized with audio the RTCP packet for= the audio streams must also be rewritten in a similar way. This may not ev= en be possible if the audio stream is relayed through a different server. Do you see any problems with using an RTP header extension with absolute se= nd timestamps? Are there any benefits with the send timestamp offset header= extension I might be missing? /Stefan --_000_3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stefan,

 

I thought some more about your problem,= and I think it is caused by your desire to map to NTP. While it may seem i= ntuitively logical to map all received packets to a single absolute NTP timeline, this may be unnecessary, and possibly even harmful.= What you really care about computing is d(i)=3Dt(i)-t(i-1)-(T(i)-T(i-1)). = If you map T(i) to NTP before computing deltas, you unnecessarily introduce= conversion and mapping errors, which may be harmful or negligible. If you simply compute deltas on T(i) directl= y, you avoid this. If you want to process multiple streams, just compute de= ltas per stream before feeding the computed d(i) into a single filter. Do y= ou agree this would solve your problem?

 

Some more comments below, but these det= ails are mostly orthogonal to the core issue above.

 

> Perhaps. I don't see why rewriting the full (RTP timestam= p, NTP timestamp) tuple is necessary for other reasons though.

 

The server needs to rewrite NTP in RTCP= SR if it wants to compute RTT. Instead of rewriting NTP on the wire, it co= uld rewrite internally (i.e. maintain state internally for the NTP offset between source and server, so the NTP echoed in RTCP RR fro= m receivers can be converted from source to server time). But this seems li= ke equivalent or higher complexity (and possibly fragility) to maintain int= ernal rewrites than rewrite on the wire. So I would not consider this an advantage.

 

More fundamental than any timestamps, s= ervers must usually (always?) rewrite RTCP SR because they are rarely (neve= r?) blindly forwarding all RTP packets for the life of the session. For example, a source projection mixer that switches video source= s at keyframe boundaries based on active speaker audio levels. The source R= TCP SRs will be periodic, not on keyframe boundaries, so what the mixer dec= ides to forward can differ from what the source sent in that RTCP interval. The mixer effectively terminat= es and regenerates all RTCP with rules more complex than its simple RTP for= warding behavior, so it can’t simply forward RTCP.<= /p>

 

> The deltas only have a meaning in relation to the corresp= onding RTP timestamp.

 

Actually, the RFC 5450 offsets only rel= ate to themselves, not directly to the RTP timestamp. See the example in se= ction 3 where “the choice of x is essentially arbitrary”. Also see the AVT archives circa 2005-2006 (search for draft-singer-rtp-hdr= ext) for discussions about “true offset” as defined by Ron vs. = “deviation compared to a static delay” as defined by Magnus (wh= ich is what the final RFC wording reflects).

 

The problem RFC 5450 attempted to solve= is exactly the same as RMCAT now wants to solve with send timestamps, to s= eparate source and network jitter, for “transmission rate adaptation” (Magnus’ words).

 

Happy Holidays!

Mo

 

 

From: Stefan H= olmer [mailto:holmer@google.com]
Sent: Monday, December 17, 2012 4:21 PM
To: Mo Zanaty (mzanaty)
Cc: Harald Alvestrand; rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

 

 = ;

On Mon, Dec 17, 2012 at 9:15 PM, Mo Zanat= y (mzanaty) <mzanaty@cisco.com> wrote:

So we’re back to two pendulums two months after= deciding multi-hop is initially out of scope. I’m glad, because it will likely be a major (or perhaps even dominant) deployment scenario, = which we should not defer based on complexity alone.

 

If we introduce a new send timestamp extension (which= I’m unsure of the benefits over RFC 5450), I think it should be in NTP units not RTP media clock units. There is a precedent (in RTCP) = for NTP timestamps that are synced across multiple RTP sessions, but there = is no such precedent for synced RTP timestamps. Different media types with = different media clocks would also present problems for synced RTP timestamps.

 

But even with this new send timestamp extension (usin= g absolute synced NTP timestamps), I don’t think it avoids Stefan’s problem of rewriting every RTP and RTCP packet at the serve= r. Every RTP packet must still be rewritten with the new extension using th= e server’s NTP time, and every RTCP SR packet must still be rewritten= for several reasons beyond congestion control.

 

Perhaps. I don't see why rewriting the fu= ll (RTP timestamp, NTP timestamp) tuple is necessary for other reasons thou= gh.

 

The problem as I see it is when we, at th= e receiving client B, are to compute the delta between packets generated by= A and packets generated by C. Even if we convert them both to NTP, their NTP timestamps aren't likely to be in sync. They can be if S= has rewritten the RTCP SRs so that the NTP timestamp of streams from A and= C now are based on the clock of S (NTP timestamp S). But when that has bee= n done we also have to rewrite the RTCP SR of all other streams from A and C which we at some point would lik= e to have synchronized playback with, which will require all those streams = to also go through S. So basically we will not be able to have to servers, = S1 and S2, which for example handle video and audio streams respectively.

 

Maybe not a big issue, but to me it feels= like a limitation without benefits. I don't see the point of requiring tha= t timestamps used for congestion control should be set in relation to the RTP timestamps which is meant for doing synchronized playb= ack.

 

 

So I really don’t see any benefit that a new ex= tension would provide beyond RFC 5450. Perhaps I’m missing it.=

 

I’m also missing why you need to convert to NTP= time in order to “jointly process all RTP streams”, because on= ly the deltas really matter not the actual NTP time, and RFC 5450 gives you a= ll you need for deltas.

 

The deltas only have a meaning in relatio= n to the corresponding RTP timestamp. RTP timestamps of different streams (= SSRCs) have different random offsets, and therefore can't be compared before converted to NTP. At least if you want to calculate the= delta between packets belonging from two different streams.

 

 

> If we want to jointly process all RTP streams fr= om A to B (at the receiver, B) we can convert the RTP timestamps of all streams to NTP using the (RTP timestamp, NTP timestamp) tuple in th= e RTCP SR report.

 

Mo

 

 

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces= @ietf.org] On Behalf Of Harald Alvestrand
Sent: Monday, December 17, 2012 6:07 AM


To: rmcat@ietf.org
Subject: Re: [rmcat] Send timestamps

 

Separating the timestamp used as a congestion signal from timestam= ps that may be used for other purposes would seem to me to be an advantage = in terms of architectural cleanliness.



RTP timestamps need to reflect media time. In a situation with relay nodes = and changing paths, this may have uncomfortable amounts of variation from t= he time the packets enter the last hop to the recipient.

Given that we won't have all systems deploying the new extension from Day O= ne, we need to be able to fall back to the RTP timestamp (it's better than = nothing), but it seems we shouldn't marry it more than we have to.

            &nb= sp; Harald

On 12/17/2012 12:00 PM, Stefan Holmer wrote:

I'll try to clarify with an example:

 

Let's say we have two clients (A and B) in a call. We w= ant to estimate the bandwidth from A to B by looking at the variations in one-way delay, which we can measure by comparing deltas in R= TP timestamp to deltas in receive-time. The problem with using RTP timestam= ps is that those represent capture time and not the send time of a frame, s= o we get a lot of noise related to variations in, e.g., video encoding time. To get around that we introdu= ce RFC 5450 and now we can measure something much closer to actual network time. If we wan= t to jointly process all RTP streams from A to B (at the receiver, B) we ca= n convert the RTP timestamps of all streams to NTP using the (RTP timestamp= , NTP timestamp) tuple in the RTCP SR report.

 

Now let's add a server (let's call it S) in between cli= ent A and B. This server simply relays RTP packets (and might do some rewriting as well). Now we want to estimate the bandwidth between = A and S, and between S and B. S will have to change the timestamp offset (R= FC 5450) of the RTP packets to correspond to its send-time, but besides tha= t all is fine.

 

Now let's add a third client (C). S will relay packets = from both A and C to B, so ideally we should jointly process all of those packets when estimating the bandwidth between S to B. However= , packets sent from A will be based on the tuple (RTP timestamp A, NTP time= stamp A) and packets sent from C will be based on (RTP timestamp C, NTP tim= estamp C), so we can't just convert to NTP at B and compare them. This can be solved in the server by rewritin= g RTP and NTP timestamps to (RTP timestamp S, NTP timestamp S) before relay= ing to B, which requires rewriting both RTP packets and RTCP packets. This = is fine as long as you rewrite _all_ streams from the same sending client in the same way, otherwise you won't = be able to synchronize them. Therefore all streams must go through the same= server.

 

I'm suggesting that we could introduce a new "send= timestamp" which doesn't relate to the RTP timestamp (which is used for synchronized playback). Whenever a packet is sent (no matter if i= t's sent from A, C or S) it will be stamped with the send-time taken from t= he clock of that sender, for instance at 1 kHz or 90 kHz. Since it's not re= lated to the RTP timestamp we won't have to rewrite the (RTP, NTP) tuple, and actually, we don't even have to = convert to NTP at the receiver since all send timestamps are taken directly= from the same clock. Removing the relation to the RTP timestamp is what I = mean with an "absolute" timestamp (i.e., not relative to RTP timestamp).

 

/Stefan

 

On Sun, Dec 16, 2012 at 4:08 PM, Mo Zanaty (mzanaty) &l= t;= mzanaty@cisco.com> wrote:

Please clarify “absolute”. Do you mean an= other RTP timestamp using the same units but a random offset from the main RTP timestamp, and no implied sync across multiple RTP sessions? Or N= TP timestamps with NTP units and implied sync across all RTP sessions (with= in the same sync domain, currently defined to be CNAME)?<= /p>

 

Please also clarify “relay conference server= 221;, as there are many RTP topologies for conferencing. I think you are probably referring to a source projection mixer. Rewriting RTCP is standar= d practice for those, as well as most mixers. In fact, I can’t envisi= on when it would be possible to blindly relay RTCP in any mixer/topology. S= o I’m not sure what complications you see arising from the use of RFC 5450.

 

Mo

 

From: rmcat-bounces@ietf.org [mailto:rmcat-bounces= @ietf.org] On Behalf Of Stefan Holmer
Sent: Tuesday, December 04, 2012 4:23 AM
To: rmcat WG
Subject: [rmcat] Send timestamps

 

Hi,

 

In draft-alvestrand-rtcweb-congestion-01=  we proposed using a send timestamp RTP header extension for measuring the pac= ket inter-arrival time offset. In 02 this wa= s revised to instead reference RFC 5450, which specifi= es a header extension for specifying the send timestamp as an offset relative t= o the RTP timestamp.

 

Thinking further about this, there seems to be a couple= of benefits with defining a new, absolute, send timestamp header extension. If a relay approach to conference servers are used, the = relaying server can simply rewrite the send timestamp of a packet to corres= pond to the time it was relayed. Doing so the receiver can jointly process = all streams being received from the relay server, even though they were initially captured and sent by dif= ferent senders (with different clocks). 

 

With a send timestamp offset, accomplishing the same th= ing would require rewriting both the timestamp offset and the NTP time in the corresponding RTCP SR reports. And to keep video synch= ronized with audio the RTCP packet for the audio streams must also be rewri= tten in a similar way. This may not even be possible if the audio stream is= relayed through a different server.

 

Do you see any problems with using an RTP header extens= ion with absolute send timestamps? Are there any benefits with the send timestamp offset header extension I might be missing?=

 

/Stefan

 

 

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F64D3E9xmbrcdx14ciscoc_-- From michawe@ifi.uio.no Sat Dec 29 05:30:47 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6441421F85E2 for ; Sat, 29 Dec 2012 05:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N0P1Q7wnjka for ; Sat, 29 Dec 2012 05:30:46 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 214B521F85DF for ; Sat, 29 Dec 2012 05:30:45 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TowUu-0003kx-Oq for rmcat@ietf.org; Sat, 29 Dec 2012 14:30:44 +0100 Received: from 089144206246.atnat0015.highway.a1.net ([89.144.206.246] helo=[192.168.1.4]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TowUt-0007nU-GC for rmcat@ietf.org; Sat, 29 Dec 2012 14:30:44 +0100 From: Michael Welzl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> Date: Sat, 29 Dec 2012 14:30:39 +0100 To: "rmcat@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 2 total rcpts 1025 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6806240F583106280607DD5B0AE2792D8BD2D098 X-UiO-SPAM-Test: remote_host: 89.144.206.246 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5 max/h 3 blacklist 0 greylist 0 ratelimit 0 Subject: [rmcat] Several comments about RRTCC X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 13:30:47 -0000 Dear all, I / we have found a number of potential issues with = draft-alvestrand-rtcweb-congestion-03, and would like to share them with = the group. I have shared some but not all of these thoughts directly = with the authors in the past, but I think it's useful to have them put = together in a list. 1) The RRTCC acronym. The draft luckily doesn't contain it, but I think the = mechanism should have an acronym anyway. I have to search through my = mailbox every time to see if RRTCC is really what it was called=85 may I = propose "DemiResi" ? (Delay minimization with reduced signaling) = "Resi" also gives you plenty of nice associations to mountains=85 cows=85 = yodeling=85 red-white plaid skirts and Lederhosen! Easier to remember = than RRTCC, no doubt! To get you guys used to the idea, I will call it = DemiResi in my text below :-) 2) Given that minimizing the amount of feedback seems to be a goal, this = feedback becomes very important. Losing a TCP ACK isn't a big deal, but = losing a DemiResi feedback message is. Given the minimal space needed = (essentially, one bit =85 plus a little more, to avoid ambiguity etc.), = I think we should introduce "acks-of-acks", i.e. a message that says "I = got your feedback". Yes, that message would only appear at the receiver = within one RTT, but if the sender's timeout (2x t_max_fb_interval) is = larger than an RTT, it could help to make the receiver retransmit its = feedback early when that message is missing. Personally I'm not = convinced that it's a good idea to send less than a message / RTT = anyway, in which case such ACKs-of-ACKs could still be useful, as they = would disambiguate forward from backward loss. For instance, the next = message could then tell the sender "don't reduce your rate because of = the loss that you see, it's only the backward path". 3) The TCP steady-state throughput equation from RFC3448 (in what follows, = I will call it "TFRC equation") is rather sensitive to the correct usage = of p, the packet loss event ratio. The way it is used in the draft, p is = packet loss but not the loss event ratio. Correct usage would require = sending loss events from the receiver to the sender (DCCP has a way to = do this), or, which would strike me as being much simpler, calculating = this equation on the receiver side. The receiver has all the information = about packet loss available. This would require the receiver to have = some notion of the RTT, which it could get e.g. if item 2) above is = implemented. 4) The text on page 12 of the draft reads as if it would be impossible for = the receive-side estimate of the available bandwidth A(i) to go below = the value obtained with the TFRC equation. If it does, however, DemiResi = becomes like some form of TFRC, even in the absence of other TCPs. Can = we be sure that this won't happen? It could be an idea to fall back to = such TFRC-like behavior only if loss is large enough to indicate that = we're competing with TCP=85 we might not always, and when we're not, we = should keep delay low. 5) The thresholds on page 12 seem troublesome to me: the behavior stays = unchanged in the 2-10% loss regime (this is high loss!), it is reduced = in proportion to the loss ratio in case of above 10% (seems reasonable, = except that 10% is already quite extreme), BUT: "As long as less than 2% = of the packets have been lost As(i) will be increased as = As(i)=3D1.05(As(i-1)+1000)" =85. this latter item means that, as long as we're below 2% loss, the = mechanism increases its rate, making 2% its loss target?! This strikes = me as rather odd for a mechanism that's supposed to avoid loss and delay = and keep queues low. Again, if this is done for interoperation with TCP, = it could be an idea to do it only when loss is above a certain = percentage (as it would be caused by TCP). 6) Rather obviously, ECN should be incorporated... Surely there's more stuff to find. I guess my main criticism is that we = still don't have a paper, a technical report, simulation code or a = simple standalone implementation to play with. Simply not enough data. I hope this was constructive... Cheers, Michael From sergio.garcia.murillo@gmail.com Mon Dec 31 01:58:22 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A230821F8B59 for ; Mon, 31 Dec 2012 01:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trA4Jmxkr3+w for ; Mon, 31 Dec 2012 01:58:22 -0800 (PST) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id A218121F8B57 for ; Mon, 31 Dec 2012 01:58:21 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id je9so5425648bkc.13 for ; Mon, 31 Dec 2012 01:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=reoPl0XfkWRnMaBCn+Y6TwaV1d8d81A4BDd/YBwIPXE=; b=FzXl7kuLckbwG5iw4cxKtihQaqvGvsADP0AU1tBCjBCOzEo8JpWHbv98op5i4V2iRE BE5sehdCSnIQRZeT+iRNoBWtAhPM4M7bdRePQF6dahsmhWatofFQsMVHnXcj8OMLM3xy 4HY/HNexn32v9+wt//jcyKeulwUdBFW3vWXEPE3JFLg3sFU/HkhAnTCE61AtR0OnrDrf 9/9ixGnC7DXZFTTj8o/yON5PZu4PPP+lP6KlJQs/Oz2YEewSxLRIhbdjXT+XLnZgsmqP kwV0TTFHkY97iXZ6I5hF6xrkoJAkRMRk9Uq7pnv6OJd2tjZwR2+cC57N1+PQNukWnKu+ v/5Q== X-Received: by 10.204.143.147 with SMTP id v19mr18845374bku.32.1356947900461; Mon, 31 Dec 2012 01:58:20 -0800 (PST) Received: from [192.168.1.65] (164.Red-79-145-154.dynamicIP.rima-tde.net. [79.145.154.164]) by mx.google.com with ESMTPS id o9sm27088475bko.15.2012.12.31.01.58.18 (version=SSLv3 cipher=OTHER); Mon, 31 Dec 2012 01:58:19 -0800 (PST) Message-ID: <50E161C8.8040009@gmail.com> Date: Mon, 31 Dec 2012 10:58:32 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> In-Reply-To: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rmcat] Several comments about RRTCC X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 09:58:22 -0000 El 29/12/2012 14:30, Michael Welzl escribió: > [..] > 5) > The thresholds on page 12 seem troublesome to me: the behavior stays unchanged in the 2-10% loss regime (this is high loss!), it is reduced in proportion to the loss ratio in case of above 10% (seems reasonable, except that 10% is already quite extreme), BUT: "As long as less than 2% of the packets have been lost As(i) will be increased as As(i)=1.05(As(i-1)+1000)" > …. this latter item means that, as long as we're below 2% loss, the mechanism increases its rate, making 2% its loss target?! This strikes me as rather odd for a mechanism that's supposed to avoid loss and delay and keep queues low. Again, if this is done for interoperation with TCP, it could be an idea to do it only when loss is above a certain percentage (as it would be caused by TCP). If i understood the paper correctly, if both sender and receiver implements it, the overuse detector will be triggered before the 2-10% ratio is reached, so in theory it is safe to increase the rate as the packets lost would not be associated to congestion. The problem comes when the receiver doesn't not implement its part, and then I agree with you that a 2-10% loss without any extra mechanism would provide a very bad experience. If FEC/RED are used, then maybe the loss is not noticeable, but haven't tried that myself yet. Also, there may be some other codec specific solutions that could make the 2-10% loss to not be a problem, like periodic intra refresh, disposable frames, etc.. > [..] > > Surely there's more stuff to find. I guess my main criticism is that we still don't have a paper, a technical report, simulation code or a simple standalone implementation to play with. Simply not enough data. > I have been trying to implement the algorithm myself in my MCU and found quite some problems, especially with the initial values of the parameters, but after checking the google webrtc implementation I have quite positive results with the overuse detector. Haven't got much luck yet with the bitrate estimator. I am also starting to implement some testing tools to help me in the implementation and troubleshooting, I will keep you posted when they are stable enough for playing. Maybe it is stupid, but on the bitrate estimator, given that "Not until over-use has been detected for at least gamma_2 milliseconds and at least gamma_3 frames, a definitive over-use will be signaled.", couldn't we use the bitrate received during that period as a valid bitrate estimation of the available bandwidth? On a last note, I believe that the algorithm will work much better if the codecs are able to produce output bitrates as closed as the target bitrate as possible (i.e. almost CBR). Which seems to be confirmed by a comment in google's code: // We try to filter out very late frames. For instance periodic key // frames doesn't fit the Gaussian model well. Best regards Sergio From michawe@ifi.uio.no Mon Dec 31 03:06:44 2012 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176EF21F86BA for ; Mon, 31 Dec 2012 03:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9N+cEuqfwTN for ; Mon, 31 Dec 2012 03:06:43 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 03ADC21F8502 for ; Mon, 31 Dec 2012 03:06:42 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TpdCb-0003YG-3K; Mon, 31 Dec 2012 12:06:41 +0100 Received: from 089144206060.atnat0015.highway.a1.net ([89.144.206.60] helo=[192.168.1.6]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TpdCa-0001ts-3R; Mon, 31 Dec 2012 12:06:41 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <50E161C8.8040009@gmail.com> Date: Mon, 31 Dec 2012 12:06:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <226C9AC4-1699-4784-BCCA-54F9BF603B48@ifi.uio.no> References: <0FCEA7FA-7DC3-4D18-9D24-B41DDBB4F5B7@ifi.uio.no> <50E161C8.8040009@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 1041 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B645F7ECB4107FE619C0CAFF910636DDFDB49E8B X-UiO-SPAM-Test: remote_host: 89.144.206.60 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7 max/h 3 blacklist 0 greylist 0 ratelimit 0 Cc: rmcat@ietf.org Subject: Re: [rmcat] Several comments about RRTCC X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 11:06:44 -0000 On Dec 31, 2012, at 10:58 AM, Sergio Garcia Murillo = wrote: > El 29/12/2012 14:30, Michael Welzl escribi=F3: >> [..] >> 5) >> The thresholds on page 12 seem troublesome to me: the behavior stays = unchanged in the 2-10% loss regime (this is high loss!), it is reduced = in proportion to the loss ratio in case of above 10% (seems reasonable, = except that 10% is already quite extreme), BUT: "As long as less than 2% = of the packets have been lost As(i) will be increased as = As(i)=3D1.05(As(i-1)+1000)" >> =85. this latter item means that, as long as we're below 2% loss, the = mechanism increases its rate, making 2% its loss target?! This strikes = me as rather odd for a mechanism that's supposed to avoid loss and delay = and keep queues low. Again, if this is done for interoperation with TCP, = it could be an idea to do it only when loss is above a certain = percentage (as it would be caused by TCP). >=20 > If i understood the paper correctly, if both sender and receiver = implements it, the overuse detector will be triggered before the 2-10% = ratio is reached, so in theory it is safe to increase the rate as the = packets lost would not be associated to congestion. The problem comes = when the receiver doesn't not implement its part, and then I agree with = you that a 2-10% loss without any extra mechanism would provide a very = bad experience. If FEC/RED are used, then maybe the loss is not = noticeable, but haven't tried that myself yet. Also, there may be some = other codec specific solutions that could make the 2-10% loss to not be = a problem, like periodic intra refresh, disposable frames, etc.. Assuming that up to 2% loss isn't necessarily due to congestion also = means that the mechanism rather heavily relies on delay. Whether we use = OWD, IPG=85 either way, it's a pretty unreliable signal, e.g. noise can = be introduced by multiple bottlenecked links, and it loses granularity = when AQM is used or queues are short. I'm not arguing against the = general use of a delay measure - but I'm not sure I like the idea of = assuming: unless a delay based over-use detector fires, losses are not = due to congestion. >> [..] >>=20 >> Surely there's more stuff to find. I guess my main criticism is that = we still don't have a paper, a technical report, simulation code or a = simple standalone implementation to play with. Simply not enough data. >>=20 >=20 > I have been trying to implement the algorithm myself in my MCU and = found quite some problems, especially with the initial values of the = parameters, but after checking the google webrtc implementation I have = quite positive results with the overuse detector. Haven't got much luck = yet with the bitrate estimator. I am also starting to implement some = testing tools to help me in the implementation and troubleshooting, I = will keep you posted when they are stable enough for playing. Cool! I'll leave it to the authors to answer your notes below (my own answer = would be "not sure, would have to dig deeper into the scheme again"). Cheers, Michael > Maybe it is stupid, but on the bitrate estimator, given that "Not = until over-use has been detected for at least gamma_2 milliseconds and = at least gamma_3 frames, a definitive over-use will be signaled.", = couldn't we use the bitrate received during that period as a valid = bitrate estimation of the available bandwidth? >=20 > On a last note, I believe that the algorithm will work much better if = the codecs are able to produce output bitrates as closed as the target = bitrate as possible (i.e. almost CBR). Which seems to be confirmed by a = comment in google's code: >=20 > // We try to filter out very late frames. For instance periodic key > // frames doesn't fit the Gaussian model well. >=20 > Best regards > Sergio