Re: [rtcweb] UDP transport problem

Dave Taht <dave.taht@gmail.com> Thu, 13 February 2014 23:09 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568C31A04E3 for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 15:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTMfdD-co5A7 for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 15:09:08 -0800 (PST)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 812851A04E0 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 15:09:08 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id e16so18785922qcx.38 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 15:09:07 -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:content-transfer-encoding; bh=a3ejuU4Dk4oYhcm9DUevZ7vy9nUqCqNIfKpxbc3QS+w=; b=hcodQfI3KTJZKyio8ReQNeANOUmrRgHU9D515QSgGklmB5/xtCYH81uzIlqLS7wy7G DayyozAJ2NYOmBS2ft0ZCYYanpFuCj9tP12oHEmQrPtZkLeDTSbzeGoYhxPMuaFfJFe5 TRV4yCbhnQTCvcgauqAqLnLliNf7vHzy6xpGmvnoZYMpVMiXm9awQnU2qoGYeU3SxpMb X5idXfrnHhtubff1TH8nSozm1NaLzQ4ZacpOpQOtBEOZWf6Efi+IDbisIMyg2PE0IRFL xMPQsuGILvuFA/fAiw9eeAH2yywCZ3gqKwE6Tp3WDd8Tj3Tig1NHSDdcl3QPIgDnhjVb LbZQ==
MIME-Version: 1.0
X-Received: by 10.140.49.9 with SMTP id p9mr6830403qga.75.1392332947068; Thu, 13 Feb 2014 15:09:07 -0800 (PST)
Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 15:09:06 -0800 (PST)
In-Reply-To: <CAD6AjGS=F_wOvOv8CJsw8cqC7=u0kh1cyQi7SpK02bEj_RrgiQ@mail.gmail.com>
References: <CAD6AjGRiQ1UF5n3JG9HPRQFM+TD54Xz-dpTn5u9bX+__BMfesQ@mail.gmail.com> <CABkgnnVbZp7yBvpY1ARuaBXS=TOipY=BhXzrd=h5DY-76oF9Pw@mail.gmail.com> <CAD6AjGSxS4jNRGotsE_no0XhewvDqcVZ+Kmx1aMW9qorqSKR+w@mail.gmail.com> <52FD2FA4.8040701@alvestrand.no> <CAD6AjGTbSJEV2cJj5QyLktyZPv8SJa7h-QHKVtdUXnF3K6xwHA@mail.gmail.com> <52FD4AD9.7080204@alvestrand.no> <CAD6AjGS=F_wOvOv8CJsw8cqC7=u0kh1cyQi7SpK02bEj_RrgiQ@mail.gmail.com>
Date: Thu, 13 Feb 2014 18:09:06 -0500
Message-ID: <CAA93jw7qhBp1EC1UUn3DNvkcB1iwx+9q=8umT=umQfGYGvoMvg@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: Cb B <cb.list6@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XXr9jrKExyRvH3vX3abIfXyYIX8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] UDP transport problem
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 13 Feb 2014 23:09:11 -0000

On Thu, Feb 13, 2014 at 5:57 PM, Cb B <cb.list6@gmail.com> wrote:

> cute. But, TCP works.  Maybe you can ask someone at Android to support
> EDNS0 so that TCP is used less.  Because for now, android required TCP
> for any response over 512 bytes.

Android, in part, uses dnsmasq, which we are busily adding dnssec support to.

https://www.internetsociety.org/deploy360/blog/2014/02/weekend-project-4/

EDNS0 is supported.

I would certainly like to see android's DNS handling to be improved.

>
>>>
>>> But that's not the point.  The question is can we include native SCTP
>>> as an option in  draft-ietf-rtcweb-transports?  What is the downside?
>>>
>>
>> Clutter.

>From a QoS standpoint I would not mind at all if it were possible to run
webrtc (and things like QUIC) over their own protocol numbers. I
realize this would
make webrtc more easily identifiable, but so long as the e2e encryption is good,
the ability for operators and edge devices to optimize for highly
interactive traffic
would be enhanced.

I don't have a lot of hope for SCTP, do have more hope for mptcp, and
the ipv6 rollout is seemingly accelerating.

https://www.internetsociety.org/deploy360/blog/2014/02/googles-ipv6-stats-pass-3-less-than-5-months-after-passing-2/

I am under the impression ipv6 support for webrtc landed in chrome recently.

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



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html