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

[Peng Liu | 刘鹏 <[e-mail]>]

Hi Shaofu,




I think there should be some limitation to the ingress traffic, it is unrealistic to expect the network to handle all levels of burst. DetNet's traffic should be predictable in most cases, while for large-scale networks, the unpredictability will be a little more within tolerance, but not unlimited. 




If the end-system generates burst traffic, either it need to apply for more resources in advance, or need to accept some delayed transmission, which is not necessarily the responsibility of the network.




We don't have to expect a single method could solve all the problems, a variety of methods refers to edge nodes, transit nodes and controller need to be combined to ensure delay or jitter in different scenarios. 




Regards,

Peng





 



发件人: peng.shaofu

时间: 2021/11/12(星期五)17:04

收件人: tte;

抄送人: draft-eckert-detnet-mpls-tc-tcqf;detnet;

主题: Re: [Detnet]  questions_about_ draft-eckert-detnet-mpls-tc-tcqfHi Toerless,

Thanks for clarifications. Please see inline.
(Sorry that I can only send messages in plain text)

Regards,
PSF


------------------原始邮件------------------
发件人：ToerlessEckert
收件人：彭少富10053815;
抄送人：[e-mail];[e-mail];
日 期 ：2021年11月12日 00:24
主 题 ：Re: questions about  draft-eckert-detnet-mpls-tc-tcqf
Hi Shaofu,
Thanks for asking, and sorry for the answer to being so long, but i did
ponder about those questions quite a bit already.

[PSF] Thanks, it is helps me.
On Thu, Nov 11, 2021 at 03:00:10PM +0800, [e-mail] wrote:
> Hi authors,
>
> Thanks for the effort to introduce TSN CQF to IP network, especially, a large scale WAN.
Thanks. Hope the answers  below will be satisfactory to support the draft.

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

For use with DetNet, and as the really as the initial production deployment
goal, this is exactly how it would work. And this is exactly how CQF in TSN
is also used, so there is nothing new in principle.
Wrt to scalability, i think there are well known options from TSN and new
ones from wide-area/high-speed networking:
- you need to admit for every flow a maximum number of bits into a cycle.
Important business cases like telemtry (traffic management in cities)
or financial stock ticker (market data telemetry ;-) have small packets.
This allows more flows.
- Typical TSN networks use 1 Gbps links. Typical Service Provider Networks
will use 1 Tbps in a few years. That is a factor 1000 number of bits/cycle
and therefore number of flows.
- The cycle time can be configured larger or smaller. The larger, the more bits
will fit. The larger the physical propagation latency of paths is, the larger
you may be willing to make cycle time.
- The admission controller may not admit every flow into every cycle, but
manage bandwidth in terms of a sequence of cycles. This is also done
by TSN controllers. This can increase the number of bursty flows that can
be admitted sinificantly.

[PSF] Agree with all the above points. However, there is a assumption here, that the cumulative sum of the bits inserted by multiple source nodes in a single cycle will not exceed the maximum number of bits that can be inserted in a single cycle on the intermediate node. With the increasing number of source nodes connecting deterministic end-systems, or the number of bits that some source nodes need to insert in a single cycle bursts (because the end-system generates burst traffic), this assumption will be frequently violated. At this time, if the admission control limits that some source nodes delay sending traffic, I am not sure whether the delay jitter caused by such delay will affect the operation of the service.


> 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.
Explanations like those bove do IMHO not belong into a normative forwarding
spec, which draft-eckert-detnet-mpls-tc-tcqf intends to be. Instead
they belong into an informatinal "architecture" document.
As i think i said during our IETF112 WG meeting: If the working group
adopts draft-eckert-detnet-mpls-tc-tcqf, and is interested to see
all the collateral controller-plane aspects be document (such as
the explanations above), then i would be happy to see that we
adopt such an architecture document. For example, our two pre-existing
draft could be good starting points:
draft-dang-queuing-with-multiple-cyclic-buffers [1]
draft-qiang-detnet-large-scale-detnet [2]
When we wrote [1], we ONLY targeted it for DetNet, and did not ever consider
a case where we would have congestion, because we thought that would not
be in scope of DetNet.
When we where then sent around various WGs,  the colleagues who wrote [2]
actually did consider use within and outside of DetNet, aka: congestion
could be an option. The text does not say much about it though.

[PSF] The order should be a mature architecture firstly, then the related control and data plane documents. Looking forward to more details for architecture. 


After my talk with Balazs yesterday, i conclde that even when we have
congestion, T-CQF would still be a DetNet solution, because it will
still guarantee a bounded latency. So this is i think an exciting
opportunity to add to the TCQF architectural document with text like the
following:
| When you use TCQF without an admission controller, congestion may happen
| and cycles may be overrun with traffic, and packets that will not fit a
| cycle have to be dropped. The packets that do not get dropped will get
| forwarded with a guaraneed bounded latency though, so this
| type of operation is still a DetNet application. For example,
| such a deployment could exclusively use TCP traffic and achieve
| bounded latency for those TCP flows. Because theree is no further
| distinction of packets, a deployment needs to have all packets
| be either admission controlled or all be congestion controlled.

[PSF] Yes, I guess there are no TCQF states per flow maintained at the transit node, thus nobody can ensure the dropped packets are always from the same unluck flow. 


I consider this congestion controlled deployment with bounded latency
a great area of research for congestion control researcher, but i
don't think that we have a well understood operational model yet.
So i might actually want to present about that option to e.g.: ICCRG,
we might even get some of those researcher then become interested in
DetNet!

[PSF] Same opinion. : )
Cheers
Toerless

_______________________________________________
detnet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet