Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate
Dan Wing <danwing@gmail.com> Fri, 29 March 2024 00:02 UTC
Return-Path: <danwing@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 D4AECC16942B for <sadcdn@ietfa.amsl.com>; Thu, 28 Mar 2024 17:02:09 -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 1bAFWWO1s_jE for <sadcdn@ietfa.amsl.com>; Thu, 28 Mar 2024 17:02:06 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 1DA21C151997 for <sadcdn@ietf.org>; Thu, 28 Mar 2024 17:02:06 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1e0bec01232so13735615ad.3 for <sadcdn@ietf.org>; Thu, 28 Mar 2024 17:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711670525; x=1712275325; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=hy63egpKHWh9ATnDu6DnWRaalChICoD4aZrux2qKE7g=; b=MKgqsB1BXbSf9TV5u4KjJqPI92nSJzExobMjZfA/w6NlAF813H0oPVrm6I3jKuMvWZ V9XIi/ttUQoQjGyFifrf/2Fr51wbWO+FMbW5u/DgqaVC6TJt6qNe0o9IPX4vjr7clMT4 GXWYorPKf+vQT70G2dyu+4Y6xsPhdRAfsvBjkkX7UEXH2ADg3MhrLN6bVOqSGSSh5K8l 854JgoOeKndk4FHw3KAGjA1wvSvxZ1cP1zZt7CaQ5zjqbHjYckO2ruP9NmK16imQVpc6 0gpdumTHo8/iH/y1Sh3iy45UkE30mfCt4qrksjImo/AwJ5I45/B+pEqmUX6jfP4X0r1M 4wuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711670525; x=1712275325; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hy63egpKHWh9ATnDu6DnWRaalChICoD4aZrux2qKE7g=; b=OqtNNoeIMnNvbXcJEmNSw4fegel1yz23pbkSZ02FSWEUKsieMgnXxVNhTwcuRrwAeI h2Y5lSvlDn6fHZrGIq5r+qv58zrsdtWSMLuIvbPrnFKua1tUPS3PDv0mhXbSV/Ggzt5x D9tSqi7s/qwIJrLViKmnV3DqK2ysBFa+zTfSAMMUESWSM0Gkvk1bG20QXtf/hmpZWYrY dDVRmz+G6mTF4n+O5cc01NeQB/xNx1kahjahptl0qw42+WSgziBl5dyAJprtCovNv8ur HHeWjicY+V7R5WyPnekK20YInKBOhoAxgQZ8zj+nfLBWpzdYNz7i4ltdyh70DOOprSiB WRAQ==
X-Forwarded-Encrypted: i=1; AJvYcCV00JTX+NXYb5Kr+bDp4MX3DzrXTbE4X5Wq6VjYeubuB5y0B2Ewa0gd+EEcHf0saF0N8M/n7zbd/DN3d1z2e8k=
X-Gm-Message-State: AOJu0YzgIMgUaWzb7s9OWUgS39EGwNIGBQqNUzOJwhHPdBjtucmGlvdp BLwtThjEoPNKchSlMXaBAg16D4S7JO1RW3tDTIIoQUEw5JV0AjRe
X-Google-Smtp-Source: AGHT+IFXjciWY/rYFlntIlJ81N8mPTUgMy8Kw1fun1eSMvOsKo6qCGv++ZDCGFCWhuwyBvVTvx7Lgg==
X-Received: by 2002:a17:902:da87:b0:1e0:e2c2:578c with SMTP id j7-20020a170902da8700b001e0e2c2578cmr1278110plx.11.1711670525079; Thu, 28 Mar 2024 17:02:05 -0700 (PDT)
Received: from smtpclient.apple ([47.208.219.53]) by smtp.gmail.com with ESMTPSA id d5-20020a170902c18500b001dddce2291esm2233676pld.31.2024.03.28.17.02.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2024 17:02:04 -0700 (PDT)
From: Dan Wing <danwing@gmail.com>
Message-Id: <2E6345BC-0514-44CD-BD79-9214B505B777@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_295E7D94-D17C-4808-9CF6-6EE424841541"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Thu, 28 Mar 2024 17:02:03 -0700
In-Reply-To: <CADdTf+iYU0MN2_YsSjsa+wXiLocnfkVS_4QoPKoK2ifi6zNGRw@mail.gmail.com>
Cc: Mohamed Boucadair <mohamed.boucadair@orange.com>, Marcus Ihlar <marcus.ihlar@ericsson.com>, Anoop Tomar <anooptomar@meta.com>, sadcdn@ietf.org
To: Matt Joras <matt.joras@gmail.com>
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> <CADdTf+iYU0MN2_YsSjsa+wXiLocnfkVS_4QoPKoK2ifi6zNGRw@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sadcdn/nQ4GPw-m-3gU6PCF3y3iVXftWZU>
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: Fri, 29 Mar 2024 00:02:09 -0000
Matt, What is "application type"? Is that a MIME type? Or is it like "this is the TikTok app" or "this is the Chrome browser visiting tiktok.com" or "this is the Speedtest app". The latter three are akin to what cellular providers are obtaining today with TLS SNI sniffing. So would SCONE send the TLS SNI to the network operator or perhaps send a combination of the TLS SNI and the client application name (or hash of its executable)? -d > On Mar 28, 2024, at 1:39 PM, Matt Joras <matt.joras@gmail.com> wrote: > > 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 <mailto: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 <mailto:matt.joras@gmail.com>> >> Envoyé : jeudi 28 mars 2024 10:51 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> >> Cc : Marcus Ihlar <marcus.ihlar@ericsson.com <mailto:marcus.ihlar@ericsson.com>>; Anoop Tomar <anooptomar@meta.com <mailto:anooptomar@meta.com>>; sadcdn@ietf.org <mailto: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 <mailto: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 <mailto:marcus.ihlar@ericsson.com>> >> Envoyé : jeudi 28 mars 2024 09:25 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; Anoop Tomar <anooptomar@meta.com <mailto:anooptomar@meta.com>> >> Cc : sadcdn@ietf.org <mailto:sadcdn@ietf.org> >> Objet : RE: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate >> >> >> >> Hi Mohammed, please see inline. >> >> >> >> >> >> From: mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> >> Sent: Thursday, 28 March 2024 08:51 >> To: Anoop Tomar <anooptomar@meta.com <mailto:anooptomar@meta.com>>; Marcus Ihlar <marcus.ihlar@ericsson.com <mailto:marcus.ihlar@ericsson.com>> >> Cc: sadcdn@ietf.org <mailto: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 <mailto:anooptomar@meta.com>> >> Envoyé : mercredi 27 mars 2024 20:52 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; Marcus Ihlar <marcus.ihlar@ericsson.com <mailto:marcus.ihlar@ericsson.com>> >> Cc : sadcdn@ietf.org <mailto: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 <mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> >> Date: Wednesday, March 27, 2024 at 8:55 AM >> To: Marcus Ihlar <marcus.ihlar@ericsson.com <mailto:marcus.ihlar@ericsson.com>> >> Cc: sadcdn@ietf.org <mailto:sadcdn@ietf.org> <sadcdn@ietf.org <mailto: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 <mailto:marcus.ihlar@ericsson.com>> >> Envoyé : mercredi 20 mars 2024 23:41 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>; Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org <mailto:marcus.ihlar=40ericsson.com@dmarc.ietf.org>>; Anoop Tomar <anooptomar=40meta.com@dmarc.ietf.org <mailto:anooptomar=40meta.com@dmarc.ietf.org>>; sadcdn@ietf.org <mailto: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 <mailto:sadcdn-bounces@ietf.org>> On Behalf Of mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> >> Sent: Thursday, 21 March 2024 08:03 >> To: Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org <mailto:marcus.ihlar=40ericsson.com@dmarc.ietf.org>>; Anoop Tomar <anooptomar=40meta.com@dmarc.ietf.org <mailto:anooptomar=40meta.com@dmarc.ietf.org>>; sadcdn@ietf.org <mailto: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 <mailto: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 <mailto:mohamed.boucadair@orange.com>>; Anoop Tomar <anooptomar=40meta.com@dmarc.ietf.org <mailto:anooptomar=40meta.com@dmarc.ietf.org>>; sadcdn@ietf.org <mailto: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 <mailto:sadcdn-bounces@ietf.org>> On Behalf Of mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> >> Sent: Wednesday, 20 March 2024 14:18 >> To: Anoop Tomar <anooptomar=40meta.com@dmarc.ietf.org <mailto:anooptomar=40meta.com@dmarc.ietf.org>>; sadcdn@ietf.org <mailto: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: >> >> >> >> 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. >> >> >> >> 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. >> >> >> >> Returning a global limit in a flow may be misleading, if no scope is provided >> 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. >> >> >> >> 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: >> >> Cost vs. Benefit >> Impact on operations vs incentive to deploy >> 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: >> >> Signals shared are only hints, especially when shared outside of the connection establishment. UEs can simply ignore these signals >> 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 <mailto:sadcdn-bounces@ietf.org>> De la part de Anoop Tomar >> Envoyé : mercredi 20 mars 2024 11:27 >> À : sadcdn@ietf.org <mailto: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) >> >> >> >> 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. >> >> >> >> 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. >> >> >> The UE-AMBR limits the aggregate bit rate across all the flows on all the non-GBR bearers of a UE/User. >> >> >> 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. >> >> >> 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 <mailto: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. > -- > Sadcdn mailing list > Sadcdn@ietf.org > https://www.ietf.org/mailman/listinfo/sadcdn
- [Sadcdn] Clarification: AMBR v/s Media/VideoBitRa… Anoop Tomar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Marcus Ihlar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Marcus Ihlar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Matt Joras
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Matt Joras
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Anoop Tomar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Qin Wu
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Marcus Ihlar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Anoop Tomar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Marcus Ihlar
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Matt Joras
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Matt Joras
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Dan Wing
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… Matt Joras
- Re: [Sadcdn] Clarification: AMBR v/s Media/VideoB… mohamed.boucadair