Hi Dave and list members,
It was difficult to follow the discussion at the meeting yesterday.
Who said what in the first place.
There have been a lot of non-technical comments such as: this solution
is better than another in my opinion. "better" has often been used
as when evaluating the taste of an ice cream: White chocolate vs black chocolate.
This has taken a significant amount of time at the meeting. I haven't learned
much from that kind of discussion and I do not think that helped to make
much progress.
If people can re-make their points in the list it would help the debate.
Another point that a few raised is that we have to make a decision as fast as possible.
I dismissed entirely that argument. Trading off latency with resilience of the Internet
is entirely against the design principle of the Internet architecture itself.
Risk analysis is something that we should keep in mind even when deploying any experiment
and should be a substantial part of it.
Someone claimed that on-line meeting traffic is elastic. This is not true, I tried to
clarify this. These applications (WebEx/Zoom) are low rate, a typical maximum upstream
rate is 2Mbps and is not elastic. These applications have often a stand-alone app
that is not using the browser WebRTC stack (the standalone app typically works better).
A client sends upstream one or two video qualities unless the video camera is switched off.
In presence of losses, FEC is used but it is still non elastic.
Someone claimed (at yesterday's meeting) that fairness is not an issue (who cares, I heard!)
Well, fairness can constitute a differentiation advantage between two companies that are
commercializing on-line meetings products. Unless at the IETF we accept
"law-of-the-jungle" behaviours from Internet applications developers, we should be careful
about making such claims.
Any opportunity to cheat, that brings a business advantage WILL be used.
/Luca
TL;DR
To Dave: you asked several times what Cisco does on latency reduction in
network equipment. I tend to be very shy when replying on these questions
as this is not vendor neutral. If chairs think this is not appropriate for
the list, please say it and I'll reply privately only.
What I write below can be found in Cisco products data sheets and is not
trade secret. There are very good blog posts explaining details.
Not surprisingly Cisco implements the state of the art on the topic
and it is totally feasible to do-the-right-thing in software and hardware.
Cisco implements AFD (one queue + a flow table) accompanied by a priority queue for
flows that have a certain profile in rate and size. The concept is well known and well
studied in the literature. AFD is safe and can well serve a complex traffic mix when
accompanied by a priority queue. This prio-queue should not be confused with a strict
priority queue (e.g. EF in diffserv). There are subtleties related to the DOCSIS
shared medium which would be too long to describe here.
This is available in Cisco CMTS for the DOCSIS segment. Bottleneck traffic
does not negatively impact non-bottlenecked-traffic such as an on-line meeting like
the WebEx call we had yesterday. It is safe from a network neutrality point-of-view
and no applications get hurt.
Cisco implements AFD+prio also for some DC switches such as the Nexus 9k. There
is a blog post written by Tom Edsal online that explains pretty well how that works.
This includes mechanisms such as p-fabric to approximate SRPT (shortest remaining processing time)
and minimize flow completion time for many DC workloads. The mix of the two
brings FCT minimization AND latency minimization. This is silicon and scales at any speed.
For those who are not familiar with these concepts, please search the research work of Balaji
Prabhakar and Ron Pang at Stanford.
Wi-Fi: Cisco does airtime fairness in Aironet but I think in the Meraki series too.
The concept is similar to what described above but there are several queues, one per STA.
Packets are enqueued in the access (category) queue at dequeue time from the air-time
packet scheduler.