Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate

Matt Joras <matt.joras@gmail.com> Thu, 28 March 2024 20:39 UTC

Return-Path: <matt.joras@gmail.com>
X-Original-To: sadcdn@ietfa.amsl.com
Delivered-To: sadcdn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6285CC151998 for <sadcdn@ietfa.amsl.com>; Thu, 28 Mar 2024 13:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 3xIOEjaRPyQY for <sadcdn@ietfa.amsl.com>; Thu, 28 Mar 2024 13:39:26 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 ED0E4C151073 for <sadcdn@ietf.org>; Thu, 28 Mar 2024 13:39:25 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-56c5d05128dso95449a12.0 for <sadcdn@ietf.org>; Thu, 28 Mar 2024 13:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711658364; x=1712263164; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xYyTBv/Lx7cG6N2pOxZ2kcGXl+G8R/PkVv61ekuxetw=; b=BAq714uydtNlkE9ypNSMILeGXfAAZfOqvUhxmAf5+vRnSf9qBtBYlBG+NmWDPh9rWY 5rL7W+2VlZMicLmUmaQRSpvnRyfUoxhPrMIqH6T0xQ2A0dMzPspS7irNGT+fAgyjoDrl NlJswZDV+y/xdAzFNfA88W75F1ePzQJkSO1CO0fJc/91blG3Yn0cldhlM+Myw1arFvvH 1YV4qib+ZCjlTlgRVIlY7P0Xs8UZHGT7vvIMDAkF2xY7wfEMr1LFCYqJxSO82KQ9rhG/ T/U4gcuLUpilifDUfrp/PID+eB9qW7BUrpSLWSTu55DWlSqCUEu33OOOqyUzkCiBR+58 k9mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711658364; x=1712263164; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xYyTBv/Lx7cG6N2pOxZ2kcGXl+G8R/PkVv61ekuxetw=; b=Lo07+sRn+m+beREntiCqi9LtMQJqoDvB1TU5TXh+dEk0cpU5Wo+Pg5FZ5LswgrUazJ RX3VOE3fOHv+CSLrXt7StNIXpy9uYO3NnC7/PC9YE7Ymd7T2HGaHHPR+/zRrxsEa9Qd3 DuYRQcWi2UJOdnSgtQYbw0ZEX2WUdKla8fj1YYBWgCq+JKN6+ajzTlts1uPAZNPR2nCj YItBPlM66wbKBseLZMxmOZ8+OsyblMTa3GgSjc2DwJxyChusPpiZodvh3daE0XgHyTGn NNNcEoKZjUWNFqrZYMiqlgy+Ns6A2KmIpvyMR6VWeYLNh5eY36duDISST8ortRVNiO+0 9dgQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4k58fxYyXEScZCEdTYH69h9tadSKsC3d8wrdS6k+ZS5neU8da8PwME+v22LHu0XVNHI6HR0z+T0qFS7ReAIE=
X-Gm-Message-State: AOJu0Ywxf1yPeGZQP8Wwm0Fr2y4dPRcVGl1ckfd/B3vtPjkosLpdrvSW 3zkgeCOIleD9q1UaorK+pOHX97/lMTcg6qRyx2j413znvBhvTn9SjgMVcPe2Z4GB7VG7/Sgif7d mC7xzD0YGWWCodZEEUQjFM5l/W2Stg/eUvxA=
X-Google-Smtp-Source: AGHT+IFDCuEK8hmC/Cq3tf9svTLdIYO+ziUWe/LvTwh6tSR5kMh3d8TvPU/cfZzjkCOINM5JzLuenaT6VbAh7vz4CNU=
X-Received: by 2002:a05:6402:278c:b0:56c:1bf7:164d with SMTP id b12-20020a056402278c00b0056c1bf7164dmr297371ede.20.1711658363268; Thu, 28 Mar 2024 13:39:23 -0700 (PDT)
MIME-Version: 1.0
References: <LV3PR15MB64354F482366D07A6A01AF31B2342@LV3PR15MB6435.namprd15.prod.outlook.com> <DU2PR02MB1016068EF3696376485280BA9883B2@DU2PR02MB10160.eurprd02.prod.outlook.com> <AS2PR07MB8978941D03CCDD6B0E3BB63CE23B2@AS2PR07MB8978.eurprd07.prod.outlook.com> <DU2PR02MB101603B364FE2F30B6C757382883B2@DU2PR02MB10160.eurprd02.prod.outlook.com> <CADdTf+jT_L++z3UaVfQTugJKFgrrCor3j8X6B0W-XZKJmmx9eg@mail.gmail.com> <DU2PR02MB10160F10C446F9F468BABB3FD883B2@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB10160F10C446F9F468BABB3FD883B2@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: Matt Joras <matt.joras@gmail.com>
Date: Fri, 29 Mar 2024 07:39:09 +1100
Message-ID: <CADdTf+iYU0MN2_YsSjsa+wXiLocnfkVS_4QoPKoK2ifi6zNGRw@mail.gmail.com>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Cc: Marcus Ihlar <marcus.ihlar@ericsson.com>, Anoop Tomar <anooptomar@meta.com>, sadcdn@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b833af0614be841f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sadcdn/deHpAJe0MSwDW78Y_HuFQC4Bo8k>
Subject: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
X-BeenThere: sadcdn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Securing Ancillary Data for Communicating with Devices in the Network <sadcdn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sadcdn>, <mailto:sadcdn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sadcdn/>
List-Post: <mailto:sadcdn@ietf.org>
List-Help: <mailto:sadcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sadcdn>, <mailto:sadcdn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2024 20:39:30 -0000

