Re: [6gip] IP Address Mobility Project

[Alexandre Petrescu <[e-mail]>]

Le 23/02/2023 à 10:27, David Lake a écrit :
> Alex
> 
> QCI is set by the network as it is aware of the requirements of the 
> application.

Ah the all-knowing network... :-)

Since GPRS and until 4G I used clients on windows to connect to cellular
networks.  All clients offered some parameters for QoS settings on
cellular.  These parameters were never respected, because the network
seemed to know better.

It should be the other way around :-)

> It is not just network capabilities but also the RF numerology.
> VoLTE, for example, travels over a more robust numerology than the
> numerology on the default bearer.  This is why voice over LTE is much
> better in terms of jitter and loss than voice over WhatsApp (for
> example).
> 
> Personally, I would like to see the ability to carry out such mapping
>  across the wider Internet - I worked on proposals for H.325 to do
> just that many years ago - not just in the operator/cellular domain
> but as application needs <<<<< available bandwidth (and bandwidth has
> been relatively cheap) we haven't really had to deal with this
> problem.
> 
> We absolutely do in cellular because SLAs are based on it.

Carrying out mappings across the wider Internet is a great idea and I
support it.

I understand a little bit VoLTE, yet I dont see precisely why would it
be better than a WhatsApp voice calls, a whatsapp that I understand even
less.

I would like to know whether both VoLTE and WhatsApp work ok on IPv6 or
not.  The latter <(whatsapp) I can check myself right now, but the
former no - VoLTE is a concept bound to a particular operator, if I
understand correctly.  I am not at that operator.

That means that I can try right away a handover of an ongoing whatsapp
call between wifi and 4G.  I can show right away whether it breaks or
not.  If it breaks, I can formulate right away a requirement for it not
to break.  If it keeps up, but there are some audio glitches, then I can
formulate a requirement for these glitches to go away.

For VoLTE I cant do any of these immediately obvious steps.

But I can agree with you, based on trust, that probably VoLTE is a great
performing tool.

Alex

