Active Interest Filtering for Distributed Simulation Scalability

1. Northrop-Grumman (TASC) and the University of Massachusetts, Amherst HARP HLA Active Routing Project Specialized Active Networking Technologies for Distributed Simulation (SANDS)

2. The Distributed Simulation Scalability Problem What We Have... • Multicasting for scalability • Receiver, network overload from indiscriminate delivery What We Want... • Ability to receive only needed information-- Active Interest Filtering

3. Data Provider Has: D, E, F Active Packet F not needed by any receiver -- eliminated immediately D F E Active Node D E B and D not needed by left rcvr -- eliminated at earliest point Data Provider B Active Packet’ D C C E Has: A, B, C A A and E not needed by right rcvr -- eliminated at earliest point B D C C E A Data Subscribers Needs: A, C, E Needs: B, C, D A A B B C C Active Interest Filtering Aggregate Available Content: A, B, C, D, E, F Aggregate Needed Content: A, B, C, D, E - Unneeded data eliminated at earliest opportunity - Exact filtering provides optimal delivery efficiency

4. S S S 3) Pushed upstream towards the sender. 1) Message with interest header sent to multicast group 2) Filter on outbound interface evaluates header Key S - Sender A - Active RouterR - Receiver 2) Merged into a single Ifilter by the Active Nodes, and... AR AR AR AR AR AR 3) Allows message through 1) IFilter (Interest Filter) subscriptions from downstream interfaces are... 4) Filter evaluates header AR 5) Discards message AR AR R R R R R R R R R R R Simple Example Filter Installation Filter Operation R R R R

5. Simulation Host Active Router SANTS Module IFilters Merged IFilters Distributed Simulation(ModSAF) AFSP Host Module SANTS IFilters AFSP Sim Data Filter Manager Subscriptions Filter Manager Filtered Data AN Mods Parameters Simulation Data Filtered Data HLA-Compliant RTI Filter (Firewall) Filters Simulation Data Active Interest Filtering Architecture • Secure filter signaling using SANTS (NAI Labs) • SANTS/AFSP integration (Aerospace) • Active Filter Signaling Protocol (AFSP) and ASP EE (ISI) • Filtering and simulation components (TASC/UMass) • HLA-compatible RTI (GaTech)

6. Red Tank Platoon A (3 T-72M Tanks) Red Tank Platoon D (3 T-72M Tanks) Active Routers Local ModSAF Hosts* Local ModSAF Hosts* 100baseT ethernet LAN** Red Tank Platoon B (3 T-72M Tanks) Blue F16 Flight (8 Aircraft) Active Interest Filtering Demonstration

7. What We’ve Accomplished To Date • Dynamic, active interest filtering • Running under a real HLA-based simulation • With code modifications almost exclusively limited to RTI components • Using Active Networks • With substantial, quantifiable improvements in network efficiency • And virtually no added latency

8. And Some Nice Extras • Coordinated, integrated activities from interested potential end-customers • DMSO authorized and funded Georgia Tech RTI work • STRICOM authorized and funded ModSAF enhancements • Interaction of two EEs in same host • Mix of real and tunneled multicast

9. Key Performance Innovations • Two-pass Filter Setup • Use knowledge of upstream filtering to reduce, distribute processing load • Decision Tree Organization • Organize interest filters as a decision tree • Processing proportional to log of no. of filters vs. linear with no. of filters • Filter Simplification • Approximate large numbers of filters with a smaller number of simpler covering filters

10. AR AR AR AR AR AR Two-pass Signaling Example Response filters from publisher (exact filtering) Active Routers Active Routers DENY filters Subscriber Requested Filters ACCEPT filters

11. AR Interest Filtering: Key Insight • Subtle but important differences from graphics problems: • Need only determine if packet falls within any subscriber filter, not which filter it falls within 2) Publisher provided response filters IF in REGION then ACCEPTELSE DENY ACCEPT filters DENY filters Active Router 1) Subscriber provided request filters Filter tree needs only a single test

12. Filter Tree Construction • Four problems of interest: • Two primary cases: with or without traffic density information • Average vs. worst-case performance metric • Two variations per case: explicit or implicit DENY filter representations • Two-pass vs. single pass signaling DENY filters ACCEPT filters Explicit DENY filters from two-pass signaling Implicit DENY filters from one-pass signaling

13. Base Problem Filter Space Accept Filters Leveraging Traffic Density Information Density Info Available: Probabilistically Biased Tree Density Info Unavailable: Balanced Tree DENY ACCEPT ACCEPT ACCEPT DENY DENY DENY ACCEPT

14. Foreshadowing Leveraging Upstream Filtering Information Upstream Filtering Information Unavailable Upstream Filtering Information Available D A D A A D D A A A D A A D

15. Tree Construction Approach • Tree construction must also be fast • Optimal construction has high computational complexity • Solution: constrain each step in the construction to a single level search, estimating results of any subsequent processing • Then: given a set of filters within some region , partition into subregions and so as to minimize where are estimates for the depths of the two subtrees that will be constructed from filters in and respectively are the probabilities that a packet will fall in subregions and given that it falls in region , respectively

16. Explicit DENYs with Density Information • Subtree depth estimated as log of number of filters • Equivalent to Huffman bound assuming equiprobable filters • Full Huffman bound possible: less accurate, more work • At each step, may use either ACCEPT or DENY filters • Choose type with minimum cardinality (fewest decisions) • Add in some cost for opposing sense (e.g., 0.5*card(), 1, etc) • Cost metric then becomes where is the cardinality of filters of type FILTERTYPE in A

17. RESULTING FILTER TREE CANDIDATE SPLIT 1 CANDIDATE SPLIT 2 D A D A Selection Example BASE PROBLEM card(left A) = 6card(left D) = 0P(left) = 1/3card(right A) = 3card(right D) = 9P(right)=2/3Metric = 4/3 card(left A) = 8card(left D) = 1P(left) = 1/2card(right A) = 8card(right D) = 1P(right)=1/2Metric = 1

18. Mappings to Remaining Problems • Without density information (i.e., P()) metric becomes • Without explicit DENY filters, metric becomes • Without density info and without explicit DENYs

19. Concluding Remarks …coming clean...

20. Lessons Learned: Failure No. 1 • We’ve been solving the wrong problem • Not so much a filtering problem • Does this packet go out this interface (for each interface)? • But more a routing problem • Which set of interfaces does this packet go out?

21. AR AR Solving the “Right” Problem IF1 IF1 • Not multiple, independent egress filter trees returning accept/deny results • Instead, a single ingress filter tree returning list of admissible egress interfaces, integrated with forwarding functions • Eliminates redundant, per interface filtering IF2 IF1 IF1 IF2 IF1 IF2 IF1 IF2

22. Lessons Learned: Failures No. 2 and 3 • We didn’t anticipate security impact in current design • Active routers create new filters through aggregation, but • Dynamic content not (easily) securable • Filter aggregation also causes an overhead problem • Change from any user ripples through entire the system: • But new aggregate filter highly redundant with previous filter • As number of filters becomes large, aggregate filters too big for signaling mechanism, forces simplification • Filter simplification adds overhead, inefficiency • Non-zero simplification processing time • Simplification can result in excess data delivery

23. Solution (?) • Avoid aggregation • Propagate user filters end-to-end • (Much!) smaller and static: can be secured • Obviates (for the most part) need to simplify • Exact information throughout the tree eliminates overhead, inefficiency • At odds with current AFSP design point • Rethinking signaling approach

24. S’all Questions?