Can you clarify why you believe communicating the application type is not
required?

Let's step back. The existing practice is that operators identify and
target ABR video flows with a certain management, shaping or policing. They
do this for a variety of reasons but generally it's motivated by data usage
limitation. The only tool they have to do this is policing or shaping the
traffic after identifying it based on DPI or heuristics. This shaping has
objectively poor outcomes on video playback.

Thus the existing system we are looking to replace is contingent on network
shapers identifying flows as containing certain kinds of application
traffic, namely ABR video. The alternative we seeonto standardize is a way
for the network to not shape the traffic but rather communicate its
requirements of that traffic to the client application, and the client
application will have the option to self-adapt instead of being shaped.

This is all in the draft charter to set up the exact problem we are trying
to solve right now and to avoid scope creep for the initial working group
effort. Indeed we have received feedback that we need to investigate
_further_ into solution sketches to justify the viability, i.e. whether
this problem can be solved by a working group.

First though we clearly need to get on the same page about the problem and
I hope this helps.

Matt

On Thu, Mar 28, 2024, 11:26 PM <mohamed.boucadair@orange.com> wrote:

> Re-,
>
>
>
> It is … because it makes assumptions about how collaboration can be put
> into effect. Your explanation confirms it. IMO, revealing the application
> identity is not required. Also, it is not given that host-to-network
> signals are mandatory for the network-to-host signals to be effective.
>
>
>
> This is exactly the reason I’m more for focusing on the metadata
> independent of the signaling channel to understand their purpose and
> inherent properties:
> https://datatracker.ietf.org/doc/draft-rwbr-sconepro-flow-metadata/. We
> need to keep in mind the conclusions in RFC 9065 (Section 7).
>
>
>
> Let’s clarify the problem to be solved rather than including a solution
> sketch into a charter.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Matt Joras <matt.joras@gmail.com>
> *Envoyé :* jeudi 28 mars 2024 10:51
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> *Cc :* Marcus Ihlar <marcus.ihlar@ericsson.com>; Anoop Tomar <
> anooptomar@meta.com>; sadcdn@ietf.org
> *Objet :* Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Mohamed,
>
>
>
> Could you elaborate why you think this particular section is solution
> biased? As for a technical reason, there certainly is one. As previously
> discussed the idea here is to offer an alternative to traffic shaping based
> on DPI and heuristic approaches. To do that the flow inherently needs to
> offer up information about what application it carries to the network
> device so as to cooperate. Indeed, the flows today carry that information
> implicitly and is extracted without the application knowing.
>
>
>
> A requirement of any solution we arrive at is to change this to an
> explicit signal and for the application to adapt instead of the network
> shaping.
>
>
>
> Matt
>
>
>
> On Thu, Mar 28, 2024, 7:38 PM <mohamed.boucadair@orange.com> wrote:
>
> Re-,
>
>
>
> I’m afraid that the proposed charter text you shared is solution-biased. I
> would avoid transforming a charter into a pre-spec document :-)
>
>
>
> Anyway, I disagree especially with having this part frozen in a charter,
> especially when there is no apparent technical motivation for it:
>
>
>
> “Associativity with an application. The network properties must be
> associated with a given application traversing the network, for example a
> video playback.”
>
>
>
> Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Marcus Ihlar <marcus.ihlar@ericsson.com>
> *Envoyé :* jeudi 28 mars 2024 09:25
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Anoop
> Tomar <anooptomar@meta.com>
> *Cc :* sadcdn@ietf.org
> *Objet :* RE: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Mohammed, please see inline.
>
>
>
>
>
> *From:* mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> *Sent:* Thursday, 28 March 2024 08:51
> *To:* Anoop Tomar <anooptomar@meta.com>; Marcus Ihlar <
> marcus.ihlar@ericsson.com>
> *Cc:* sadcdn@ietf.org
> *Subject:* RE: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Anoop,
>
>
>
> Your clarification is reasonable and glad to hear that the plan is to
> leverage existing mechanisms at the network side. I will be circulating a
> proposal SOON.
>
>
>
> However, I still don’t get this part from Marcus reply: “Here we have a
> possibility to make that identification more deterministic than how it’s
> done today with DPI and similar methods”.
>
>
>
> The purpose of SCONEPRO is to improve the current situation where networks
> throttle video. Today video flows are being detected using DPI and
> heuristic methods prior to applying the shaping.
>
> The current charter proposal states:
>
>
>
> “Associativity with an application. The network properties must be
> associated with a given application traversing the network, for example a
> video playback.”
>
> “Client initiation. The communication channel is initiated by a client
> device, just as the end to end application flows are also typically
> initiated by a client.”
>
>
>
> So, by establishing the channel the client explicitly states that it
> wishes to receive this information and that it might use it for
> self-regulation. Whether any additional information is required will depend
> on the specific solution.
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Anoop Tomar <anooptomar@meta.com>
> *Envoyé :* mercredi 27 mars 2024 20:52
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Marcus
> Ihlar <marcus.ihlar@ericsson.com>
> *Cc :* sadcdn@ietf.org
> *Objet :* Re: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Mohammed,
>
>
>
> Thanks for follow-up question. Pls see inline response as [AT].
>
>
>
> Thanks,
>
> Anoop
>
>
>
>
>
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
>
>
>
> *From: *mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> *Date: *Wednesday, March 27, 2024 at 8:55 AM
> *To: *Marcus Ihlar <marcus.ihlar@ericsson.com>
> *Cc: *sadcdn@ietf.org <sadcdn@ietf.org>
> *Subject: *Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
> Hi Marcus,
>
>
>
> Thanks for the follow-up.
>
>
>
> For this specific point:
>
>
>
> ==
>
> MI: This information is not system-wide necessarily, applications need to
> actively engage to obtain the information.
>
> *[Med] ACK, but this also means that application identification is needed
> at the network element to identify the application and bind it a specific
> policy + bind a context with a subscriber profile. These are lot of
> assumptions with inherent complexity.*
>
> MI2: Correct, the application needs to be identified to some degree. Here
> we have a possibility to make that identification more deterministic than
> how it’s done today with DPI and similar methods.
>
> =
>
>
>
> Do you have in mind exposing things such as OSAppId or other identifiers
> to the network? If so, isn’t that a privacy breach?
>
>
>
> [AT] : We are not proposing any out of band mechanism between CSP n/w and
> client to establish association between user/subscriber and flow and to
> help n/w to detect the flow.  Since SCONE is proposing on-path interface
> based communiction  b/w client and CSP n/w device ( for e.g pkt core user
> plan device – PGW/UPF) to exchange n/w meta-data, there is no need for
> client to share any subscriber specific identifier with the n/w because n/w
> already has mapping b/w flow , bearer and subscriber . And there is no need
> for n/w to share this information with the client. So in short, the client
> would not get any PII information, subscriber policy and n/w policy for a
> subscriber. One of the motivations behind using an on-path interface for
> SCONE is to avoid the need for the client to know about association between
> user/subscriber and flow. This helps in avoiding any privacy breach.
>
>
>
> W/o going into specifics ( solution aspects) of exact mechanism of flow
> détection via on-path interface signaling I don't foresee that we would
> need mechanism like OSSid (which is configured in client via USRP rules
> through “out of band” manner either through NAS signaling or manually) to
> help detect the flow.  We can discuss and share the exact mechanism while
> detailing out the solution aspects.
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Marcus Ihlar <marcus.ihlar@ericsson.com>
> *Envoyé :* mercredi 20 mars 2024 23:41
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Marcus
> Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>; Anoop Tomar <
> anooptomar=40meta.com@dmarc.ietf.org>; sadcdn@ietf.org
> *Objet :* RE: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Mohammed,
>
> Thank you for your comments.
>
>
>
> More answers inline as MI2.
>
>
>
> BR
>
> Marcus
>
>
>
> *From:* Sadcdn <sadcdn-bounces@ietf.org> *On Behalf Of *
> mohamed.boucadair@orange.com
> *Sent:* Thursday, 21 March 2024 08:03
> *To:* Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>; Anoop
> Tomar <anooptomar=40meta.com@dmarc.ietf.org>; sadcdn@ietf.org
> *Subject:* Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Marcus,
>
>
>
> Thanks for the clarifications.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Sadcdn <sadcdn-bounces@ietf.org> *De la part de* Marcus Ihlar
> *Envoyé :* mercredi 20 mars 2024 14:38
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Anoop
> Tomar <anooptomar=40meta.com@dmarc.ietf.org>; sadcdn@ietf.org
> *Objet :* Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Mohamed,
>
> Thanks for sharing your considerations. I’ve made some comments inline.
>
>
>
> BR
>
> Marcus
>
>
>
> *From:* Sadcdn <sadcdn-bounces@ietf.org> *On Behalf Of *
> mohamed.boucadair@orange.com
> *Sent:* Wednesday, 20 March 2024 14:18
> *To:* Anoop Tomar <anooptomar=40meta.com@dmarc.ietf.org>; sadcdn@ietf.org
> *Subject:* Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi Anoop,
>
>
>
> Thanks for clarifying the scope of the bitrate metadata in the sconepro
> context.
>
>
>
> With this clarification, I think the set of operational considerations I
> presented in tsvwg apply here:
>
>
>
>    1. Networks usually don’t assign quota per flow, application. So, *which
>    information to return?*
>
> MI: Many networks do, and this is in fact the motivation behind this work.
> Typically, there are application-type specific policies associated with
> user subscriptions. The most common case is to shape ABR video traffic.
>
> The information to return would correspond to the policy that is applied
> in the network. A media bitrate value for instance.
>
>
>
> *[Med] **So, this is a static information, which is not per-flow or
> specific application. Putting aside, all the hidden assumptions about
> classification/identification of application traffic, how supplying such an
> information (if available as you said) would be superior to all the
> bitrates already available to the UE? If there are specifics, why not
> sharing that additional information during the attachment of the network? *
>
>
>
> MI2: How static this information is varies between deployments, there are
> operators that use a single shaping bitrate for all subscribers of a
> particular class, others have somewhat dynamic shaping rates, based on
> measured or predicted network load. With SCONEPRO, this information is
> communicated directly to the application, or the networking stack the
> application uses.
>
>
>
>    2. Access control/rate limits are bound to a subscriber; not specific
>    device. So*, how a per-host information can be computed?*
>
> MI: The information that is sent using SCONEPRO is based on information
> already used by the network device that does the shaping. It is information
> that is usually determined on subscriber level, but applies to particular
> services.
>
> *[Med] **What do you mean by a particular service? A host that receives a
> per-subscriber policy may misinterpret that information as it is scoped to
> it but it is shared among all the devices of that specific subscriber.
> Hosts behind the same mobile CPE will all be handled as one single host.*
>
> MI2: A particular service in this case could be a YouTube or Facebook
> video session. Today these are detected using DPI or heuristic methods, the
> flows perceived to belong to that session are being shaped. Shaping as
> deployed today is likely problematic with regards to tethered devices, with
> something like SCONEPRO the situation can be vastly improved since the
> applications on each device can obtain this information separately.
>
>
>
>    3. *Returning a global limit in a flow may be misleading*, if no scope
>    is provided
>    4. Subscribers having distinct service offerings are serviced via same
>    access node.* System-wide limits are not thus always possible*
>
> MI: This information is not system-wide necessarily, applications need to
> actively engage to obtain the information.
>
> *[Med] **ACK, but this also means that application identification is
> needed at the network element to identify the application and bind it a
> specific policy + bind a context with a subscriber profile. **These are
> lot of assumptions with inherent complexity.*
>
> MI2: Correct, the application needs to be identified to some degree. Here
> we have a possibility to make that identification more deterministic than
> how it’s done today with DPI and similar methods.
>
>
>
>    5. Cascaded bottlenecks may be observed, *supplying a local
>    information may not reflect the actual properties of a path*
>
> MI: The information supplied reflects a policy that the network device
> intends to enforce in some way, either through shaping or by facilitating
> application self-adaptation.
>
> *[Med] **self-adaption is not efficient here is it adapts to a policy
> which is not reflecting the actual network conditions. *
>
> MI2: If the operator has a goal of reducing video application volume in
> their networks, self-adaptation is a very efficient way of realizing that.
> You can argue that this method of network management is inefficient, but it
> is a fact that many large operators manage their networks in this way
> today. Further, as stated earlier, these policies might be completely
> static or somewhat dynamic based on some level of awareness about network
> conditions. The way we’ve designed the SCONEPRO prototype it is possible to
> support dynamic policy updates.
>
>
>
> Let alone the *deployability* tradeofs for networks:
>
>    1. Cost vs. Benefit
>    2. Impact on operations vs incentive to deploy
>    3. Enhanced experience vs. impacts on nominal mode
>
> MI: The networks that would deploy this are those who already perform
> service specific traffic shaping (ABR video shaping) which today is already
> quite complex and costly to deploy. SCONEPRO can lead to less deployment
> complexity in these cases.
>
> *[Med] **Not sure I understand the less complexity argument for at least
> two reasons:*
>
>    1. *Signals shared are only hints, especially when shared outside of
>    the connection establishment. UEs can simply ignore these signals*
>    2. *If a network puts in place such a shaping policy, it will still
>    use it as it does not trust the host behavior. Maintaining the OLD behavior
>    + new processing to share the signal is more complexity, not less for these
>    networks.  *
>
> MI2: Right, there will be a period where you will need to maintain both
> approaches.
>
> Networks that do not do shaping of this sort will of course have less
> incentive to deploy this initially.
>
> *[Med] Ack.*
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Sadcdn <sadcdn-bounces@ietf.org> *De la part de* Anoop Tomar
> *Envoyé :* mercredi 20 mars 2024 11:27
> *À :* sadcdn@ietf.org
> *Objet :* [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
>
>
>
> Hi All,
>
>
>
> During IETF 119 session we have got this question from many IETF
> participants *“why can’t network use 3GPP NAS signaling & AMBR (session
> AMBR or APN-AMBR) parameter to communicate the allowed data rate with the
> client endpoint ?” *
>
>
>
> I am using this mail to clarify this question.
>
>
>
> What is AMBR (*Aggregate Maximum Bit Rate)*
>
>
>
>    1. This is specified in 3GPP specification and it is configured by
>    CSPs as part of subscriber policy in mobile packet core.
>
> Mobile packet core control-plane element sends APN-AMBR or Session AMBR to
> “user-equipment/mobile phone” using NAS ( Non access stratum) signaling
> specified in 3GPP spec. This signaling takes place between Mobile packet
> core control-plane element (MME for 4G and AMF/SMF for 5G) and mobile
> phone’s 3GPP modem stack.
>
>
>
>    1. Definition of AMBR - *Aggregate Maximum Bit Rate allowed for the
>    user for all the service data flows (SDFs ; different app flows) on all the
>    non-GBR bearers.  User can have one or many non-GBR bearers. And on each
>    non-GBR bearer user can have multiple SDFs. *
>
>
>
>    1. The UE-AMBR limits the aggregate bit rate across all the flows on
>       all the non-GBR bearers of a UE/User.
>
>
>
>    2. In simple term , UE-AMBR value can be used by CSPs to cap the
>       aggregate bitrate for *all the flows on all the non-GBR bearers for
>       the UE/user.* This flow can be any flow as long as it is on non-GBR
>       bearer.  CSP typically serves all the internet services/flows ( streaming ,
>       OTT RTC, b/g service, internet browsing) on non-GBR bearer.
>
>
>
>    3. It does not work at specific flow level within a non-GBR bearer for
>       the UE/user.
>
>
>
>
>
> *SCONE-PRO problem statement is about bit-rate adaptation for media/video
> streaming flow, which is essentially a flow within a non-GBR bearer. So
> 3GPP NAS signaling and AMBR cannot be used to serve the requirement of
> SCONE-PRO problem statement. *
>
> *As part of SCONE-PRO we would need to specify meta-data ( allowed
> media/video bit rate and some other parameters) to be shared by network
> (based on n/w property) with the client. *
>
>
>
>
>
> Thanks,
>
> Anoop
>
>
>
>
>
> PS: There are 3 terms related to AMBR; UE-AMBR (4G and 5G), APN-AMBR( 4G)
>  and Session-AMBR ( 5G) . For the sake of simplicity, I am not going into
> specific details of each of these parameters.. However, the key point is
> that these parameters & NAS signaling can-not be used to serve the
> requirement of the SCONE-PRO problem statement.
>
>
>
>
>
> ____________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> ____________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> ____________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> --
> Sadcdn mailing list
> Sadcdn@ietf.org
> https://www.ietf.org/mailman/listinfo/sadcdn
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>