Re: [Moq] Charter adjustment
Suhas Nandakumar <suhasietf@gmail.com> Fri, 22 July 2022 02:30 UTC
Return-Path: <suhasietf@gmail.com>
X-Original-To: moq@ietfa.amsl.com
Delivered-To: moq@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15161C13C506 for <moq@ietfa.amsl.com>; Thu, 21 Jul 2022 19:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, RCVD_IN_DNSWL_BLOCKED=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_BLOCKED=0.001, 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=gmail.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 DKtZ0MXgZdCC for <moq@ietfa.amsl.com>; Thu, 21 Jul 2022 19:30:36 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C992EC157B4D for <moq@ietf.org>; Thu, 21 Jul 2022 19:30:36 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id q43-20020a17090a17ae00b001f1f67e053cso3019662pja.4 for <moq@ietf.org>; Thu, 21 Jul 2022 19:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHpDM+7SZBH+xJLgJH5ABGXYKwNtdRShqP1UCUoY77E=; b=HnFk+ASN7vK2b2v/RgD6OysK37UVDJdpCTpH7s7u7TY4VSyx2cxktAfe6lEPA21K72 XD9MPwYEtsSsf9Mz+FBc3fCJCJjN2Kk66xmrFgILTiRLUZoyPfSZyIgUcDj/aL7c023b zw8Mj4diSc1vKMpsLsEOdiPo0JfRffdlzgrI3nsrRi4rzMndfAVjTatVk9eqesP1K15R UBNmOzr33xYvbofsnQS956YZBDc1y3LrmBMGie4v3mf2XvN6kLo240vcWCgZHbv/xzi6 o6eyvdlodg3OVKBbOu0+c/WXAy1bW9a4B2rG9/VO1o8065RcVk/WrAC4qr0rhyAvu9H2 HCqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHpDM+7SZBH+xJLgJH5ABGXYKwNtdRShqP1UCUoY77E=; b=uNZMgso3RO7V7HfTGuA7QuR1ZsWLkQMZNTIFsHv3a07H4T6pOs1QovCX0a+4uDN5m9 FWK9XR8xkQ8OFpfkP7yhLvT5oRVm8IaUQT7lRuR8Dw9wkaQ+w+4mJu2XfxjK4qWhozWT lTcOK9TBXsbSsN/oJLoVTIdecnnve1GIk2trd/tITuyYItcvZyco+XU2vY5rVElsgis9 NBTpjJXJKJT6h83n3/3j8UaNh7K+gXsl/bEY6TTReaYY4NmKBPsZiqVRFUf0CNXqNXW9 7yJa3FaoiHSAIKQDpEQI5hS+zAxDQ1POJBM07IaqkbGZ2TJzk+pQHMsmU1xbZk/bxMt1 oO8w==
X-Gm-Message-State: AJIora+Hpee3GAf0fzHdmiiiLxjsNd9Rav0bjbKv8RCLzPoJnqkkx7pB XMcJAVSAnjsxhtiKO6Lrm5dMaJsuPKGXYp8JKDY=
X-Google-Smtp-Source: AGRyM1uIUJ/9UDA/btYBL1QvqWayDbVdj5E3/sEMEsp/DtBa5E2c3VCDcVC3dGBJztWo5DjY/W7RJZ20IwsrlTIfCCE=
X-Received: by 2002:a17:902:ef48:b0:16a:1d4b:22ca with SMTP id e8-20020a170902ef4800b0016a1d4b22camr1246394plx.6.1658457035995; Thu, 21 Jul 2022 19:30:35 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMAr=dMSg9efcYBd5QZquvDhYcQi_gibyttxjqcxvWZKMw@mail.gmail.com> <511BF9AE-C84B-4AC2-9430-B268979078B4@networked.media> <CAMRcRGRGR3bXroZch4DAgeN65GodUp2J4=44pvB-6_ieGLKDTg@mail.gmail.com> <BN7PR11MB275378CDC1463041BB4E71CEB4919@BN7PR11MB2753.namprd11.prod.outlook.com> <CALGR9oaFWKvjaHg_bjoTFFMavpwAWLLe2FEGyLzNcYFqxWHswg@mail.gmail.com> <CAMRcRGTs8UPLHzw9PiJB2rOh8MwE402LvBi+xRXbnVdrx2sSwA@mail.gmail.com> <CAMRcRGRdTk_kXnd=s5ZB0XuHTRtTH0xPir3hJkBprAV70dtsTw@mail.gmail.com> <CAKcm_gMbWtbJe=kcbCXxAphLpiaiGHQPcm=00Tqoioh2SC6VZA@mail.gmail.com>
In-Reply-To: <CAKcm_gMbWtbJe=kcbCXxAphLpiaiGHQPcm=00Tqoioh2SC6VZA@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Thu, 21 Jul 2022 19:30:25 -0700
Message-ID: <CAMRcRGQ7Arbs4QYt3Uuv7vf=uJGse85-nR8xOyum87SJDTVQsg@mail.gmail.com>
To: Ian Swett <ianswett@google.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, "Mo Zanaty (mzanaty)" <mzanaty=40cisco.com@dmarc.ietf.org>, "Ali C. Begen" <ali.begen=40networked.media@dmarc.ietf.org>, Ted Hardie <ted.ietf@gmail.com>, MOQ Mailing List <moq@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000817c5d05e45b9e1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/P5yNUDQjpu0PmtR-lMBJeAnz15I>
Subject: Re: [Moq] Charter adjustment
X-BeenThere: moq@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Media over QUIC <moq.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/moq>, <mailto:moq-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/moq/>
List-Post: <mailto:moq@ietf.org>
List-Help: <mailto:moq-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/moq>, <mailto:moq-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2022 02:30:38 -0000
On Thu, Jul 21, 2022 at 4:39 PM Ian Swett <ianswett@google.com> wrote: > I agree with Lucas. > > Ensuring uncoordinated middleboxes can improve MoQ content delivery seems > like an impossible task, or at least out of scope for this working group. > Ensuring coordinated middleboxes/CDNs can improve MoQ content delivery > seems very much in scope. > > +1 , agree that we need to make it clear in the scope. > HTTPS proxies have been around for a long time, and MoQ shares many of > those properties. > > Ian > > On Thu, Jul 21, 2022 at 6:40 PM Suhas Nandakumar <suhasietf@gmail.com> > wrote: > >> >> >> On Thu, Jul 21, 2022 at 3:34 PM Suhas Nandakumar <suhasietf@gmail.com> >> wrote: >> >>> >>> >>> On Thu, Jul 21, 2022 at 3:08 PM Lucas Pardue <lucaspardue.24.7@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Thu, 21 Jul 2022, 10:16 Mo Zanaty (mzanaty), <mzanaty= >>>> 40cisco.com@dmarc.ietf.org> wrote: >>>> >>>>> I agree with Ali and Dan that “on-path” has a specific meaning to many >>>>> networking people which is not the meaning intended in the charter. I would >>>>> contend that is a misnomer that must be removed. >>>>> >>>>> The discussion of middle boxes has been in the context of explicitly >>>>> addressing them, not them happening to be on the network path to another >>>>> endpoint and transparently mediating the packet flow addressed to that >>>>> other endpoint. That is certainly a viable use case, but not one I’ve seen >>>>> anyone mention, perhaps because QUIC encryption makes on-path mediation >>>>> very difficult. >>>>> >>>> >>>> QUIC makes uncoordinated middlebox behaviour difficult. Even detecting >>>> QUIC traffic is tricky for such boxes. When there is coordination or >>>> cooperation between endpoints and other components in the path, things are >>>> a lot smoother. >>>> >>>> The prime example of this is QUIC load balancers that can make >>>> decisions (routing/dispatching packets) based on the connection ID. The >>>> generally works by the server picking IDs based on some scheme or algorithm >>>> and sharing that with the load balancer. >>>> >>>> I think the MoQ charter needs to be clear about whether the middleboxen >>>> are expected to work on: QUIC packets as opaque blobs, the frames within >>>> QUIC packets once protection is removed by actors who have the session >>>> keys, application data in streams, datagrams, or something else. >>>> >>> >>> These are good points Lucas. >>> >> >> >>> Atleast from my reading of relays/caches in charter was that, its where >>> the QUIC connection terminates (but not the MOQ) , akin to CDN , for >>> example. >>> >> >> >>> PeerA <-----QUIC-----> Relay <----QUIC----> PeerB >>> <---------------------------------- MOQ --------------------------> >>> >> Relays in the above contexts are special MOQ entities that perform >> specific actions to enable MOQ protocol like >> - caching, forwarding/distributing, fragmentation where necessary, >> reacting to congestion, >> These actions doesn't need access to raw media that is exchanged between >> PeerA and PeerB for instance. >> >> Cheers >>> Suhas >>> >>> >>>> Cheers >>>> Lucas >>>> >>> -- >> Moq mailing list >> Moq@ietf.org >> https://www.ietf.org/mailman/listinfo/moq >> >
- [Moq] Charter adjustment Ted Hardie
- Re: [Moq] Charter adjustment Ali C. Begen
- Re: [Moq] Charter adjustment Ted Hardie
- Re: [Moq] Charter adjustment Ali C. Begen
- Re: [Moq] Charter adjustment Ted Hardie
- Re: [Moq] Charter adjustment Dan Wing
- Re: [Moq] Charter adjustment Suhas Nandakumar
- Re: [Moq] Charter adjustment Mo Zanaty (mzanaty)
- Re: [Moq] Charter adjustment Lucas Pardue
- Re: [Moq] Charter adjustment Suhas Nandakumar
- Re: [Moq] Charter adjustment Suhas Nandakumar
- Re: [Moq] Charter adjustment Ian Swett
- Re: [Moq] Charter adjustment Bernard Aboba
- Re: [Moq] Charter adjustment Christian Huitema
- Re: [Moq] Charter adjustment Suhas Nandakumar
- Re: [Moq] Charter adjustment Bernard Aboba
- Re: [Moq] Charter adjustment Bernard Aboba
- Re: [Moq] Charter adjustment Christian Huitema
- Re: [Moq] Charter adjustment Ian Swett
- Re: [Moq] Charter adjustment Maxim Sharabayko
- Re: [Moq] Charter adjustment Ted Hardie
- Re: [Moq] Charter adjustment Lucas Pardue
- Re: [Moq] Charter adjustment Ted Hardie