Joe, Conrad, and I have been bouncing around ideas for quality of service.  There will come a time when served agency traffic is more important or urgent than general ham traffic.  Any QoS functions will need to recognize that and give the agency traffic higher priority through the mesh.

Brain Storming idea on the table:

Create a way for an "Incident/Event Organizer" to define the event on a master mesh node:

1) New setup screen to define incident/event, e.g. "RACES County MOU Drill 12345", "County Marathon Comm Support", etc.

2) Define 'cluster' list of nodes that are allowed to join and allowed to be included in the cluster.

3) Define usage of rule set "A" -- predefined QOS levels

4) Activate

Create a setup page for Node owners/admins to accept and join the incident:

1) create setup page to "join" and "disconnect" to the defined incident using QOS rule set "A".

Anyone can define a given incident cluster on their node, but owners of other respective mesh nodes in the cluster control and choose to join or not. Incident owners work to ensure sufficient coverage of nodes will meet the needs of the incident. Pre-defined "package" install and updates for QOS rules to be applied to the nodes.

Example QOS rule sets:

A) Non-incident traffic is entirely blocked/ignored/dropped.

B) Non-incident traffic is contained at 128kb/256kb/1M/etc. bandwidth

C) ???

Joe AE6XE

Sounds to be a reasonable suggestion.

I would add the need to integrate into OLSR Metric to (artificially) degrade the link for reporting so that nodes that are outside the "incident" will attempt to route around it to avoid even routing through a QOS net, that may on its own reduce the contention (if auxiliary connections exist) and when an connection doesn't than it will go through the incident net.

Downside to this is that means is that a packet may go through a lossy path reducing its speed and increasing network traffic at the expense of avoiding the network. If it's non incident traffic that probably will be fine I imagine,

I also wonder how to combine multiple distinct group policies on high level nodes that may want to support multiple groups,  do they need to dedicate to a single group, arrange to coordinate that all the rules for all the groups in the area into one policy?   Do we add the option for most nodes to pull the master policy but set individual nodes override the policy? I know in my case I work on a repeater site that supports 3-5 organizations at any given incident (depending upon activations.

Yes, that is the most common way to do it. Of course, we need to consider the implications of using self-issued certificates – just as we do today for SSH – versus certificates issued by some other trusted verifying authority.  All of this will develop over time and I expect that groups of meshers will have different solutions to the same problem. That is a good thing – provided that approach has documented their rules for what constitutes an acceptable credential and the uses for each type. That way we can compare the rules and possibly derive a rule-set that is usable across wider areas and larger meshes.

Setting up and running a certificate infrastructure is another complication. This needs to be designed carefully to both provide the flexibility we need in our environment (many diverse groups with differing requirements including rapid ad hoc responses) and avoid the complexity and assumptions of typical corporate enterprise  implementations.

There should always be a place for issuing and using simple passwords as we are doing now. The simple, cheap solution should always have a place as a valid credential for many uses.

In addition to your suggestions, we might want to use authentication to differentiate among people or devices that have access to:

-        Specific parts of a local mesh network, like a command post versus a tactical team which focuses on a specific area

-        Specific services where some people are allowed to view a camera and others not.

-        Specific sub-services, where all participants can use the phone services but only within specific call groups.

-        Limiting the geographical reach of a mesh network. It makes sense to develop and test with networks across many states, but it would probably be a distraction, at best, to allow a network in Texas that is supporting an emergency operation to be visible in California, New Jersey or Europe. We might want to turn geographical limits on and off at will, and do so quickly as the need arises, and the local authorities decide.

-        Prevention and detection of abuse or misuse.

All the best,

Randy WU2S

On Behalf Of Darryl Quinn
Sent: Wednesday, December 03, 2014 22:40
Subject: Re: QoS and directory services

Interesting ideas.  Are you thinking about using a public/private key pair (ie. the ssh certs that we all use) to drive the authentication that would control "secure features" of the mesh.

Consider the following potential "authenticated features":

- internet gateway routing

- tunnel server connections

- QoS