IETF Logo Mail Archive

Re: [Rum] Minimum Technical Features in RUM?

Chris Wendt <chris-ietf@chriswendt.net> Wed, 27 March 2019 15:30 UTC

Return-Path: <chris-ietf@chriswendt.net>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A631202DB for <rum@ietfa.amsl.com>; Wed, 27 Mar 2019 08:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com
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 Xrd_gpMHJWJx for <rum@ietfa.amsl.com>; Wed, 27 Mar 2019 08:30:21 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412E4120073 for <rum@ietf.org>; Wed, 27 Mar 2019 08:30:21 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id v20so19262361qtv.12 for <rum@ietf.org>; Wed, 27 Mar 2019 08:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q4QRkwNu2uCG7mn0BrtDOlIRc3dzr8pNTM0X8dc9Tcc=; b=lTdeo7wuebX8/amiyjJXRkfbKP/rvAgtxf7p46hUZH2cAChGF3tBclhAhUICe2lPko gBVtW9v8/iTDBcw6jzF5oAx/cClPi6o8FlTJ7TFH3dq+qEjjmfa2wnefybrpZw5noJK/ 5JZKHZHz1YebL/EKCpeTng2O6EPC9xdho26QorXgfyoK//ffPeBgEp/gwc/bDMvbFfNp Xh3N49CipQTqIH1NkbZnQnc9vWFqTjryEOIHPgUO40CPdY9ecKPLn26FHPsuapZ12alr Ns31+MFe+64zRLgBYjZvX3iGUXxSnbL4G759STUS76iYK2v39U0NHK2ILOTka5eOc3Nr I8SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q4QRkwNu2uCG7mn0BrtDOlIRc3dzr8pNTM0X8dc9Tcc=; b=ewPdDe1mDJWxZlUTWCCB7XQUbhJH/c9BO5WqIhnRQPg3zul26OE7sxx4M7Fb/z9w11 SDzKHvNuJThbLmUSIyzz6Pv9oe4gaqqzI424ki+DJm8faUxlsgz9ncCUhrIkmzBXh2gS FDEDBHuTgMGfD1Wp5/3XmNdE/NEmaf2lqZAYjH9h6JaKPgi+6oBd1kozvOwJL3TFp0fF iGG82gr4JCA5vNYAJ/cgLo+v8tOnqoYKinWByLyORB+iZWu8c4KFt1EQ+bamr8Ub5U69 qV66N4t4D7uHLLUxDShZEXTjLEhKWIxkuRk8kti4ZlTgtvVBN6cd6GGtOCf5ahZrbkg0 H6lg==
X-Gm-Message-State: APjAAAXD6S1CPugfiFrosYdgeYm3nbwG1hCz98Zd/qfO5dB/1COVS3T3 kEpooiwcMVc8qiNg4p8Vrzg2CXAZA9g=
X-Google-Smtp-Source: APXvYqwRhxp1ieYNa44jyytR44bWylasWTSWz4Uyw45yKG12JRGw090TwJDA+3aEUHnM+e+tz/i/vw==
X-Received: by 2002:a0c:9236:: with SMTP id a51mr32149719qva.217.1553700620370; Wed, 27 Mar 2019 08:30:20 -0700 (PDT)
Received: from [10.26.44.23] ([64.237.40.140]) by smtp.gmail.com with ESMTPSA id c207sm9418926qkg.14.2019.03.27.08.30.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 08:30:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Chris Wendt <chris-ietf@chriswendt.net>
In-Reply-To: <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com>
Date: Wed, 27 Mar 2019 16:30:17 +0100
Cc: rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <421FADC7-8C6A-436E-A792-1D5676A689E7@chriswendt.net>
References: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com> <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com>
To: Eric Burger <eburger@standardstrack.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/NcWCWqWj3LE3IoVhwB3SqQBGXkg>
Subject: Re: [Rum] Minimum Technical Features in RUM?
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 15:30:23 -0000

I think we can hopefully point to the webrtc video specs which I believe at least define minimums in terms of MTI codecs, resolutions, etc.  Maybe they will be updated over time, but we are getting to the point that having beyond a 4k video stream for your video call may produce diminishing returns.  Some would argue 1080p/30 or 60 is already at that point.  So while, you never say never, i believe it’s pretty safe to say for the kind of video we are addressing in RUM, there is soon going to be some pretty comfortable stability for a while.  I don’t think that’s a controversial statement but maybe could be proven wrong :)

> On Mar 27, 2019, at 4:20 PM, Eric Burger <eburger@standardstrack.com> wrote:
> 
> Is there a compelling reason to go here?
> 
>> On Mar 27, 2019, at 9:49 AM, A. Jean Mahoney <mahoney@nostrum.com> wrote:
>> 
>> Brian asked if the draft was missing anything. If there is a required minimum frame rate, it would need to be captured in the draft. Adam said that once the WG started importing WebRTC information into the draft, they would find things to add. FEC for instance. Adam said he could be the WG contact for WebRTC information.
> 
> I agree: it would be nice to say, “The device MUST be usable.” However, doesn’t the definition of usable change over time? Looking at my real-time messaging work in the late 1990’s, we might have said something like, “You MUST have an ultra high-speed, 384kb/s connection.” Wouldn’t that look quaint today.
> 
> In other words, talking about FEC, minimum frame rates, minimum display sizes, etc. is IMHO is way out of scope. If someone chose to build a device that was unusable, that is not our problem. They would find adoption to be about 0%. Conversely, if someone is seriously building a device that meets RUM, they would presumably check to see what would be viable in the (then current) market.
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

v2.23.0 | Report a Bug | By Email