> 
> David
> 
> Sent from Outlook for iOS <https://aka.ms/o0ukef> 
> ------------------------------------------------------------------------
>
> 
*From:* Alexandre Petrescu <[e-mail]>
> *Sent:* Thursday, February 23, 2023 9:12:36 AM *To:* Sridhar
> Bhaskaran <[e-mail]> *Cc:* Hesham ElBakoury
> <[e-mail]>; Lake, David (PG/R - Comp Sci & Elec Eng)
> <[e-mail]>; Giles Heron 
> <giles=[e-mail]>; Toerless Eckert
> <[e-mail]>; [e-mail] <[e-mail]> *Subject:* Re: [6gip]
> IP Address Mobility Project For the traffic class mutability: the
> routers in an xGPP (3GPP) network are all under the same authority.
> This means that that authority can easily configure all intermediary
> routers to not touch on the traffic class.
> 
> Alex
> 
> Le 23/02/2023 à 05:00, Sridhar Bhaskaran a écrit :
>>> Are there proposals to replace GTP?
>> 
>> <SB> See 3GPP TR 29.892 - 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HEUdsqLk%2Fkf60NXbK%2FXjeI79BHgIWA3KDsVnH%2B1CZIw%3D&reserved=0
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HEUdsqLk%2Fkf60NXbK%2FXjeI79BHgIWA3KDsVnH%2B1CZIw%3D&reserved=0>
>>
>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HEUdsqLk%2Fkf60NXbK%2FXjeI79BHgIWA3KDsVnH%2B1CZIw%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HEUdsqLk%2Fkf60NXbK%2FXjeI79BHgIWA3KDsVnH%2B1CZIw%3D&reserved=0>>
>> SRv6 was proposed and the outcome of the study is in this TR. After
>> this IETF DMM worked on this draft independently - 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1%2FfkVw58e7Sg3xExGaL%2BMEyLnh6W5XdlGl8a5Ga7Ydc%3D&reserved=0
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1%2FfkVw58e7Sg3xExGaL%2BMEyLnh6W5XdlGl8a5Ga7Ydc%3D&reserved=0>
>>
>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1%2FfkVw58e7Sg3xExGaL%2BMEyLnh6W5XdlGl8a5Ga7Ydc%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1%2FfkVw58e7Sg3xExGaL%2BMEyLnh6W5XdlGl8a5Ga7Ydc%3D&reserved=0>>
>> 
>> 
>>> I can say that QoS can also be done with flow labels and traffic
>>> 
>> classes
>>> in IPv6 headers, without GTP.
>> <SB> Flow labels and traffic classes can be changed by on path IP 
>> devices (routers etc). 3GPP endpoints require an unmodified flow 
>> identifier. That is why they keep the flow identifier in additional
>>  layer of encapsulation (i.e in GTP header). The flow identifier
>> marked by the first 3GPP entrypoint gateway (UPF) is kept all the
>> way upto radio network in the downlink direction so that, radio
>> network can directly use that as index to look up the resource
>> allocation scheme / scheduler and RRM details. For certain services
>> like voice media (which is marked by QOS flow identifier
>> corresponding to QCI/5QI 1), mission critical services (QFI --> 5QI
>> --> 69) etc, strict SLAs are there. Network cant afford to let on
>> path routers meddle with QoS flow markers.
>> 
>> Regards Sridhar On Thu, Feb 23, 2023 at 1:16 AM Alexandre Petrescu
>>  <[e-mail] <mailto:[e-mail]
>> 
> <mailto:[e-mail]>>> wrote:
>> 
>> 
>> 
>> Le 22/02/2023 à 19:43, Hesham ElBakoury a écrit :
>> 
>> I can try to find that out.  I remember some relatively recent 
>> presentations at IETF about replacing GTP, or reducing the number
>> of headers.  It might have been in the (precursor?) of the DMM WG. 
>> (distributed mobility mgmt).
>> 
>> A related question, IMHO, would be too whether there is an RFC for
>> GTP in a first place...
>> 
>> I can remember an Internet Draft of year 2000 about GTP - named
>> simply draft-casati-gtp - but it was not pursued at IETF.
>> 
>> If there were a GTP RFC, then we could think about improving it, 
>> replacing it, etc.
>> 
>> When there is no GTP RFC, one can think about what should an ideal
>> xGPP (3GPP) network use instead.
>> 
>> Or maybe another way...
>> 
>> Alex
>> 
>>> Hesham
>>> 
>>> On Wed, Feb 22, 2023, 10:39 AM Alexandre Petrescu 
>>> <[e-mail]
>> <mailto:[e-mail]
>> <mailto:[e-mail]>> 
>> <mailto:[e-mail] 
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>> wrote:
>>> 
>>> David, Giles,
>>> 
>>> Le 22/02/2023 à 14:35, David Lake a écrit :
>>>> This:
>>>> 
>>>> “…the 5G UPF terminates the GTP tunnel but also does QoS,
>> charging,
>>>> lawful intercept etc. ”
>>>> 
>>>> … is a VERY important point.  GTP enables a number of very
>> low-level
>>>> RF features which MNOs need to control their allocation of
>> spectrum
>>>> and more importantly the numerology associated with an
>> application.
>>>> It is also used in shared solutions such a CoMP.
>>> 
>>> I can agree with the importance of the point above.  I can
>> agree about
>>> improvements there might be necessary.
>>> 
>>> I can say that QoS can also be done with flow labels and
>> traffic classes
>>> in IPv6 headers, without GTP.
>>> 
>> 
>>> But I agree with the importance of the topic.
>>> 
>>>> If we are to replace GTP (and I think there is a reason to
>> do that)
>>>> we have to provide the interactions to the layer 1 that
>> MNOs need.
>>> 
>>> I agree.
>>> 
>>> [...] Giles said:
>>>> I’m not sure that your electricity analysis is correct.
>>>> 
>>>> Doing e.g. an MPLS exact match lookup across a FIB with a few 
>>>> thousand labels rather than an IPv6 longest-match lookup
>> across a FIB
>>>> with a few million prefixes, for example, may well more
>> than offset
>>>> the extra electricity consumption caused by the extra 4
>> bytes of
>>>> header.
>>>> 
>>>> And then of course there’s all the electricity consumed by the 
>>>> control plane updates hitting the router CPUs.
>>> 
>>> I can agree.  But I do not take that as an invitation to ignore 
>>> electricity consumption.  Rather, all points you mention
>> (exact match
>>> lookup consumption, ctl plane) should be measured and told
>> who consumes
>>> more, and then decide what to reduce.
>>> 
>>> I do not take your remark as giving up electricity savings in
>> front of
>>> too much complexity of understanding what's happening.
>>> 
>>> I do not take your remark as freedom to add more headers when
>> it becomes
>>> necessary to add more functionality.
>>> 
>>> [...]
>>> 
>>>>> More details about this performance degradation can be
>> provided if
>>>>> absolutely necessary, but some times trust might also
>> help for a
>>>>> quicker understanding towards realizing a common goal.  (the 
>>>>> development of trust is another matter that we can discuss 
>>>>> separately :-)
>>>> 
>>>> Trust takes time to earn, and I’d tend to suggest that
>> arguing that
>>>> it makes sense to inject a host route for a UE into OSPF
>> may not be
>>>> the best way to earn it.
>>> 
>>> Given this apparent disparate understanding about routing -
>> you seem to
>>> be more people to be saying the contrary of what I say - I
>> give up this
>>> topic discussion on host based routes.  Maybe for later for
>> another G,
>>> maybe never.
>>> 
>>> Alex
>>> 
>>> -- 6gip mailing list [e-mail] <mailto:[e-mail]
>>> <mailto:[e-mail]>> <mailto:[e-mail]
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0>
>>
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0>>
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0
>>
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0>>>
>>> 
>> 
>> -- 6gip mailing list [e-mail] <mailto:[e-mail]
>> <mailto:[e-mail]>> 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0>
>>
>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C8951b6e70f0b432512c008db157e24f0%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127403752290988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rbZ1SLim7OAFhk%2BmkMe2gMhHYi29UO1LKWN%2ByYi%2BKKc%3D&reserved=0>>
>> 
>> 
>> 
>> -- o__ _>  /__ (_) \(_)... Burn fat not fuel - Bike along to a
>> healthier life and cleaner world! :)
>> 
>> Sridhar Bhaskaran
>>