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

[Alvaro Retana <[e-mail]>]

On February 21, 2019 at 7:35:32 PM, Lou Berger ([e-mail]) wrote:

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.
>
Okay, this sounds like basically the same point that Benjamin was
making, i.e., there must be mechanisms preventing non-detnet traffic
from impacting detnet traffic, and detnet traffic trying to use more
than its allocation and impacting non-detnet traffic. Is this correct or
are you asking for something different/additional?

Yes.  I’m not asking so much for a mechanism, but for at least the
recognition that it is a risk.




>
>>> 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).
>
Currently flow identification is based on IP headers (6 tuple) and/or
MPLS labels.  So DetNet has the same privacy concerns as standard IP/MPLS.


> 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.
>
Given DetNet flow identification, is this any different than standard PBR?

Right, it is not really different.  It is just not mentioned anywhere that
identification (or misidentification as it may be, maybe maliciously) can
lead to not providing guarantees, potential starving, etc..

Thanks!

Alvaro.