Subject: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Mon, 13 May 2019 06:41:14 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-6lo-deadline-time-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The security consideration section have significant short comings as this
mechanism enables multiple ways to attack both the packet and the system to my
understanding. I would appreaciate your clarifications on these matters.

First of all by changing the dead-line so that it gets dropped because it is
already late, alternatively move the deadline time out further in time (later),
so that the forwarders may deliver it so late that the receiver considers it to
late.

Secondly, there is the question if extensive use of this header will cause
overload or affect the scheduling of packet transmission affect other traffic
negatively. There appear to exist potential for new ways of bad interflow
interactions here.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Looking at this mechanism it appears to me as something that should fit into a
frame work, but that is not explicitly given. The main reason I am raising that
is that it appears to not care about a number of interesting and challenging
questions for a mechanism like this. Questions that a particular framework can
take care of, or which any user of this mechanism would need to consider in
their deployment before they can determine if they can safely deploy it. It
might be that some of the questions have answers and I missed. In that case
please straighten me out. And if you have some additional document that
provides more detailed usage which discuss any of these issues I would
appreciate a pointer.

So quesitons that I got when reading this specification:

1. Are there any mechanism to provide feedback if the packets reach the
receiver in time? If the sender sets the deadline shorter than the minimal
one-way path delay, then all packets will be late. Will any feedback be
provided that this is happening? In cases D=1 this appear to be a recipe for a
black hole for the traffic. One can also end up in situation where a large
fraction of the packet are late.

2. Any mechanism that exist to determine what the expected latency are from
sender to receiver?

3. Are there any type of admittance or policy approval to use this mechanism?

4. What is the relationship between traffic with a dead-line and other traffic
without a dead-line. Are traffic with a dead-line implicitly allowed to
pre-empt other traffic or at least to delay it in its queue?

5. As Barry noted, what are the protection against missuse?

These are issue that a framework or architecture would consider, I note that
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ include some
discussion of these topics. Still DETNET architecture appear more constrained
when it comes to usage than what this mechanism through its examples.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 30 May 2019 14:15:50 -0700

> draft-ietf-6lo-deadline-time-04: Discuss

Agreed that this vulnerability should be mentioned in the Security 
Considerations.

> negatively. There appear to exist potential for new ways of bad interflow

If other packet transmissions have to be pre-empted in order for the 
deadline to be met for a particular packet, then indeed this could 
affect other traffic.  It is also a matter of possible interest what 
might happen if there were two packets in the transmission queue with 
the same or different deadlines.  However, the processing in these cases 
is a local matter at each intermediate point, and out of scope for this 
draft.   Does this also belong to be mentioned in the Security 
Considerations?

This mechanism is a simple kind of signaling that could fit into various 
frameworks, and exploring that space would be pretty interesting.  But 
it would represent a huge digression away from the point of this draft, 
which all along was intended to offer a simple mechanisms without 
getting involved with messy issues of policy.  If there is something 
missing in the basic mechanism, then that should be fixed.  But I don't 
see what is missing.  Some of the discussion below is also relevant to 
this point.

> fraction of the packet are late.

This kind of signaling is far more appropriate at the application 
level.  To fully characterize the expected distribution of latency 
values is out of scope for the draft, and the information needed would 
usually depend on the application.  Some applications don't care much 
for dropped packets but don't want to handle packets coming in too 
late.  For other applications, knowing the distribution would allow for 
setting a deadline that would usually all reception of 85% of the 
packets (or some percentage predetermined by the application).  It's 
hard for me to see that as in scope for our draft.

> 2. Any mechanism that exist to determine what the expected latency are from

As above, I think this is most properly handled by the application.

> 3. Are there any type of admittance or policy approval to use this mechanism?

The policy details are out of scope for this draft.  However, it might 
be worthwhile to mention that (similar to many QoS efforts) care must be 
taken to avoid abuse.

> pre-empt other traffic or at least to delay it in its queue?

We don't specify that, and since it's a local matter at each node, a 
mandate would be unenforceable.  However, if it is important, we could 
design an advisory extension to the draft for this purpose.  The problem 
is that the application should not necessarily need to be involved with 
changing its behavior in response to (highly dynamic) traffic conditions.

> when it comes to usage than what this mechanism through its examples.

I think it would be best to enlarge the discussion in the draft to 
explain about the potential for abuse.  I don't see just how the simple 
mechanism at the level of 6LoRH should be charged with the 
responsibility for an entire framework, and I really hope that simple 
mechanisms such as this one can be found to have value even without 
specification of a much larger set of protections and repairs.

Regards,
Charlie P.