Hi Roland, On Fri, Oct 23, 2020 at 10:37 PM Roland Zink <[email protected]> wrote:
> Hi Lucas, > > > 1) Just opening a second QUIC connection is not enough as it will most > likely use the same path as the first. Some API to list interfaces and > their properties is needed. Then the second second connection can be bound > to the desired interface. If for example you want to check the available > WiFi networks in Android then you need location permissions and the user > needs to grant them and can revoke them anytime. In addition you need to > write some legal text what you do with this data. > > > 2) Is probably similar to 1) but may use some system library to do the job > and hide it from the application itself. > > > I can't speak for others but my expectation would be that some OS-level > API should abstract network layer information when possible. Still and e2e > solution will reveal the clients changing external IP addresses on the > server side. A longer lived multipath connection may be used to track the > user. > Thanks for your thoughts. One of the touted benefits of QUIC is the ability to iterate and experiment with more freedom. Requiring OS or platform APIs would seem to provide friction to that. There might be some interesting questions about the deployment reality for QUIC extensions that need such capabilities, compared to QUIC extensions that can operate in their own bubble. Cheers Lucas > >
