IETF Logo Mail Archive

Re: [dispatch] Virtual IETF107 - SRT draft is available

Mark Nottingham <mnot@mnot.net> Thu, 19 March 2020 00:22 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554CE3A1ED7 for <dispatch@ietfa.amsl.com>; Wed, 18 Mar 2020 17:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Zfh7UbdH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ByuUg+Xj
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 O6DfKwGjv4F2 for <dispatch@ietfa.amsl.com>; Wed, 18 Mar 2020 17:22:41 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5805B3A1ED5 for <dispatch@ietf.org>; Wed, 18 Mar 2020 17:22:41 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9AF0A606; Wed, 18 Mar 2020 20:22:39 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 18 Mar 2020 20:22:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=L iyH3wWU67aKbV9lm65KzXt7bd13RwJeWlrr9LEhm10=; b=Zfh7UbdHLAQHXSUoi j4gj0q3u1Vg4Z53uEplorW4kYbCzvjUt4y4CjhgU7nXGuqdjMhgETuHyspqkoFX1 PTxEo4KIuMTlRt8gL/hnyG5cvCZFGp8hCz7VUN44GHpRoWyfMAOgqs9S7GAQje4Y mqzNUEjE5+vVzvNBJyBIDEMDnBjVNeQb1baXLz3xHo1m07HMgK4/DbRp/MIqQFlx prxAqjZLbfwgSoe9JOpXU1ceqWI+yatKsO32ZsjPuXVApGPDeuMrURKxifHB3XUl cp2G7xozcjlG7jO8zuhMZpRWfPtj37mBAU5/WKn+p9IBsSAYSFW1tLV+bpRxyMUC ZeN1g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=LiyH3wWU67aKbV9lm65KzXt7bd13RwJeWlrr9LEhm 10=; b=ByuUg+XjEJHlLbVy+5k6/9PlZkdI6WQeskuKErjbsZrlYU4/xotRa9imK NOVYdMOnWJfke+qI+nX/rShIdJCyjjdUdbzq7mrS27663eMsrJWxAfFoTrpYam+6 4LsimfhJDGAPzvr1loQFNxk5ji2rjLoz+Vc2mdh1QG6zrk7AewpcTS25eSbtmmo6 4Syjzgf1nLdKVWZ2p5fv7SjGEQ0+F2Sw1QkmEavubZwihONiGgTC/n3p8CdQkoeg zPPCtI/vOZ83W8T4p1gDCHwAsNsO/3XrxEnN43gq5fLLZjQqyfoGpHF1tEE4l3Kg 5ctpgJoWVRHBEw1d5uv/YnbB71fIQ==
X-ME-Sender: <xms:TrtyXsnyOVjNpgv4nTCR-ZQw8fLdNJMtaqvxi4ZWlr3z5DV79N2x0g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefkedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddv hedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh hnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:TrtyXk2PKS0mItFhKpRQJz-uB48IyiaDcG1fqbV58i0DodHx6Yd2Sw> <xmx:TrtyXnhq3XrgZwcDh9yDShEDokl8U33qhc98U7hxZjIzd5hEEgPMFQ> <xmx:TrtyXrf-4dA6Rvj6X2ZAYUXSopYLul0Pii2Jgj1x6asTA2rg-XYg0Q> <xmx:T7tyXlAnhafeeYVgSkFXbV-PQZW6KCLxUDLxIeI6OGN9wI5kS_FhUQ>
Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0CF273061856; Wed, 18 Mar 2020 20:22:36 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <A928C153-0E0B-41E6-8A7E-2752D8137408@nbcuni.com>
Date: Thu, 19 Mar 2020 11:22:34 +1100
Cc: Martin Thomson <mt@lowentropy.net>, "dispatch@ietf.org" <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F97AADA9-817E-4D3D-B6AF-BEC145359851@mnot.net>
References: <A928C153-0E0B-41E6-8A7E-2752D8137408@nbcuni.com>
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/Fc_JfXN3obYqyCpOqGez8EMbITk>
Subject: Re: [dispatch] Virtual IETF107 - SRT draft is available
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2020 00:22:43 -0000

On 19 Mar 2020, at 8:26 am, Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:
> 
>    * why would anyone choose to do this as opposed to something like QUIC?  QUIC provides certain security properties, whereas I have very little confidence in the claimed security properties of this protocol.
> 
> [GD] SRT has reliable delivery features that are needed for media distribution and are not part of QUIC and wouldn't be likely to be added to QUIC.  So QUIC isn't a replacement for SRT, though it is entirely possible that at some point SRT may be run over QUIC.
> 
> [GD] SRT has features that meet media specific needs.  For example consider the need to reliably deliver a live sporting event quickly from the stadium to the distribution carriers such as your local TV station or cable company or streaming operator. It's used when the media stream MUST arrive at the studio and can't tolerate retrains.  It's not only for live events but such events are a great use-case for the Reliable aspects of SRT.

QUIC has reliable delivery of streams by default, and the WG has just adopted <https://tools.ietf.org/html/draft-ietf-quic-datagram-00> for unreliable delivery. Is there any feature of SRT that can't be built on top of those primitives?

I'd suggest that doing so is a much quicker (no pun intended) path to standardisation, in that the design work on QUIC's encryption and transport features is getting very close to done. SRT would need to be evaluated against a number of design criteria -- including not only security and privacy, but also network fairness -- to start, and it'd still need to go through the consensus process.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

v2.23.0 | Report a Bug | By Email