Subject: [Dots] DOTS and QOS

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Nov 2015 15:11:42 -0600

This is an opening for a business model of positioning DOTS relays 
within the provider network.

All of this is orthogonal to DOTS.  It is potentially smart 
implementations and deployments.

DOTS must not assume QOS is present to ensure message flow on a 
congested path.  I believe this is already in the req ID.

But an interesting opportunity.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Nov 2015 10:15:11 -0500

On Tue, Nov 10, 2015 at 4:11 PM, Robert Moskowitz
<[email-masked]> wrote:
> This is an opening for a business model of positioning DOTS relays within
> the provider network.

the question about QOS during the meeting wasn't about packet qos, but
about 'qos' inside the stream of data between client/server.

Essentially, if you have message types like: (and these are TOTALLY MADE UP!!)
    1) helo msg
    2) dos-help msg
    3) statistics reporting msg

would you chose by convention or by standard to send dos-help before
helo (for instance) during times of stress?

I think the answer to that question assumes you know something about
the attack going on, and are 'on-path' with the attack traffic... and
you understand something about the network resources between the
client and server.

> All of this is orthogonal to DOTS.  It is potentially smart implementations
> and deployments.

it's potentially important to DOTS, operationally, but from a
standards perspective I bet it's simpler to leave that decision to the
implementors and agree that 'any message order from the client is ok,
within the specified timeout periods (which should ALSO be
configurable!)'

> DOTS must not assume QOS is present to ensure message flow on a congested
> path.  I believe this is already in the req ID.

agreed. no one should assume that QOS (of PACKETS) is going to work
outside their network boundary, unless they have contracted with their
carriers to support marking of PACKETS.

-chris

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 12 Nov 2015 20:57:19 +0700

> about 'qos' inside the stream of data between client/server.

Yes, it turns out to've been about DOTS message prioritization, *not* QoS.

-----------------------------------
Roland Dobbins <[email-masked]>