IntenseWebs/LibreQoS
3
0
Fork 0
mirror of https://github.com/LibreQoE/LibreQoS.git synced 2025-02-25 18:55:32 -06:00
Code Issues Packages Projects Releases Wiki Activity

More notes about RTT monitoring

Browse Source
This commit is contained in:
Dave Täht 2022-12-10 21:19:55 -08:00
parent a6ab2a7ecf
commit b1b6605b37
1 changed files with 22 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
sim/README.org
View File

@ -88,8 +88,30 @@ Similarly, many devices are themselves the bottleneck, still, so they
accumulate a ton of RTT themselves, and monitoring the RTT and doing accumulate a ton of RTT themselves, and monitoring the RTT and doing
something about it would possibly help. something about it would possibly help.
Validating the the RTT metrics reported by pping line up with the
actual measurements from actual flows is important. Also, what are
the effects of ack-filtering on pping?
** FQ ** FQ
The FQ methods we use are really good for most traffic types, and
could be even better if more applications did single packet pacing and
were more sensitive to delay and jitter.
** Encapsulations ** Encapsulations
We have no insight into QUIC or VPN traffic. This is going to get
worse over time. The only thing we have for quic is the: [[https://www.ietfjournal.org/enabling-internet-measurement-with-the-quic-spin-bit/][spin bit]] -
which is probably [[https://http3-explained.haxx.se/en/quic/quic-spinbit][not widely implemented]]. The best insight we actually
have is queue accomulation and packet drop/mark behaviors.
** HTB is bursty ** HTB is bursty
** DSCP
What DSCPs are in common use today?
** DROP_MONITOR
We have 2600 (not kidding, 2600) places where packet