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

[[e-mail]]

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 <[e-mail]>
Envoyé : jeudi 28 mars 2024 10:51
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Marcus Ihlar <[e-mail]>; Anoop Tomar <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 28 mars 2024 09:25
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Anoop Tomar <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
Objet : RE: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate

Hi Mohammed, please see inline.


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, 28 March 2024 08:51
To: Anoop Tomar <[e-mail]<mailto:[e-mail]>>; Marcus Ihlar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 27 mars 2024 20:52
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Marcus Ihlar <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 27, 2024 at 8:55 AM
To: Marcus Ihlar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 20 mars 2024 23:41
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Marcus Ihlar <marcus.ihlar=[e-mail]<mailto:marcus.ihlar=[e-mail]>>; Anoop Tomar <anooptomar=[e-mail]<mailto:anooptomar=[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, 21 March 2024 08:03
To: Marcus Ihlar <marcus.ihlar=[e-mail]<mailto:marcus.ihlar=[e-mail]>>; Anoop Tomar <anooptomar=[e-mail]<mailto:anooptomar=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Sadcdn] Clarification: AMBR v/s Media/VideoBitRate

Hi Marcus,

Thanks for the clarifications.

Please see inline.

Cheers,
Med

De : Sadcdn <[e-mail]<mailto:[e-mail]>> De la part de Marcus Ihlar
Envoyé : mercredi 20 mars 2024 14:38
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Anoop Tomar <anooptomar=[e-mail]<mailto:anooptomar=[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, 20 March 2024 14:18
To: Anoop Tomar <anooptomar=[e-mail]<mailto:anooptomar=[e-mail]>>; [e-mail]<mailto:[e-mail]>
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.


  1.  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.


  1.  Returning a global limit in a flow may be misleading, if no scope is provided
  2.  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.


  1.  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 <[e-mail]<mailto:[e-mail]>> De la part de Anoop Tomar
Envoyé : mercredi 20 mars 2024 11:27
À : [e-mail]<mailto:[e-mail]>
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.


     *   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
[e-mail]<mailto:[e-mail]>
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.