Re: [PANRG] About Michael's proposal on sidecar protocols in PANRG today

["Holland, Jake" <[e-mail]>]

Hi Panrg and Spencer,

I might have liked Michael’s proposal too, I’m still not quite sure yet.  To me the tricky-sounding parts go beyond multipath (though multipath can certainly be a stopper or complication for some potential solutions).

Stuff I like:

  *   I think it makes great sense in general to find a way to give the endpoints some kind of hint and ongoing guidance saying “your end-to-end congestion controller is probably going to be making deeply stupid performance choices unless you listen to me”, which I think(?) is roughly the core purpose of a PEP.
  *   I also think the hash-based acking of packets (I think at the UDP payload layer?) is a natural mechanism to do that with, once you’ve got the endpoint<->PEP communication channels you’d need.

Stuff I’m unsure of:

  *   The part about how to get the endpoint-PEP communication channels you’d need sounds tricky
  *   I’m not so sure about ignoring multiple on-path PEPs.  If you want to handle both satellite and microwave, it’d be nice not to declare that out of scope too early.  (I won’t insist on including it in the end if there’s an otherwise good proposal that can’t do that, but I would prefer answers to “how to do the endpoint-PEP communication” that don’t make this impossible, if there are multiple answers that are approximately equally good.)

I can think of a few ways to do those endpoint-PEP channels, but if you want to talk to the client side as a PEP you’re going to very likely have NAT issues too, and I think(?) you might need to talk to the client side to do a good job as a pep.  At very least if you want retransmits after downstream loss to be a part of this story, but probably also if you want to be able to drain the pep’s queue in a reasonable way.

So maybe you have to successfully talk to the server first (which a PEP could maybe do on a well-known port on the sender’s IP, offering a client cert to identify itself so servers can do some vetting?) and the server could relay the PEP’s server name to the client so it could open a connection and get the channel it needs as well?  I’m not sure.  I don’t offhand see another way for the PEP to reach the client thru a NAT unless it injects something in the target stream in a way that passes the NAT, which seems... probably trickier.

Anyway, very interesting question.  I do hope there’s a good answer here, and thanks Michael and Keith for raising it, you’ve definitely got me thinking.

-Jake

PS: I think some PEPs operate as a 2-ended tunnel over (for instance) a satellite link, rather than a single on-path node.  I think some possible approaches here won’t care, but others might.


From: Spencer Dawkins at IETF <[e-mail]>
Date: Thu,2022-03-24 at 5:44 AM
To: "[e-mail]" <[e-mail]>
Subject: [PANRG] About Michael's proposal on sidecar protocols in PANRG today

Dear PANRG,

I liked Michael's proposal, and I suggest that we spend some time thinking about interaction with multiplath, now that all REAL transport protocols support multipath ... 😀

Best,

Spencer