解决什么问题
Qbv 的 GCL 看起来是输出：哪个时间开哪个 gate。但真正困难的部分在输入。如果 flow set 没有说清楚，排出来的表就没有可信基础。
一条流的平均带宽不够。你必须知道它什么时候发、每次最大多大、多久必须到、走哪条路径、进入哪个队列、是否有冗余副本。
背景与直觉
排火车时不能只知道“今天大概有 1000 名乘客”。你需要列车班次、长度、出发站、到达站、到站时间限制和轨道。Qbv 的 flow set 也是这种输入。
怎么解决
一个基础 flow set 可以包含这些字段。
| 字段 | 作用 | 缺失风险 |
|---|---|---|
| talker/listener | 定义通信端点 | 不知道保护对象 |
| period | 决定周期和重复频率 | cycle 难以选择 |
| max frame size | 决定发送时间 | 窗口宽度错误 |
| deadline | 定义边界 | 无法判断是否成功 |
| route | 决定每跳窗口 | 只验证局部 |
| traffic class | 决定 gate 控制对象 | 进入错误队列 |
| sync/error budget | 决定余量 | 纸面窗口过窄 |
Qcc 的 stream contract 和 Qbv 的 flow set 之间有强关联：前者从配置视角描述流，后者从排表视角使用这些字段。
带来了什么新问题
流量模型常常和真实业务不完全一致。应用升级后帧长变大，采样周期变化，路径改了，背景流量增加，原来的 GCL 就可能不再可靠。
因此，flow set 应该进入版本管理和验证报告。没有输入版本，就无法解释调度结果为什么成立或为什么失效。
检查点
- 一条 Qbv 关键流如果只给平均带宽，不给最大帧长和周期，排表会缺少哪些信息？
- 为什么 route 不是 GCL 之后的附属信息，而是排表前的核心输入？