Re: [Detnet] questions about draft-eckert-detnet-mpls-tc-tcqf

[Toerless Eckert <[e-mail]>]

Thanks Norm

I think what you are calling "bundling" is probably what we did in DetNet
so far call aggregation, and i do agree it is a very interesting function,
which i think we have not well defined at the actual forwarding/qos level.
I think it is present in some of the yang work though.

IMHO, this aggregation function should continue to be defined as much
as possibly independent of the QoS that is then used for the aggregate
flow, such as T-CQF as proposed by us - or any other detnet qos for the
aggregated flow. Of course, if DetNet WG would prefer to combine
specifications of these functions, that would be fine
too, but lead to a less flexible architecture IMHO.

For the implementation of T-CQF i am aware of, aggregation (into T-CQF)
was of course also implemented at >= 100 Gbps interface speed, so i can not
agree with your concern about implementation problems. Maybe the implementation
concern background you are referring to comes from typical IEEE industrial
1gpbs (maybe 10 gbps) ethernet switches, where i can more easily imagine that flexible
buffer management may be more limited than in more general purpose
high-speed WAN routers, which are the platform we used.

So, hopefully we will not limit our decision making in DetNet to TSN
market scope products.

Also: I wonder if aggregation could not also be modelled by setting
up the typical TSN gates for multiple flows with the same timing parameters.
But i have not enough insight into the configurability of those gates.

In any case, if we look at the need for interoperability and standardization,
i think it is foremost important to be able to have on-the-wire interoperable
hop-by-hop QoS. As much as i want to have edge-aggregation standardized,
it is still a single-box function, so less critical to get standardized
for successful deployments.

Cheers
    toerless


On Wed, Nov 17, 2021 at 12:37:26PM -0800, Norman Finn Consulting wrote:
> A follow-on.
> 
> CQF is under consideration for improvement for use in TSN, where network sizes are relatively small.  My paper, referenced by Janos, does not address the issue of bundling many flows into a single flow, then merging or splitting them arbitrarily.  Without bundling, TSN CQF has scaling issues; a large number of flows requires large buffers, which increase the per-hop delays.  But, bundling is not a trivial operation.  Bundling may require buffers and state machines, itself, and may therefore reduce the no-touch advantage of CQF.  My next step for the CQF proposals in TSN will be to address this issue.  I imagine that Janos will keep you informed if progress is made.
> 
> -- Norm
> 
> > On Nov 15, 2021, at 22:56, Norman Finn <[e-mail]> wrote:
> > 
> > You’ve got it.  Admission control is the key. Either through a reservation protocol or a central supervisor, you have to ensure that no output interface is given more load than can be handled in a single transmission period. No sender can proceed without permission.
> > 
> > Reservation-before-transmission is required by all TSN techniques. You can't guarantee zero congestion loss to an arbitrarily large load. The nice thing about CQF is that, with centralized control, you don't have to touch any intermediate nodes to admit or delete a flow; only contract enforcement at the ingress node has to be configured.
> > 
> > — Norm
> > 
> >> On Nov 10, 2021, at 23:00, [e-mail] wrote:
> >> 
> >> Hi authors,
> >> 
> >> Thanks for the effort to introduce TSN CQF to IP network, especially, a large scale WAN.
> >> 
> >> Can you help me to understand how does T-CQF solve the congestion ?  For example, an intermediate node with multiple incoming ports may receive T-CQF packets from many sources, and  these packets are put into the same cycle-id related queue. Can they be guaranteed to be sent together in the next cycle?  Appreciate for additional description of that in the document.
> >> 
> >> I have seen examples of single T-CQF flow competed with best-effor backgroup flows, that is OK. However, the competetion between multiple T-CQF flows may be more interesting.
> >> One may say that there is a central controller to plan and arrange T-CQF flows, and never permit more T-CQF flows match the same local cycle-id at the intermediate node then to avoid congestion. I think that may be possible for a small network, but may be challange for large scale WAN.
> >> 
> >> Regards,
> >> PSF
> >> 
> >> _______________________________________________
> >> detnet mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/detnet

-- 
---
[e-mail]