Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb

"Karl Stahl" <karl.stahl@intertex.se> Wed, 01 May 2013 21:29 UTC

Return-Path: <karl.stahl@intertex.se>
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 A9F0321F899E for <rtcweb@ietfa.amsl.com>; Wed, 1 May 2013 14:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
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 rv8rMC4Z0wVc for <rtcweb@ietfa.amsl.com>; Wed, 1 May 2013 14:29:08 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7B021F8648 for <rtcweb@ietf.org>; Wed, 1 May 2013 14:29:03 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id MAD48048; Wed, 01 May 2013 23:28:48 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Randell Jesup' <randell-ietf@jesup.org>, rtcweb@ietf.org
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <AE1A6B5FD507DC4FB3C5166F3A05A48416281FDB@tk5ex14mbxc272.redmond.corp.microsoft.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <9F33F40F6F2CD847824537F3C4E37DDF0E6C04AF@MCHP04MSX.global-ad.net> <CAErhfrx6xi7rNmc6CZc5iyKiYv+oZbi3sBa5QywB7dUKtms2Aw@mail.gmail.com> <C643F355C8D33C48B983F1C1EA702A450B49EA@ESESSMB301.ericsson.se> <4AA3A95D6033ED488F8AE4E45F47448742B13620@WABOTH9MSGUSR8B.ITServices.sbc.com> <CALiegfmpZZigigQtaadsXup6VfWgJAF8--TJpbUwSJMmar7fRA@mail.gmail.com> <CAD5OKxv2d2DemnjHQdB8XU8NKfK-Uu913DLPq9JUT4z9kvFfTQ@mail.gmail.com> <829F9A35-5F23-4A0F-9831-80478F70965E@phonefromhere.com> <517E2F6A.30905@alvestrand.no> <C5E08FE080ACFD4DAE31E4BDBF944EB1134B0090@xmb-aln-x02.cisco.com> <5180f8ac.65f3440a.7deb.fffffeeaSMTPIN_ADDED_BROKEN@mx.google.com> <CAOJ7v-1K6B6GTBShbwcE2FZWtL+Hm_XLMS_cRvMJejx8gUtieg@mail.gmail.com> <51815F43.709050 5@jesup.org>
In-Reply-To: <51815F43.7090505@jesup.org>
Date: Wed, 01 May 2013 23:28:48 +0200
Message-ID: <036401ce46b2$de8e6500$9bab2f00$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac5GmfquJx7HLAbSTySFsb3/wt5p+AAFHleg
Content-Language: sv
X-Spam-IndexStatus: 0
Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb
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, 01 May 2013 21:29:12 -0000

Correct, a geostationary satellite link adds minimum 240 ms of delay. That
would add 500 ms roundtrip which is bad for RTC (i.e. two way
communication). I would call it an Internet data-only access (which of
course is fine for streaming video though, that is one way, and can
retransmit using TCP and where a small extra delay doesn't matter). We
should not confuse. RTC is two way, and more than 500 ms round trip delay or
so, must be considered "not an RTC Internet access".

Narrow band access also adds delay. A 250 kbps 2G, 3G, or ADSL upstream
takes 50 ms to get a 1.5 kbyte Ethernet packet through. With a few packets
queued up, your voice packet may get 200 ms added if not prioritized in that
queue (which it is not over best-effort Internet).

So there are delays - and all accesses are not good enough for RTC.
 
Then we have packet loss is addition. There are tolerance in audio packet
loss (better with some codecs) and telephony 3.5 kHz voice is not hard to be
better than.

But WebRTC in itself allows teleprecense HD quality! Do we need loss-less
RTP transfer to utilize that over data crowded Internet access? We cannot
retransmit due to delay - Only IP-QoS, level 3 traffic shaping in congestion
points and diffserv or reservation gives loss-less RTP.

(A deviation from the DTLS delay question it started with, but
interesting...)

/Karl



-----Ursprungligt meddelande-----
Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Randell
Jesup
Skickat: den 1 maj 2013 20:30
Till: rtcweb@ietf.org
Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568)
and RTCWeb

On 5/1/2013 9:01 AM, Justin Uberti wrote:
> This doesn't match what we are seeing. I pulled some Chrome stats on 
> average RTT seen across various network connections; on 3G, close to 
> half of users had RTTs > 250 ms. 4G is somewhat better. 2G is 
> considerably worse.
>
> India continues to be especially bad, partially because of the above, 
> partially because of use of satellite links, which due to physics 
> incur 500 ms RTTs.

Those are all RTT measurements, so One Way Delay's of roughly half of that?
speed-of-light for a one-way satellite link would be around 280ms in theory
- and of course that's just for that one physical link.

--
Randell Jesup
randell-ietf@jesup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb