Re: [Masque] [Int-area] draft-pauly-intarea-proxy-config-pvd

[Tommy Pauly <[e-mail]>]

Indeed, I don’t think 8801 is currently deployed by the carriers, but the target of this document is to have a standard, cross-network way to bootstrap the discovery of these proxies.

Using IPv6 RAs and related information to advertise proxies would allow 3GPP to provide this as a clean discovery option, and one that will work on any network attachment as well. This makes the incentive for clients to adopt higher since it will work across all networks.

Tommy

> On Jul 26, 2023, at 7:48 AM, [e-mail] wrote:
> 
> Hi Tommy,
> 
>> - ... on cellular
>> carrier networks, which is one of the main deployment targets
>> here.
> 
> Unless I'm mistaken 8801 is not required/supported in 3GPP specs. Typically, PCO IEs are used there.
> 
> FWIW, the network already provides the following to a UE (excerpt from 23501):
> 
> == (0-RTT Converter)
> iii)	The network shall send MPTCP proxy information to UE, i.e. the IP address, a port number and the type of the MPTCP proxy. The following type of MPTCP proxy shall be supported in this release:
> -	Type 1: Transport Converter, as defined in IETF RFC 8803 [82].
> 	The MPTCP proxy information is retrieved by the SMF from the UPF during N4 session establishment.
> 	The UE shall support the client extensions specified in IETF RFC 8803 [82].
> ==
> 
> And 
> 
> == (MPQUIC Proxy)
> The network shall send MPQUIC proxy information to UE, i.e. one IP address of UPF, one UDP port number and the proxy type (e.g. "connect-udp"). This information is used by the UE for establishing multipath QUIC connections with the UPF, which implements the MPQUIC Proxy functionality.
> =
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Int-area <[e-mail] <mailto:[e-mail]>> De la part de Tommy
>> Pauly
>> Envoyé : mardi 25 juillet 2023 23:34
>> À : Marc Blanchet <[e-mail] <mailto:[e-mail]>>
>> Cc : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>> Objet : Re: [Int-area] [Masque] draft-pauly-intarea-proxy-config-
>> pvd
>> 
>> Hi Marc,
>> 
>> To start — I have no objection to there being some mechanism to
>> discover a proxy using dns-sd / bonjour! If someone has a good use
>> case for that, that certainly is a possibility.
>> 
>> I do think it would be a different use case than the one for this
>> network-provided proxy provisioning, however. A couple salient
>> points to consider:
>> - While the local router may be able to point you to the
>> appropriate proxies to use, the proxies themselves are likely not
>> on the local link or multicast area. Instead, they would likely be
>> some infrastructure associated with the network operator, deeper
>> in the network.
>> - A dns-sd solution would allow many parties to advertise such
>> capabilities on the network. The case we’re concerned with here is
>> knowing the one that comes from a network operator, not other
>> peers.
>> - While I can’t rule it out categorically, I’m not aware of many
>> cases where we’d be able to use multicast dns-sd on cellular
>> carrier networks, which is one of the main deployment targets
>> here.
>> 
>> Thanks,
>> Tommy
>> 
>>> On Jul 25, 2023, at 3:57 PM, Marc Blanchet
>> <[e-mail]> wrote:
>>> 
>>> Hello,
>>> Saw your presentation yesterday at masque and now read your
>> draft. Fine by the overall approach, but I was wondering if you
>> have considered to use DNS-SD (aka Bonjour)? I could see a proxy
>> on the local network advertising its proxy service and the client
>> « finding » the proxy by the DNS-SD/Bonjour mechanism. Seems
>> straightforward to me. Also enables multiple proxies to « offer »
>> their service, so redundancy right out of the box. In other words,
>> I’m looking at this as a service discovery not provisioning. I am
>> surely missing something?
>>> 
>>> Regards, Marc.
>>> 
>>> --
> 
> ____________________________________________________________________________________________________________
> 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.