On Fri, Oct 23, 2020 at 4:44 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. > I'm probably starting to sound like a broken record, but we chartered TAPS in 2014 to think about hiding bizarre transport attributes from applications (among other things) using an abstract application programming interface, and I note that https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ is now targeting Propose Standard, and https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-5.2.13 is about multipath.
Has anyone been looking at this? TAPS has been chugging away since before QUIC was chartered, and certainly didn't want to do anything to slow QUICv1 work down, but now that QUICv1 is past Publication Requested, should we be? Best, Spencer
