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

[Nicolas Kuhn <[e-mail]>]

Hi,

This looks like an interesting way of solving the E2E encryption and PEP
dilemma that deserves to be looked at.

In the SATCOM use-case, you mention that the SC can influence the sending
rate (slide 8).
While this may "solve" one of the problems PEP try to resolve (exploit the
adequate rate), PEP are interesting for other aspects : increasing endpoint
sending buffer sizes, local loss recovery or "slowstart" convergence.
It could be interesting to look at these aspects and in particular the
required interaction between the SC interaction with the E2E encrypted
traffic.

Also, in most SATCOM scenarios, there are two TCP-PEP proxies in sequence.

The approach is very interesting and I would be happy to read more about
this.

Cheers,

Nico

On Thu, Mar 24, 2022 at 3:06 PM Michael Welzl <[e-mail]> wrote:

> 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=[e-mail]> 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 <[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
> _______________________________________________
> Panrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg
>
>
> _______________________________________________
> Panrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg
>