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

Hi !

Many thanks for the friendly words - actually, many thanks to everyone today for that!
Some comments below:

> On Mar 24, 2022, at 2:40 PM, Holland, Jake <jholland=40akamai.com@dmarc.ietf.org> wrote:
> 
> Hi Panrg and Spencer,
>  
> I might have liked Michael’s proposal too,

Keith & Michael’s !   Importantly, Keith deserves the credit for splitting this off into a separate protocol, which is the really main deal here IMO.

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

So we all agree that there are some tricky things to work out - and that’s even with only a single SC proxy. Sure, supporting multiple would be nice, but … you don’t even need to consider multipath to see problems with this.
First, SC proxy 2 ACKs to SC proxy 1 about a specific flow X. Then, flow X doesn’t even traverse SC proxy 1 anymore, only SC proxy 2. How would SC proxy 2 know?

That thought alone made me feel like looking at the root of a tree… out of which endless branches can grow.

>  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,

Yes; they are easier when piggybacking ACKs, because this signaling traffic then shares the same tuple as the main traffic, but otherwise, NATs can prevent some use cases, and there is the problem of identifying the “main” traffic the SC is talking about. Again multiple design choices there...

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

That really depends on the use case.

>  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?)

Yes…

> 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?

Aha; maybe?

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

I don’t think the client always needs to be involved to be able to do some good with this. As I tried to illustrate with the two use cases, what needs to change really depends on the case it is.

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

Thanks for the feedback! :)

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

Aha - with tunneling, the problem above probably goes away, yes…

Cheers,
Michael

>  
>  
> From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> Date: Thu,2022-03-24 at 5:44 AM
> To: "panrg@irtf.org" <panrg@irtf.org>
> 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
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg