IETF Logo Mail Archive

Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02)

Harald Alvestrand <harald@alvestrand.no> Fri, 04 April 2014 09:03 UTC

Return-Path: <harald@alvestrand.no>
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 CEED91A00E3 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 02:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 7xuRFLMu_Jfb for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 02:03:07 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8B61A043C for <rtcweb@ietf.org>; Fri, 4 Apr 2014 02:03:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C880D7C526A; Fri, 4 Apr 2014 11:03:01 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP6SBNy7RFcu; Fri, 4 Apr 2014 11:03:00 +0200 (CEST)
Received: from [10.20.1.105] (114.red-80-28-236.adsl.static.ccgg.telefonica.net [80.28.236.114]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2D6EF7C5266; Fri, 4 Apr 2014 11:02:58 +0200 (CEST)
Message-ID: <533E753F.4090902@alvestrand.no>
Date: Fri, 04 Apr 2014 11:02:55 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Bernard Aboba <bernard.aboba@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> <CAOW+2dsX4DkUTSdyVKXbHtgbVbrmS3+KTDiaYF7=8FORQ3Ri_w@mail.gmail.com> <CABkgnnWzh8Us=e-MhEZg=8Psy7=-BqLAt-UWASBPjuTAku9bgw@mail.gmail.com> <CAOW+2dt+YdsJLJ8dFmRsaKpOpQQXd1ohX0u_r8sJjvifk_kB3w@mail.gmail.com>
In-Reply-To: <CAOW+2dt+YdsJLJ8dFmRsaKpOpQQXd1ohX0u_r8sJjvifk_kB3w@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------060809030006020309050001"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CtxqkBekf9iXraI7sE7L-NaiZGs
Cc: Harald Alvestrand <hta@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02)
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: Fri, 04 Apr 2014 09:03:15 -0000

On 04/03/2014 10:44 PM, Bernard Aboba wrote:
> Martin said: 
>
> "The marginal benefit remains...tiny relative to the cost"
>
> [BA] This is particularly true if you consider *all* of the additional
> work items required to enable the usage scenario.  It is one thing to
> support SRTP/SRTCP over RFC 4571 framing, but without also
>  encapsulating DTLS/SRTP over RFC 4571 framing, how do you reliably
> obtain the SRTP/SRTCP master keys?  Similarly, do we also run
> SCTP/DTLS data channel over RFC 4571 framing?   In my experience,
> without a great deal of care, running one reliable transport over
> another can works poorly if packet loss is encountered (e.g. the
> time-out periods interfere with one another).  

One result of the London discussion was that I read the TCP TURN
candidate specification, and found that it most explicitly states that
you use 4571 framing for DTLS.

Since it would be very silly to have two types of TCP candidates with
different encapsulation strategies, I wrote in 4571 framing for DTLS too.

"The absence of alternatives clears the mind marvellously".

RFC 4571 is a framing protocol without support for resynchronization. So
it depends on getting whole frames through - something that seems to be
hard to achieve with POSIX TCP send() semantics. A simple implementation
would use blocking writes, in which case packet loss at the higher level
could not occur; another implementation strategy would use non-blocking
mode and drop packets from a higher level buffer if the TCP transmission
buffer filled up, leading to the two-level packet loss issue mentioned.

Which implementation strategy would people expect to use?

-- 
Surveillance is pervasive. Go Dark.

v2.23.0 | Report a Bug | By Email