Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

On February 20, 2019 at 4:11:45 PM, Lou Berger ([e-mail]) wrote:

Hi Alissa,

…Alvaro… :-)

Hi!


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

I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns
about the coexistence with non-DetNet traffic and privacy:

§3.3.1 talks about what I think is a hard to achieve balance between coexisting
with non-DetNet traffic and keeping that traffic from disrupting DetNet flows.
Because of the constraints, the intent of prioritizing DetNet flows is clear
(and that is ok), but that may result in starvation of non-DetNet
traffic...even if the text does explicitly say that it "must be avoided".

I would like to see the potential case of starving non-DetNet traffic called
out somewhere.

This is the objective of section 3.3.1.


I'm looking for something similar to the first paragraph in §5,
but focused on the non-DetNet traffic.

The current text reads:

3.3.1.  Coexistence with normal traffic

   A DetNet network supports the dedication of a high proportion of the
   network bandwidth to DetNet flows.  But, no matter how much is
   dedicated for DetNet flows, it is a goal of DetNet to coexist with
   existing Class of Service schemes (e.g., DiffServ).  It is also
   important that non-DetNet traffic not disrupt the DetNet flow, of
   course (see Section 3.3.2 and Section 5).  For these reasons:

   o  Bandwidth (transmission opportunities) not utilized by a DetNet
      flow is available to non-DetNet packets (though not to other
      DetNet flows).

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.

   o  When transmission opportunities for DetNet flows are scheduled in
      detail, then the algorithm constructing the schedule should leave
      sufficient opportunities for non-DetNet packets to satisfy the
      needs of the users of the network.  Detailed scheduling can also
      permit the time-shared use of buffer resources by different DetNet
      flows.

   Starvation of non-DetNet traffic must be avoided, e.g., by traffic
   policing functions (e.g., [RFC2475]).  Thus, the net effect of the
   presence of DetNet flows in a network on the non-DetNet flows is
   primarily a reduction in the available bandwidth.


I think we need a little bit more to understand what you'd like to see
changed or added.  Can you suggest text or what specific topic you'd
like to see added/addressed?

Yes, let me try to explain better…while comparing with the current text in
§5, which basically says that even though the objective of DetNet is to
provide bounded latency, a MIIM may delay the traffic and the objective may
not be achieved.

For non-DetNet traffic, the objective is to not starve it, while providing
specific guarantees to the DetNet flows — said other way (from the
Introduction): "Unused reserved resources are available to non-DetNet
packets as long as all guarantees are fulfilled.”  However, the algorithms
(maybe error, misconfiguration…or even maliciously) may end up*not*
constructing the schedule to leave sufficient opportunities for non-DetNet
packets (as suggested in the text above from §3.3.1).

I see a parallel in how there is a risk of the intention for DetNet flows
not being met (because of an attack) and how the intention for non-DetNet
traffic may also not be met.


Related to the above is the fact that the identification of flows could be used
to specifically *not* include some of them as DetNet flows.  This is a
variation of the concern outlined in §6, but applied to non-DetNet flows, with
the potential starvation mentioned above.  Again, I would like to at least see
some discussion of this risk.

I don't follow - what is the risk that should be addressed?

§6 talks about potential privacy concerns due to the identification of
flows.  I interpret that as potentially being able to identify the user
(application, or both maybe).

As far as I understand the architecture, DetNet flows are identified at the
edge and then assigned to specific paths.  If the identification of flows
can be used to identify the user (for example), then it can be used to not
only attack specific DetNet flow, but also to decide to not provide
guarantees to a specific flow based on who the user or the application may
be.

I’m trying to point at a scenario where the identification may lead to flag
a flow as non-DetNet — and then (back to the initial point) potentially
starve it: eliminating the ability of that user to communicate.

The use case and problem statement documents outline specific applications that
may not have non-DetNet traffic, and the Introduction supports that.  However,
the architecture described in this document may be used in more general
networks to provide guarantees to specific traffic...  IOW, even if the
intention is there, there is no guarantee that DetNet will only be used in the
expected use cases.

You're not requesting any change in the document here, right?

Right.  Just pointing out that not all deployments of DetNet may be in the
expected use cases, potentially exposing them to other risks, or other
applications.


Hope this makes more sense.

Thanks!

Alvaro.