[vadiml]

Given the fact that the root cause of the problem with current CC algorithms is inability to discriminate between congestion and jitter provoked delays the obvious solution will be to implement some kind of method to report jitter state to the source. Maybe some kind of ICMP packet or IP option.

[foobiekr]

Someone should coin this as a law: "All problems on the internet will be solved with more bandwidth."

Everything else will turn out to be a configuration burden, control plane load problem, security issue, hard to debug (especially after the fact, impossible) and so on.

Bandwidth and NPUs with designed-in minimal latency are easy to metric, easy to measure, easy to deploy, easy to implement and so on. They have very predictable behaviors.

Reality is that we are entering a phase where networks can be vastly simplified. MPLS is going, SR is here for the time being, QoS is dying, multicast dead, SDWAN is going to be a thing for a few more years then dead, and so on.

[stingraycharles]

Isn’t this already somewhat there, the ECN bit of TCP?

[jdthedisciple]

At least in TCP can't jitter be detected and measured using ACKs?

I thought some algorithms even do that already

[toast0]

You can measure jitter, but you don't know how much of the delay was due to congestion, and how much was due to other factors.

Something mentioned elsewhere in the thread is wifi physical layers may wait to send small packets until they get a few small packets to aggregate or a timeout. Other systems that aggregate packets may do something similar.

On time division multiplexed systems, it may take measurable time to wait for an assigned slot, even if the channel isn't congested. Some packets would get lucky and have a short wait and others would have a longer wait.

This would be challenging to signal as the delay is added at a hop-by-hop level, but whether the delay is significant enough to signal is unknowable at that level. Maybe you could ask all hops to add to a field indicating milliseconds of delay (or some other fixed increments), but I don't think there's room for that in existing fields and you'd have a heck of a time getting meaningful support. ECN took how long to be usable on the internet, because some middleboxes would drop connections with it enabled, to say nothing of devices actually flagging congestion.

[signa11]

rfc-4689 (iirc) defines jitter as the fluctuation in forwarding delay between 2 consecutive received packets in a stream.

not sure how this would work for tcp-ack's which can be cumulative. moreover, any approach that does this measurement must account for both delayed and lost/corrupt packets.

imho, only a true realtime jitter measurement would do, anything else would be a crude approximation, and might result in the same flaws as before...

[edit]: examples of '...anything else...' mentioned above might be inter-arrival histogram where receiver relies on packets being transmitted at a fixed cadence, in this case lost/corrupted packets would badly skew the computed numbers. another approach might be post-processing (after packet capture) where limited buffer space might prove to be the achilles heel etc.

[vadiml]

In VOIP applications the correct jitter estimation is very important and RTP/RTCP protocols are doing it pretty well. Of course each RTP packet has a timestamp which simplifies the task

[urthor]

Not sure that will work in real world scenarios.

How would you know they're honestly reporting jitter?