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

[Lou Berger <[e-mail]>]

Hi Alissa,

Thanks for the comments - see below.

On 2/20/2019 10:56 AM, Alvaro Retana wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-detnet-architecture-11: 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-detnet-architecture/
>
>
>
> ----------------------------------------------------------------------
> 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?


> 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?


> 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?

Thanks,

Lou

(as doc shepherd)