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

Martin Thomson <martin.thomson@gmail.com> Fri, 04 April 2014 15:41 UTC

Return-Path: <martin.thomson@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 E4D001A021E for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 08:41:55 -0700 (PDT)
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 qsbOUWwN8dJn for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 08:41:51 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4830C1A0152 for <rtcweb@ietf.org>; Fri, 4 Apr 2014 08:41:51 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id p61so3566330wes.25 for <rtcweb@ietf.org>; Fri, 04 Apr 2014 08:41:46 -0700 (PDT)
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=rzGjZYNP0rXRMYXM+8fud7yIf7p7Jwbyozt+iJsOTbA=; b=pzGfGyBJ53tyV0JPPNK9xGftWoSO5XLb3F/7hk+RFVp69Arjd5iYkVw83JLEEQS0lW KDRRhCxziVIgxgmowLaM73ncHxzMGK383CuQocqY0KXffgi1NUTmRBjrNZUKo3xK+sWr 2DYtlXQGz6fJoJ5/afEi+S4N/mtqYR3CwFCGjlcS44vJxWI1O0YAPzMeChy/GNKH5QV6 oKY25fIk5X1SHbdk+Kj+RsRSZNIBF2F1SuUc3xOnxjQKCIuD7lKrmAua58lzk7meH0rc KYrgGShxS0psw2sZVGGX8FBKdqqBGdUXU6dCpajmJPpTzhxqsOgkTPouF5+Vg9uGGzgO 71RQ==
MIME-Version: 1.0
X-Received: by 10.180.84.73 with SMTP id w9mr5535941wiy.58.1396626106321; Fri, 04 Apr 2014 08:41:46 -0700 (PDT)
Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 08:41:46 -0700 (PDT)
In-Reply-To: <533E753F.4090902@alvestrand.no>
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> <533E753F.4090902@alvestrand.no>
Date: Fri, 04 Apr 2014 08:41:46 -0700
Message-ID: <CABkgnnVSCBptt+cbUtbcCYh5XMH5FO7T-M6AeqOneXMOGbXwhA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C2BZsd6s5rbBPGROj3UQ5Xlb7y4
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 15:41:56 -0000

On 4 April 2014 02:02, Harald Alvestrand <harald@alvestrand.no> wrote:
> Which implementation strategy would people expect to use?

I think that for TURN, we were planning on using non-blocking writes
and discard packets that didn't make the cut.  This means that a
blocked congestion window would manifest as packet loss to upper
layers.

That way, at least congestion indications make it through to SCTP in
some fashion.  It's certainly not ideal, but I'm not sure that there
is a good solution in this space (I do know some people who claim to
have solved the problem of TCP congestion control within a TCP
congestion controlled envelope, maybe you can ask them.