[Jool-list] Default pool4 hashing does not work well with some video CDNs

[Alberto Leiva]

Oh, and also:

I removed RFC 6056 ephemerals, because they don't seem to serve a
purpose anymore.

On Sat, Apr 22, 2023 at 4:27 PM Alberto Leiva <ydahhrk at gmail.com> wrote:
>
> https://github.com/NICMx/Jool/tree/improved-rfc6056
>
> This is going to be tricky to test since you probably won't "feel"
> anything unless you have a lot of traffic, but can you at least check
> the video streaming works?
>
> 1. The pool4 *entry* (see https://nicmx.github.io/Jool/en/pool4.html)
> is decided from MD5(IPv6 source address, secret)
> 2. The pool4 entry port is decided from MD5(IPv6 source address, IPv6
> source port, IPv6 destination address, IPv6 destination port, secret)
>
> I don't know if this comes across, but suppose you have the following
> two pool4 entries:
>
> - 192.0.2.1#(1000-2000), TCP
> - 192.0.2.1#(3000-4000), TCP
>
> Even though they have the same address, they are different *entries*,
> so different IPv6 sources will hash into them. I'm assuming this is
> not going to be much of a problem because it rarely happens.
>
> f-args doesn't do anything anymore, and it's marked as deprecated.
>
> The code still falls back to attempt to use the next entry if it can't
> find a valid transport in the original, which I think is a little
> better than giving up altogether.
>
> On Fri, Apr 21, 2023 at 8:41 PM Alberto Leiva <ydahhrk at gmail.com> wrote:
> >
> > Actually, that's a great idea. I'll try implementing it over the weekend.
> >
> > On Thu, Apr 20, 2023 at 10:57 AM Ondřej Caletka <ondrej at caletka.cz> wrote:
> > >
> > > On 20/04/2023 17:07, Alberto Leiva wrote:
> > > >> Or perhaps even change the pool4
> > > >> allocation algorithm so that it tries to stick to one IPv4 address for
> > > >> one source address and just randomize ports used.
> > > > But how is this different from f-args 8?
> > >
> > > If I understand the docs correctly, algorithm of Jool treats pool4 as a
> > > flat list of (IPv4, port) tuples. The F-function is run and its result
> > > chooses one of the tuples. If that one is in use, a possibly CPU-intense
> > > algorithm is run to find a free tuple adjacent to the one chosen by F.
> > >
> > > That is, with f-args=8, every session originated from the same IPv6
> > > source address will always try to select one particular tuple. So every
> > > second and further session from the same host will trigger this
> > > collision resolution process.
> > >
> > > What I would like to see instead would be to use F with f-args=8 only to
> > > select IPv4 address. Once it is selected, another F could be run, this
> > > time with f-args=15 (or 7) to select a port within that IPv4 address.
> > > This way it would be guaranteed that one IPv6 address is always masked
> > > behind one IPv4 address and at the same time there would be less collisions.
> > >
> > > But maybe I'm just too scared of the collision resolving algorithm :)
> > >
> > > --
> > > Cheers,
> > >
> > > Ondřej Caletka