Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Colin Perkins <csp@csperkins.org> Wed, 21 September 2011 20:31 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBE721F8BBD for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 13:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.552
X-Spam-Level:
X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC60BWLPdgvl for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 13:31:53 -0700 (PDT)
Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id B021521F8BBC for <rtcweb@ietf.org>; Wed, 21 Sep 2011 13:31:53 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6TUs-0006MN-jw; Wed, 21 Sep 2011 20:34:22 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com>
Date: Wed, 21 Sep 2011 21:34:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79 D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1084)
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2011 20:31:54 -0000

On 21 Sep 2011, at 20:30, Hadriel Kaplan wrote:
> On Sep 21, 2011, at 8:17 AM, Magnus Westerlund wrote:
>> On 2011-09-21 11:02, Hadriel Kaplan wrote:
>>> On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote:
>>>> If I interpret this correctly, you are arguing that an RTCWEB 
>>>> implementation shall support a remote end-point that doesn't
>>>> support RTCP.
>>> 
>>> Yes, although we could make that allowance/exception for audio only - in fact, G.711 only if it comes down to it.
>> 
>> Well, I don't know if we can argue that one past the Transport Area
>> Director?
> 
> Hmmm… how about by pointing out this is RTP over UDP and not TCP, and that we're following RFC 3550, which does not mandate reception of RTCP to continue the session?  I would think a Transport Area AD would know how UDP works. ;)
> 
> 
>> I know I can argue 400 bps as an acceptable non congestion
>> controlled rate. And that is because that is the equivalent of a full
>> backed off TCP connection that sends one full Ethernet frame every 30
>> seconds. We probably can argue 4kbps also as an acceptable rate. But
>> getting to the next magnitude is more problematic, especially in the
>> light that there still exist a reasonable large number of access links
>> around the world that don't have more than a few 10kbps in capacity.
> 
> Then the call quality will suck and the user will hang up.
> 
> BTW, are you suggesting that even with G.711, that rtcweb do some form of congestion control based on the RTCP packets?  At that point we're not even talking about RTP/AVP for PCMU/PCMA then are we?  This is some new profile, not AVP.


Well, the AVP spec [RFC3551, page 5] does say:

      If best-effort service is being used, RTP receivers SHOULD monitor
      packet loss to ensure that the packet loss rate is within
      acceptable parameters.  Packet loss is considered acceptable if a
      TCP flow across the same network path and experiencing the same
      network conditions would achieve an average throughput, measured
      on a reasonable timescale, that is not less than the RTP flow is
      achieving.  This condition can be satisfied by implementing
      congestion control mechanisms to adapt the transmission rate (or
      the number of layers subscribed for a layered multicast session),
      or by arranging for a receiver to leave the session if the loss
      rate is unacceptably high.

      The comparison to TCP cannot be specified exactly, but is intended
      as an "order-of-magnitude" comparison in timescale and throughput.
      The timescale on which TCP throughput is measured is the round-
      trip time of the connection.  In essence, this requirement states
      that it is not acceptable to deploy an application (using RTP or
      any other transport protocol) on the best-effort Internet which
      consumes bandwidth arbitrarily and does not compete fairly with
      TCP within an order of magnitude.


-- 
Colin Perkins
http://csperkins.org/