Re: [Mops] Draft minutes from 2020-Apr interim

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 22 April 2020 14:46 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F83A0D97 for <mops@ietfa.amsl.com>; Wed, 22 Apr 2020 07:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 PWsfMIGNbzGZ for <mops@ietfa.amsl.com>; Wed, 22 Apr 2020 07:46:04 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 CA5303A0DB0 for <mops@ietf.org>; Wed, 22 Apr 2020 07:46:03 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id g4so2597516ljl.2 for <mops@ietf.org>; Wed, 22 Apr 2020 07:46:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yNaMxwzh1UzXITWIXT7HF6KCls8bi2oO4CznUL8mywk=; b=X2DvhpLqMVt2OQFl/3iF4TgoThTjZApHxElOOd9tOno8CV5Fcne+LJVrsveJikp6gm INsocLnrKBOugTJmQnkn7PUPtmtWuYHnTXgCjfRoQjAv3HUHvRXX81Bh5rY+OQG7O2Im bO2z9D5/6cXpYMedrM9EZ+VY5rYeYR44OMzdlWU2wghpGrhP8BkOIsF2NbF3oYNdV1il QXhkDQP4Sp8/clD1aZ1X6Cjc6R/2t/UMw7B72P6NInX47OEIPmAAZv4rx/HmgPTAPTF6 K5BY2hZSXwvnFrCFIRuIOxQzBkETIY855xlZ4q7u/qdnyKBQXX/ZWlUCybxdVArr7aJz +5Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yNaMxwzh1UzXITWIXT7HF6KCls8bi2oO4CznUL8mywk=; b=egm90o2OHaO/OM1vNJ+e6HxGv6FNQfdspyuh1f1VmdCRmdX/TIoLQNqjjPSk+W/s7I xYohBBfdjCGN1tGhfqCKVEzEmkA9shY78ufMBm+wAizDD2hlLVyoq6lZD4omCDO3zaNk zqvLrgEC3CXfn+ZMZ6w4R0pcQ5QvgPQdffItFqQE/F59/IFrozJHE1Iec/PyVwOUFJIJ Yj2xW0fTU50lGOCvregQHlE95CfR3ViQ1h3TJ3BysvWLrijjLwX8dUbNE6rEF76vpX4r fPg7rj7yEOk4S4FJUGrbYSZpvC/eHpCN3OjIi+MSk8/bUz+psjdlpfhk8IVHfBQOrDKB 705A==
X-Gm-Message-State: AGi0PuYx4DHU+vKgt0t+L9AlkPoP+Xb4v/2y4WPuUFF0O+irEqa5RQyT NyJYUlU39JKbb3rBbCKLY/hgktk6My3zkvTN/Xn2Ob6MPzQ=
X-Google-Smtp-Source: APiQypIJf4M56etjg1SCbp/fOBKjzd38j7LMorVaK5/RLbq+b9b7p3tJY7K+avG4ljsO0fEqmV4KYnaFzcHiKtqWoOc=
X-Received: by 2002:a2e:7e04:: with SMTP id z4mr16692469ljc.50.1587566761803; Wed, 22 Apr 2020 07:46:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAJU8_nXQkRd_KVNUBsk-1F_ZC_DGnMt5n0Unr-asK3WUrqvADA@mail.gmail.com>
In-Reply-To: <CAJU8_nXQkRd_KVNUBsk-1F_ZC_DGnMt5n0Unr-asK3WUrqvADA@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 22 Apr 2020 09:45:35 -0500
Message-ID: <CAKKJt-dfTkN3coBoM9N_k3AcErtzSBd0OSyqBo-WgGCZJtTJjA@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: mops@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e54ff605a3e2307a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/lB3Z2nIchJNmqEbOoG8OvsJkQ9Y>
Subject: Re: [Mops] Draft minutes from 2020-Apr interim
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2020 14:46:07 -0000

Hi, Kyle,

On Wed, Apr 22, 2020 at 7:52 AM Kyle Rose <krose@krose.org> wrote:

> I've pasted the draft minutes from our Ides of April interim below. Thanks
> again to Olufemi Komolafe for volunteering! Please review and provide
> clarifications and/or corrections to the chairs. Otherwise, we'll be
> posting the minutes to the data tracker in a week at which point it will be
> part of your Permanent Record.
>

Thanks for the excellent start on minutes. I have a couple of notes below.

Best,

Spencer


