[Mops] DRAFT minutes from today's meeting

Leslie Daigle <ldaigle@thinkingcat.com> Mon, 07 November 2022 12:22 UTC

Return-Path: <ldaigle@thinkingcat.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 D04F7C14CE47 for <mops@ietfa.amsl.com>; Mon, 7 Nov 2022 04:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thinkingcat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7gJaDLReDYT for <mops@ietfa.amsl.com>; Mon, 7 Nov 2022 04:22:25 -0800 (PST)
Received: from hamster.birch.relay.mailchannels.net (hamster.birch.relay.mailchannels.net [23.83.209.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6730DC14CE23 for <mops@ietf.org>; Mon, 7 Nov 2022 04:22:25 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D83E66C0C93; Mon, 7 Nov 2022 12:22:22 +0000 (UTC)
Received: from pdx1-sub0-mail-a238 (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 750836C1E11; Mon, 7 Nov 2022 12:22:22 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1667823742; a=rsa-sha256; cv=none; b=VDKFaj3VXqLCt2O/jTYgMESmYfaFr/vgBu1iiVCsxPEvNIkqcerf/WpSibHIrSTb35NIWS PuUCMISgEqYJ+6WbVUKhPhMU6n+6hC/rmi7ttMk7gj2VMP+BkaMPcnvoNzPjJ913gRJY0b T3LIyOi0xAixfDH1Sygw0Rq0fO8GbHbCRKgNael7LKTxz+zmCgMkT3uJH70NfeAO7sPM1i qBqGrgDerpq3A1UPMDOszT8gwhIzPLXzcDJrn5Mn22wc2mejlv1u5msgjImYMhCx+/No2f kgKIomDjN3d3NZ69Ifb3pxvDpmxljFDXimI2Z5E1PirXZNGQCv0Avz98t+RZeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1667823742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=aXq8Exol2TIX/MZx3Gep4acgrCrPH7GmTl40gUtHT44=; b=Ob4JWa7XKXu/UE+RcjIqZnU4X7p2dsSR+huTZfYyDDUEFCFI0TpXQBSezvzahw4jYQujkA StJRPwT4F/kd6ljWEnapDIekQ+v0rdRR+WkuQ6Yr+UoeL99vArpFuY94UyVdXVlCMzmVn0 UHkb6Z9yjyhMPS9KbXyA7R4pgFaNvyHLOl0jGPetiCMImmMjj3Bo8gpTnJPZTKLcITiLeH 3VJ+p6Idd0VPUa9mSI4+86U6eOnQE+Jac04Kp84CaSMtXTdG5Hr+d4obtkpiFxMIYqzHEL L4KHCX2xlu7NtsfQvpqrcIENR4VS045uNXWspamBXk4Ognfe+pirpfiO7lggmQ==
ARC-Authentication-Results: i=1; rspamd-5cb65d95c4-2tp7r; auth=pass smtp.auth=dreamhost smtp.mailfrom=ldaigle@thinkingcat.com
X-Sender-Id: dreamhost|x-authsender|ldaigle@thinkingcat.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|ldaigle@thinkingcat.com
X-MailChannels-Auth-Id: dreamhost
X-Oafish-Chief: 7447bf6b04c62839_1667823742739_977853782
X-MC-Loop-Signature: 1667823742738:1712007867
X-MC-Ingress-Time: 1667823742738
Received: from pdx1-sub0-mail-a238 (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.105.95.137 (trex/6.7.1); Mon, 07 Nov 2022 12:22:22 +0000
Received: from [31.133.145.247] (dhcp-91f7.meeting.ietf.org [31.133.145.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ldaigle@thinkingcat.com) by pdx1-sub0-mail-a238 (Postfix) with ESMTPSA id 4N5VjT3Jcvz1y; Mon, 7 Nov 2022 04:22:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thinkingcat.com; s=dreamhost; t=1667823742; bh=aXq8Exol2TIX/MZx3Gep4acgrCrPH7GmTl40gUtHT44=; h=From:To:Subject:Date:Content-Type:Content-Transfer-Encoding; b=Ktv4wbbNcOQxZcS+d+wOYahJYlCIMZUwrCo9spBfbzVP3r4ZCrCoUZG4IarGKDSym zpISHCCy6pa06R6uJgs86JGpK3olGBJEQSETAZs2G4oQ1FWPFzuaRo4Vn3jfNy0N3z 8HRXgHRiwNu9vfMFCyIi/sORBHGW1UKFyesxkxFXWlhFG5u6FwoRiVDVnyZvmkB0Ec g/7IWapNMafXG8p4uIWbNDNUPa0J2vdrw4k0fcW1ggM4nSRepICSWn9Axu8zTYzxza WWTjS7il6aI5C97BFxFSddpPUJ1KBv8n6yuCW6W1sgxDThLFSHkYyTuMRMQCf+JL7z jCc9EA4CCI9mg==
From: Leslie Daigle <ldaigle@thinkingcat.com>
To: MOPS Working Group <mops@ietf.org>
Date: Mon, 07 Nov 2022 07:22:18 -0500
X-Mailer: MailMate (1.14r5875)
Message-ID: <757C866C-1CE3-4F9E-A73A-AC0D4A71B393@thinkingcat.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_92FD158C-AB93-4CAF-AFEF-239F6D8F818B_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/qmmIJOJuLUZ4c2NxrKWYvO5g2Gw>
Subject: [Mops] DRAFT minutes from today's meeting
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 07 Nov 2022 12:22:29 -0000

Hi,

Thanks, very much, to Warren Kumari for being our note taker at 
today’s MOPS meeting.

Please find the current draft of the notes copied below.  If you 
participated in the meeting and have any edits to make, the document is 
available at:

https://notes.ietf.org/notes-ietf-115-mops


We will be uploading the official minutes by next Monday, November 14.

Thanks,
Leslie.



# MOPS IETF 115 London Hybrid Agenda
### 09:30 GMT, Monday 2022-Nov-07

## About / Intro:
* Admin [5 min]
* Note well
* Minute taker: Warren Kumari
* Agenda bash

## Working Group Documents [20 min]

### Media Operations Use Case for an Augmented Reality Application on 
Edge Computing Infrastructure: Where to go? [20 min]
* Updates
   * S 3.x: Elaborated techniquess to aquire model of real world
   * S 5.1: ATR Traffic Workloads
* Pretty chart with numbers
   * BW for various contexts / usages -- 1Mbps -> 1000Mbps
* Simlar, but in a table
   * Latency for things like AR surgery - <750 us, >30Gbps
   * Latence for things like Cloud based mobile AR  - <50ms, 50/100Mbps
* Questions:
   * Renan Krishna: Is the WG Ok with us putting these in the draft?
   * Q: Are these numbers RTT or 1-Way?
   * A: 1-way (I think, I missed it because I was playing with 
formatting!)
   * Q: 30Gbps seems very high
   * A: Well, this seems like it is for uncompressed.
   * Q (Sam Hurst): Have you soncidered iframe only.
   * A: We are trying to capture industry practice. Would welcome 
comments on GH.
   * Q (Kyle Rose): If you are going to put in numbers, they are "moment 
in time" - are these numbers all from the same rough time? Should state 
in the draft.
   * A: Yes. We should  specify in draft
   * Q (Spencer): WG should think of rough orders of magnitude. Do 
'somewhere between x and y, not 34.324385223226Mbps'. That's one thing I 
wish we'd done differently, with the streaming media operational 
considerations draft (now published as 
[rfc9317](https://www.rfc-editor.org/info/rfc9317)).
   * Q (Giles Heron): Latency figures below x (~1ms) are somewhat 
pointless
   * C: Other issue is that we envision running this over other 
transports (e.g WiFi) - want comments on how this affects things.
* Actions items for draft (notes from chairs):
   *   Numbers
   *   Are we done?!
   *   Pull all questions out, send them to the list, and try get 
answers. Hope to WGLC by next meeting...

## Industry News/Experiences [25min]

### Updates from SVTA (Glenn Deen) [15 min]
* Original intent from MOPS was to bring professional video people and 
IETF together. Update from Streaming Video Technology Alliance (SVTA nee 
SVA)
* What is the SVTA?
   * List of areas / groups
   * Wheee! SVTA uses RFCs... Many RFCs...!
* How SVTA Open Caching relates to CDNi
* Updated Open Caching Config info...
* SVTA is doing a QUIC PoC (actually HTTP3). Developing test 
environement for streaming with QUIC
* SVTA Contacts:
   * Glenn Deen (Comcast-NBCUniversal) - glenn_deen@comcast.com
   * Sanjay Mishra (Verizon) - Sanjay.Mishra@verizon.com
   * Jason Thibeault (Streaming Video Technology Alliance Executive 
Director) - JT@SVTA.ORG
* MOPS was able to bring new people to the IETF
* Questions:
     * (Sam Hurst): For clarification, is this over HTTP/3 or over QUIC 
itself?
     * A: HTTP/3 for now, maybe deeper in the future

### Update on ALTO at Telefonica (Luis M. Contreras) [10 min]
* Why make TCDN be a transport aware network?
   * Benefit from real time awareness
* Network map & Cost Map
   * Received over BGP-LS
* Progress / update since IETF114
   * Pilot run on Oct 27th
* Known isuses / limits
   * One vendor has issues disseminating BGP-LS
* Good News!
   * Retrieved ~16k summarized IP ranges, spaning differnt types of 
nodes (fixed, mobile, enterprise, etc)
   * IP ranges currently internal only
   * Cost map correctly reflect IGP metric
   * Server load is not really significant
* Less good news
   * Missing some IP ranges
     * Still looking to see why... Perhaps missing some BGP-LS 
sessions...
     * A few duplicates
* Next steps:
   * How often to consume?
   * Debug issues
   * Wait till vendor fixes their stuff...
   * For ALTO / MOPS:
     * Document pilot (does MOPS want to see this?!)
     * Identify gaps / issues, etc.
     * Hope to update at IETF116
* Q:
   * Frédéric Fieau@Orange: Do you plan to work with other telcos and 
share maps?
   * A: No plans at the moment


## Related IETF work [15 min]

### TreeDN: draft-giuliano-treedn (Lenny Giuliano) [15 min]
#### Presenter: Lenny Giuliano <lenny@juniper.net>
* Why (Problem Statement)?!
   * With large live audences and moar bitrates, are we at inflection 
point?
   * Live streaming != On-Demand Streaming
     * Expectations for low latency. If you hear the bar downstairs 
cheering before you see the person with the ball do, um, whatever people 
do with balls in sprts things..... Clearly the minute taker doesn't 
sport...
   * Join rates are vastly differnt; smooth for on-demand, step function 
for live
* Multicast has been successful in some places.
   * Not so wonderful on the Internets...
   * "All or Nothing" -- all L3 hops need to do this.
   * "Too Complex" -- perceived benefit not worth the cost. (WK/scribe 
comment: And often the benefit is negative..)
   * "Chicken and Egg" -- no-one does this, because no-one does this.
* TreeDN...
   *  Native and overlay concepts to deliver serive to users who don't 
have multicast.
   *  Native On-Net SSM
      * SSM is less complex
   * Overlay - AMT (RFC7450)
     * Dynamically built tunnels hop unicast-only bits of the network.
     * Solves "All or Nothing" and "Chicken & Egg"
   * Incremental deployment
* Diagrams (with and without Multicast and TreeDN)
   * If deployed on existing infrastructure, it is basically 
CDN-on-a-Chip - $0 capex, ~$0 opex
     * Just some config
* Benefits
     * More efficent network
     * Allows SP to offer Replication As A Service
     * Democratizes and decentralizes content sourcing
* Applicability
     * Any multi-destination content
         * Live treaming is the sexy example
         * But large files (e.g sw updates) also work well...
* Next Steps / Action Items:
     * Q (Kyle): Read draft, interesting... Still had issues, like 
democratizing content - this is just for the fanout though, not the 
rights issues, etc. Creating novel attack surface with replication as a 
service. This hand-waves away things like key mgmt - they are still 
there, just not in the replication. Exposes what content is being 
consumed. Willing to help, but still unresolved (non-technical) issues.
     * A: 1: Yes, content rights are an issues, but thats orthogonal - 
e.g nature cams, drones, etc. 2: Attacks: Multicast is a differnt attack 
surface. Not more or less, just differnt. 3: Key Mgmt - What was meant 
was the key mgmt is that it goes on between user and provider; 
intervening providers don't have to participate. Not unique to 
mulicast...
     * Q (Eric Vynke): Looks like this is best current practices for 
using MBONE best current practices "just" stitching existing bits 
together, not new work. Seems like it belongs in MOPS. Is there a 
deployed PoC?
     * A: Yes. Come to MBONED...
     * Q (Hang Shi): What transport does this use? Can be used with TCP?
     * A: Nope. Multicast doesn't really do TCP, works with UDP - can 
carry any multicast compatiable transport.
     * Q - Chairs: WG Adoption? If so, MOPS or MBONED? Show of hands...
       * Chairs: Looks like there is good support for adopting (approx 
23 hands raised, 3 not raised in Meetecho queue)


## AoB [5min]
* None!