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

[Marcus Ihlar <[e-mail]>]

I agree with Tommy here.

If network advertised proxies can be used in multiple kinds of networks it makes sense to have a common discovery method.

IPv6 RAs are extensively used in 3GPP networks and have a broader applicability than PCOs, so it does seem like a good fit.



BR

Marcus



From: Int-area <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, 26 July 2023 18:53
To: Tommy Pauly <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Int-area] [Masque] draft-pauly-intarea-proxy-config-pvd



Re-,



Not sure why using PvD would be “cleaner” vs. what they are doing with PCO IEs.



There are plenty proxies that are enabled in cellular networks and being discovered by UEs already (CSCFs, etc.).



Cheers,

Med



De : Tommy Pauly <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 26 juillet 2023 09:17
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : Marc Blanchet <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [Int-area] [Masque] draft-pauly-intarea-proxy-config-pvd



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



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