[pim] Re: New I-D: draft-karstens-pim-multicast-application-ports

[Toerless Eckert <[e-mail]>]

Nice idea. Not sure how important and crucial it is. Some thoughts:

I am worried if multicast applications may not run into 49150/49151 being pre-bound
by some unicast app - without SO_REUSE*.

COuld we not find two other ports that are not at risk of this use collisions ?

It would be good to validate the a actual behavior of different relevant OS stacks.
For example, the drafts says "SO_REUSEADDR and/or SO_REUSEPORT". Sounds like nob ody
knows exactly whats required and/or OS implementations differing correctly or incorrectly
versus POSIX. Or POSIX being unspecific.

Early on, the kernel/socket API libraries did not filter messages. It would really be nice
to know how well kernel level filtering because of different multicast addrs now works.
Because if we start to reuse the same port, we will have in high-speed application potentially
create a lot more unnecessary punting of packets to use-level and filtering there - which
would render the benefits of this scheme questionable. a lot more
There 

I would suggest to not imply that ports may not be known anymore. We have built enough
signalling where the port-numbrer is signalled, and while we could technically avoid that
and assume the 49150/49151 default, i'd rather take that step only after a lot more deplopyment
experience.

But most importantly: I am primarily worried about the filtering when using SSM.
I would fear that filtering of (S1,G) does not happen if another process susbscribes to
(S2,G). If thats the case, then the filtering by port number which does very work well
in the kernel may be the saving grace to avoid unnecessary punting and dropping at process
level.

Cheers
    Toerless

On Tue, Jul 09, 2024 at 07:25:50AM +0000, Karstens, Nate wrote:
> Hello, pim,
> 
> I wanted to make everyone aware of a new Internet Draft, available here:
> 
> https://datatracker.ietf.org/doc/draft-karstens-pim-multicast-application-ports/
> 
> This document covers the related presentation at IETF 118 (see https://www.youtube.com/embed/QDiHD9I64T4?start=3338&end=3530)
> 
> Abstract:
> 
> This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning two UDP ports specifically for use with multicast applications and lists requirements for using these ports.
> 
> Chairs - can we please have some time to discuss this during the pim session at IETF 120?
> 
> Any feedback would be greatly appreciated!
> 
> Thanks,
> 
> Nate Karstens
> Garmin International
> National Marine Electronics Association

-- 
---
[e-mail]