Discussion paper for Issue#34 and PR#123

[eric-murray]

The discussion paper raises two separate topics:

Terminology

The paper proposes to replace the terms public and private used in PR #123 with observed and local. I make the following observations:

• For the "normal" case when IPv4 CGNAT is in operation, the observed parameters will be the public parameters, and the local parameters will be the private parameters. The terms are essentially synonymous. For IPv4 scenarios, I would expect CGNAT to be in operation for the vast majority of commercial use cases for this API.
• For the "exception" case when CGNAT is not in operation, the terms are not synonymous:
  • The parameters in use will be either private or public (almost certainly private), but cannot be both
  • The observed and local parameters will therefore be identical
• As I only really care about the first case (when CGNAT is in operation), I really don't mind whether the terms private / public or local / observed are used. It's not at all clear to me which terminology a developer will find more intuitive. I would suggest a poll to decide this.

API Design and Constraints on API Caller Input Options

Good API design not only allows the API caller to specify the parameters required, but also places logical (i.e. machine enforceable) constraints on the values and combinations of parameters that can be specified.

Required Parameter Combinations The discussion in Issue #34 showed that the following parameter combinations are required if the API caller wishes to identify the UE using its IPv4 address:

• The API caller MUST specify the public IPv4 address as well as EITHER the private IPv4 address OR the public port
• Using the proposed terminology, the API caller MUST specify the observed IPv4 address and EITHER the local IPv4 address OR the observed port

The proposal on Page 9 of the discussion document does not help to enforce these requirements

• If the API caller specifies an IPv4 subnet as localIpAddr, there is no requirement for them to also specify an observedIpAddr IPv4 subnet
• If the API caller specifies an observedIpAddr IPv4 subnet, there is no requirement for them also to specify either a localIpAddr IPv4 subnet or a uePorts->observedPorts value

Much of the discussion in Issue #34 and the associated PR #123 was about trying to enforce these requirements on the API caller, who may not understand why they need to additionally provide public_address if they want to identify the UE by private_address, but must understand that they have to do it.

Additional observations

• The discussion paper proposal introduces a new requirement that, if the UE is identified by IP address(es), then either IPv4 or IPv6 addresses must be specified, but not both.
  • This excludes dual-stack scenarios, which are currently allowed by the API design. Mixed IPv4 / IPv6 scenarios deserve a whole issue to themselves, and should not be excluded without some additional discussion.
• Separate local and observed fields for IPv6 addresses don't really make sense as they will always be the same value
• The proposal allows for UEs to continue to be identified by arbitrarily large subnets, when the discussion in the issue concluded that UEs should be identified by single IP addresses
• Knowing localPorts is useless for identifying the UE (because all UEs can use almost any source port value) but observedPorts is useless for flow descriptions. The two reasons for specifying ports (UE identification and flow descriptions) should be separated. Only a single observed (i.e. public) port should be specified.
• More generally, it is not clear to me that localPorts is required for flow descriptions rather than just using wildcards. Maybe if the UE is acting as a router and sending multiple flows to the same application server IP:port combination, then different QoS levels will be required for the different flows, but how does the API caller learn the local port in that case? Anyway, use of UE ports in flow rules requires a separate discussion issue of its own.

I will shortly make an alternative proposal in the original Issue #34 which deals with using the API design to constrain allowed API caller input parameter options.

[eric-murray]

@emil-cheung As discussed during the meeting, the discussion paper omits the scenario that Issue #34 was originally created for, which is where the device (i.e. UE) or, more specifically, an application running on the device directly requests the QoD service.

In this case, the device can easily find its private (local) IPv4 address if it does not know or have other parameters (external identifier, msisdn, etc.) but, as discussed in Issue #34, this is insufficient to identify the device uniquely. Hence the proposal is that the device obtain its public (observed) IPv4 address and then provide both parameters to the QoD service.

How does the device obtain its public IPv4 address? By using DNS, as follows:

dig @resolver1.opendns.com A myip.opendns.com +short -4

Try it - it really works. It works for any DNS client (e.g. nslookup) with suitable syntax changes, but you have to use the opendns resolver (or another resolver that supports this functionality). There are also HTTP APIs that can be used to obtain this information.

So a mobile app can obtain sufficient information to identify itself by IPv4 address to the QoD service without involving the application server, and the proposed API changes in Issue #34 were designed to address this scenario.