> Kyle
>
>
>
>
>
> Media OPerationS (MOPS) WG
>
> April 2020 Virtual Interim
> Wednesday, April 15, 2020 20h00UTC-21h30UTC
>
> Webex details below
>
> Agenda
>
> Intro
>
> Agenda Bashing [5min] chair(s)
>
> Review of concrete work items:
>
> [15min] Draft of edge network operational considerations for streaming
> media
> Jake Holland
> draft-ietf-mops-streaming-opcons
> Github - https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons
> Accepting comments via GitHub issues
> Presented update on draft
> Discussion on “Soliciting Contributions - Proposed Template”
>      + have in current draft or perhaps produce new draft (BCP?)
> Matt Stock: Like template and sees potential
> Jake Holland: Appreciates feedback.  Potential to write diffrent BCPs,
> targeted at diffrent audience
> Spencer Dawkins: Aim is for draft to not only call out potential bad
> things but rather try to be actionable, hence why mitigations are solicited
> Glenn Deen: +1 on collecting mitigations and sees potential in this
> highlighting potential areas of interest/work. Mitigations are only a first
> step, and where there are really egregious problems the mitigation may be a
> temporary approach and the issue may trigger additional work relevant to
> the IETF.
> Matt Stock: Mitigations may not be black/white but rather may involve
> tradeoffs which should be called out to inform decision-making
> Leslie Daigle: Maybe collect the issues as a starting point
> Spencer Dawkins: Thanks to both Glenn and Matt for these excellent
> suggestions
>
Updates from elsewhere
>
> Updates from other work
> [15min] Sanjay Mishra - anything from SVA Open Caching WG
> Described significant impact COVID-19 having on video traffic seeing by
> carriers
> Discussed ongoing and potential work of interest in SVA and potential new
> working groups
> Glenn Deen: Recent work in SVA working group on media use cases for
> multicast streaming that may be of interest
> Jake Holland: Work looks interesting.  What does engagement with SVA look
> like?  SVA members commenting on IETF mailing list? Interested to hear more
> about the multicast work
> Sanjay Mishra: Perhaps bring back updates/proble statements etc from SVA
> to IETF, IETF can work on these items and perhaps SVA consumes the output
> Spencer Dawkins: Thanks for discussion on COVID-19 impact on video
> traffic.
>

This could be "Thanks for discussion on COVID-19 impact on video traffic,
with references. draft-ietf-mops-streaming-opcons now has a section on
"Unpredictable Usage Profiles", and the authors have been talking about
mentioning COVID-19 as well.


> Glenn Deen: Address potential issue regarding IPR raised by Jake Holland.
> There should be no issues - SVA docs are published on the web for all to
> read and IP issues shouldn't enter into MOPS working with SVA use csses. If
> still concerned, please come talk to glenn.deen@nbcuni.com - I'm on the
> SVA board.
>
>
>
> [5min] Glenn Deen -- anything further re SMPTE
>
>
> [15min] Maxim Sharabayko SRT — see
> https://datatracker.ietf.org/doc/draft-sh arabayko-mops-srt/ , posted on
> MOPS mailing list
> Overview of potential benefits SRT
> Jake Holland: Questions about protocol and operational use.  Suitable for
> contribution/distribution or livestreaming to end-users?
> Max Sharabayko: SRT is well-suited for media
> Marc Cymontkowski: Use of UDP means not SRT is not direct
> What other protocols were considered and what was deficient about them?
> Marc Cymontkowski: Original goal was to transmit live stream over public
> internet. Came to problem with clean slate and started with UDP and added
> enhancements to make it more suited for real-time traffic.
> Kyle Rose: With hindsight, starting off with RTP may have been a better
> option at the start, a few years ago.
> Glenn Deen: Comcast use SRT significantly and so keen for this work to
> succeed.  What are the current priorities for RTP?
> Marc Cymontkowski: Redundancy, balancing data of multiple links,
> congestion control
> Glenn Denn: Congestion control of interest - as playing nicely with the
> network is in everyone's best interest
> Leslie Daigle: Potential interest in this WG in this protocol.  Detailed
> protocol machinery discussions will be done in other WGs but MOPS interested
> Spencer Dawkins: An Independent Stream draft on SRT as it exists today
> will be of great value to MOPS, because we would have a good reference for
> the protocol as we start to make recommendations on use of SRT for
> streaming operators. That was the recommendation for a first step from
> Dispatch discussion on SRT as I understood it, although the current IESG
> might change that recommendation.
>

My last sentence would be clearer as "That was the recommendation for a
first step from Dispatch discussion on SRT as I understood it, although the
final direction would be up to the responsible area directors"..

>
> Alex Gouaillard: Discussion in other WGs regarding SRT, especially
> concerns regarding security
> - When presented at IETF dispatch, concerned were expressed by long time
> IETF contributors like Eric Rescorla, Colin Perkins, Martin Thompson
> discussion here:
> https://mailarchive.ietf.org/arch/msg/dispatch/ekMWlMXch132tvri2BwrnnULzuw/
> - The question was just about the status of those discussions as, given
> the position of the people asking with respect to security, media
> transport, QUIC, SRTP, at IETF, those questions will come back at one point.
> - One of the question raised on the Dispatch thread was also, why at mops
> and not in ART, since it looks more in scope for the later.
>

that's probably "for the latter".


> - Another question was regarding security definition (eric/martin)
> - another question, more generic, is why a new protocol when it looks like
> webrtc / QUIC are a good match to the announced goal (nat traversal, TLS
> 1.3, CC, BWE, ...)
> => discussion on dispatch would have concluded by a request for a
> document, and thus is pending this document availability.
>
>
>
> Operational Issues Observed
> [15min] Jake Holland — Experience making the world safe for interdomain
> multicast
> Discussed some of the challenges/opportunities with interdomain multicast
> Outlined goals for 2020 & eager to collaborate in trials/POCs so please
> reach out if interested
> Leslie Daigle: Interesting overview
>
>
> AOB
> [10min]  Liaison Statement from SC 29/WG 11 to IETF MOPS WG (SC 29 N 18620)
> Spencer Dawkins: Spoke to Stephan Wegner, the IAB liaison manager for SC
> 29/WG 11, on Monday; he had no further updates beyond what was in the
> original liaison statement they sent to IETF.
>
> Leslie Daigle: Git repo set up for WG
> Kyle Rose: Repo will be used when documents are adopted.  Not mandatory
> but convenient for collaboration.  Will send URL on list shortly
>
>
> --
> Mops mailing list
> Mops@ietf.org
> https://www.ietf.org/mailman/listinfo/mops
>