Hi Sri <dl> in-line </dl>
Well here and hope you are too – been too long!!!! David From: Sri Gundavelli (sgundave) <[email protected]> Date: Tuesday, 15 November 2022 at 05:22 To: Lake, David (PG/R - Comp Sci & Elec Eng) <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Media Header Extensions for Wireless Networks Hi David, Hope you are doing well! Thank you for your feedback. Please see inline From: David Lake <[email protected]> Date: Monday, November 14, 2022 at 1:22 AM To: Sri Gundavelli <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Media Header Extensions for Wireless Networks Hi Sri Thank you for the very interesting presentation at 115 last week. [Sri] My co-author John did the presentation. I’d like to make some comments about your proposal which I think has much wider implications than ‘just’ the air interface. 1. We have a mechanism in LTE/6G for ensuring delivery of packets in a more expeditious manner – IMS. It has the benefit of tying the capabilities and performance of the air interface to the packet core. Other than for VoLTE/VoNR, we have never used its full potential! We even have multiple classes of service defined already… [Sri] I assume you are referring to the QoS markings for traffic classification, and around DSCP markings. Agree, the 3GPP QoS architecture has the semantics for defining traffic QoS flows with different latency/loss/ characterizations. It follows the IETF’s diff-serv architecture. The problem statement we have at hand goes beyond what the classic QoS architectures can support. Our goal is to bring media awareness to the transport; expose certain meta-data that allows the transport to make certain decisions. This awareness includes the markings on the different frames that video compression tools generate, expose the relation between the frames, and the relative importance of frames within the same flow. This awareness if present in the RAN/transport will result in greatly improving the user experience, and reduction in packet discards. The current QoS models do not have the semantics, we can provide a marking at a flow level and it ends there. <dl>. Agree. The diff-serv is not granular enough. My idea would be to expand the TFT to match on something OTHER than DSCP related to the requirements of the data in the packet. For example, the application could add a cryptographically-signed key to the URI of any packets/HTTP sessions containing I-Frames and the TFT could be programmed to identify these and steer into the appropriate QCI/5QI. Only the embedded TFT in the UE and the UPF would be able to identify the requirement – it would not be possible to write a UE-only application capable of steering traffic in this manner. The signature could include meta-data information (for example, the frame-rate and quality so hence the required bandwidth). I suggest that the end application (i.e. the service, not the UE client) is responsible for allocating and distributing the marking – for example, via the SMF to the UPF and AMF to the UE. This would, of course, require extensions to the 3GPP architecture. </dl? 1. We need to channel our inner George Orwell. ‘All [packets] are created equal, but some are more equal than others.’ Understanding the requirements of a specific application especially where the access media is highly limited is important. Unlike wireleine, 5G/6G/whateverG are unlikely to reduce in price and increase in capacity yet Internet access is 92% over these technologies now. We have to start understanding the applications and matching ‘network’ resources accordingly. [Sri] 😊 In a capitalistic world, some packets are more equal than others. Agree, network needs to understand the application requirements. <dl>. I am seeing the same discussion in the apn, can and 6gip groups. We need to move towards the entire infrastructure being driven in a customer-outcome orientated manner IMvHO </dl> 1. Each UE has a TFT as the way of steering traffic into the ‘correct’ bearer at the correct QCI/5QI. To-date, this is very rough – simple 5-tuple – but there is no reason why this could not be expanded to take input from metadata in the manner you suggest. [Sri] I understand what you are saying. You are suggesting defining different forwarding behaviours at a frame level. I-frame has more priority than P and B frames. It is fine, but this does not capture the dependency graphs. For example, the loss of a certain frame makes the related frames irrelevant. We cannot model such relationships with this approach. But, I agree with you we should consider applying QoS flow definitions at a more granular frame level and not just a flow level. <dl> If the marking was more dynamic and under control of the application where the application is the combination of the app on the UE and the server, then I think it would be possible to react to loss in this manner. You would even be able to tell the UE (or application) to throw away P/B Frames until the next I-frame by changing the meta-data sent to the client… </dl> So I have a proposal. * We design an API between the TFT and the application which enables specific packets (e.g. the I-Frame) to be marked in some manner. * This should be marked so that any encryption is maintained. * By ‘application’ I think we need to consider that application = UE app + data centre app NOT a ‘app’ on the UE. * Traffic which requires a higher level of handling is transported in the dedicated bearer with the correct QCI/5QI and associated radio numerology. Outside of the scope of this group but of wider interest would be how I could maintain that QCI and packet treatment beyond the SGi/N6 interface across other packet networks to/from the data source. [Sri] Thanks for the excellent feedback. Lets see what ideas we can bring them in to the spec. Regards Sri All the best David David Lake Tel: +44 (0)7711 736784 [Text Description automatically generated with low confidence] 5G & 6G Innovation Centres Institute for Communication Systems (ICS) University of Surrey Guildford GU2 7XH
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
