[Detnet] Mirja Kühlewind's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind 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:
----------------------------------------------------------------------

Thanks for addressing the tsv-art review comments  (and big thanks to Michael
and David!) and all the work done so far! I think the document is in good shape
and I only have one minor comment that I would like to see addressed/more
explicitly spelled out. However, this should be done quickly with potentially
2-3 small changes in the draft. See below.

Given that DetNet traffic is often assumed to be not congestion controlled, it
is important that there is also some network function that makes sure the
source traffic stays within the requested bandwidth limit in-order to protect
non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I
think it should be more clearly spelled out that this would require a rate
limiting function at each DetNet source/relay (tunnel ingress). Currently sec
3.3.2 says:

"Filters and policers should be used in a DetNet network to
   detect if DetNet packets are received on the wrong interface, or at
   the wrong time, or in too great a volume."

However, maybe this case of limiting non-congestion controlled traffic (in case
the source in not keeping to the limits on purpose/in order to cheat, because
it couldn't estimate the needed bandwidth requirement an better, or due to
timely fluctuations) could be explained more clearing and the respective
requirement to implement rate limiting could be state separately and more
strongly...?

One related comment on this sentence in Sec 3.1:

"As DetNet provides allocated resources (including provisioned capacity)
   to DetNet flows the use of transport layer congestion control
   [RFC2914] by App-flows is explicitly not required."

I guess congestion control should still be a requirement if the App-flow also
passes not-DetNet-aware segments of the path, e.g. maybe the first hop. Usually
use of congestion control for application limited flows is also not a problem
if sufficient bandwidth is available. Also note that, as I stated above, the
important part for not requiring congestion control is actually not only that
resources are allocated but also that rate limiting is in place to make sure
resources usage cannot be exceeded above the reserved allocation. Maybe this
sentence could also be further clarified in the draft...?

And then one more small comment that is also related. Sec 3.2.2.2 says:

"If packet replication and elimination is used over paths with
   resource allocation (Section 3.2.1), ..."

My assumption was that all DetNet traffic is send over pre-allocated
resources...? If that is not true that has implication on congestion control
and needs some additional considerations. Can you please confirm that and maybe
clarify in the draft! Thanks!


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

I agree with Alexey and Benjamin that this document should be informational.
Informational documents can also have IETF consensus, so that cannot be the
reason to go for PS. However, this document does not specify a protocol or any
requirements that are mandatory to implement for interoperability and therefore
should not be PS.