Re: Privacy considerations of multipath (Re: My BoF report: multipath)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Christian,

On Fri, Oct 23, 2020 at 5:19 PM Christian Huitema <[e-mail]>
wrote:

>
> On 10/23/2020 3:10 PM, Spencer Dawkins at IETF wrote:
> > 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.
>
>
> I think you are hearing practical reasons to not do what TAPS is
> proposing, and instead to use the close coupling between the application
> and the QUIC implementation to make better transport decisions. In
> practice, application code is developed for a specific implementation of
> QUIC, and that implementation gets ported to all platforms that provide
> UDP sockets or equivalent.
>

I'm sorry, I wasn't clear in my e-mail.

I think where we are, is that there are two flavors of applications - the
kind that would do better than a general purpose transport with multiple
paths, and the kind that doesn't need to handle the paths in detail.

I was thinking of the second category. I could usefully have included that
caveat in my note.


> > 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?
>
>
> It's a free world. Of course you can do that. Whether that's useful is
> for you to decide.
>

Sure. I was mostly looking at the author list for
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/, and wondering
if anyone was already doing that.

Best,

Spencer


> -- Christian Huitema
>
>