Re: [Roll] [manet] IETF 114 manet meeting presentation

["Adamson, Robert B CIV USN NRL (5592) Washington DC (USA)" <[e-mail]>]

Ron,

To answer your question regarding pcap support, nrlsmf still supports the option to run with pcap only.  It also still supports the option to use the IP tables “divert” rule to access packets but that only works for IPv4 and I plan to deprecate that since it adds unnecessary complexity to the code and is not as useful and easy to support as the Tun/Tap option that is set up with the “device” command-line option in nrlsmf.  That option uses _both_ a Tun/Tap interface it creates to serve as the virtual network device for protocols to use as a routable interface and the “stacks” that virtual interface upon a “pcap” (PF_PACKET on linux) interface to the physical interface device.  We’ve also used this in conjunction with other virtual interfaces including those associated with an OvS switching layer for various purposes.

The advantage of using the Tun/Tap is that nrlsmf does not just get a copy of packets that it can choose to forward or not, but emplaces its process in-path so that additional things can be done.  With the elastic multicast option, this includes only transmitting packets over the air when there are actual multicast group members subscribed and only sending packets over the combination of interfaces needed to reach group members.   I also implemented a form of the Upstream Multicast Packet (UMP) header extension to provide IP previous hop information for operation on IP-based wireless subnetworks that provide their own native multicast mechanism for layered heterogeneous “network of networks” use cases and leveraged a reserved portion of the UMP extension for a sequence number to measure link quality for forwarded multicast packet flows to support use of the ETX routing metric to build multicast sub-trees from the SMF flooding plane.  I don’t yet have slides to cover all these details but could do that for a future meeting.

I’ve been working to separate/modularize the forwarding plane functionality from the control plane functionality in the interest of paring down forwarding plane state and functionality in the interest of helping inform and define a future kernel level forwarding module that supports what is needed for IP multicast approaches like SMF and the experimental Elastic Multicast work.   The “flow-based” (protocol:src:dst tuple) approach is also applicable to some forms of unicast routing with duplicate packet filtering also useful for more than just multicast.   My progress on this has been slower than I like since the time I can spend on this is opportunistic and limited.  The code is all on GitHub and I am happy to answer questions about it as I can.  There are some very experimental options in there (not all good ideas after some testing 😉 ) too like “reliable forwarding” that implements a primitive retransmission mechanism.  But those options are configurable and more basic SMF operation is the default behavior.  Even though it is a user-space forwarding engine, we have managed to get pretty good performance with.it.

Best regards,

Brian

From: manet <[e-mail]> on behalf of "Velt, R. (Ronald) in 't" <Ronald.intVelt=[e-mail]>
Date: Tuesday, July 26, 2022 at 6:25 PM
To: "Adamson, Robert B CIV USN NRL (5592) Washington DC (USA)" <brian.adamson=[e-mail]>, "Rogge, Henning" <[e-mail]>, "[e-mail]" <[e-mail]>, Babel at IETF <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [manet] IETF 114 manet meeting presentation

[Dear MANETeers, Babelites, ROLLers, I am going to cross-post replies to various posts on the Babel and MANET MLs or to mails to the chairs over the past two weeks in semi-random order, in an attempt to get us on the same page for Friday’s joint session. Apologies for the noise in case you are not interested in multicast, the topic of that session.]

Hi Brian,

Sorry for the delayed reply and good to hear from you! Please see inline.

Ron, Henning,

I am not sure if I can participate in the live meeting next week, but I could provide some information and even slides to Henning (if he’s interested)  on the nrlsmf data plane.  The current code has evolved a bit since we last presented an overview at an IETF meeting.   Or if you want to identify this as a possible future presentation if there’s interest let me know.

While it would be truly awesome if you could participate, a contribution in any way, shape or form is most welcome! In my own presentation, I was going to refer extensively to the excellent presentation Justin Dean gave in the MANET session at IETF-96 (see slides: https://www.ietf.org/proceedings/96/slides/slides-96-manet-1.pdf ). An update on work done by NRL in recent years would be very relevant, in my opinion. Slides can either go into Henning’s presentation or mine. (Or you can have your own presentation slot, if you can make it).

My current “go to” approach for the data/forwarding plane as a user-space process has been to use a combination of PF_PACKET socket (on Linux … other mechanisms on the other operating systems supported that includes MacOSX, Windows, Android, and other Unix platforms). and a Tun/Tap virtual interface with the protocols configured on the Tun/Tap interface.

(Does this mean the pcap-based approach has been abandoned for nrlsmf?)

This is a  topic of particular interest for me.  One thing I have been doing is more clearly separating the data/forwarding plane aspects of SMF/Elastic Multicast implementation from the control plane.  There are some events triggered by things that happen in the data plane (e.g., detection of multicast flow activity/inactivity) and part of the approach is achieve sufficient functionality while minimizing what happens in the forwarding plane and limiting the amount of interaction between the control plane and data plane.  Some of our work has included working with Open vSwitch (OvS) and I have been looking at this in the interest of what data/forwarding plane functionality could be embedded within OvS to support MANET multicast.   The idea would be then to have an option besides the user-space forwarding engine approach currently used.

Very interesting. I definitely would like to hear more about that. Another option, at least in theory, would be to improve multicast forwarding support in (Linux) kernel space, as already hinted at by Henning.

Thanks!
Ronald

Best regards,

Brian


From: manet <[e-mail]<mailto:[e-mail]>> on behalf of "Velt, R. (Ronald) in 't" <Ronald.intVelt=[e-mail]<mailto:Ronald.intVelt=[e-mail]>>
Date: Friday, July 22, 2022 at 5:19 AM
To: "Rogge, Henning" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [manet] IETF 114 manet meeting presentation

Hi Henning,

That would certainly be a useful contribution to our session, in my opinion. I checked with the chairs of the other groups: there was positive feedback from Donald Eastlake and silence from the ROLL chairs (which we will interpret as approval 😊 How much time do you think you need? I’ll adapt the agenda accordingly once I get to Philly. (Am travelling today).

Thanks!
Ronald

From: manet <[e-mail]<mailto:[e-mail]>> On Behalf Of Rogge, Henning
Sent: donderdag 21 juli 2022 15:44
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [manet] IETF 114 manet meeting presentation

Hello,

I will be attending (online) the IETF 114 MANET meeting and would like to give a short presentation about the practical problems of multicast routing.

A “how the hell should we do the data-plane” talk.

I know, it’s in theory and implementation issue and not a protocol one, but I think it is a VERY relevant problem for MANET, because there is no good solution on Linux (which is often and widely used for MANET implementations) and I worry that other operation systems have similar issues.

In the end, if the data-plane is bad, nobody will use any protocol we talk about.

Henning Rogge

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.