# RPM Community Meeting Notes

## May 22, 2024

### Notes

Matt M. is looking for a place to host a set of drafts where he can tell the story of some changes to internet protocols that could potentially make big improvements.

Seems like scalable congestion control is necessary but not sufficient for L4S.

Is there a way that we "cross the streams" and collapse some of the layers so that there is more complete knowledge to help end systems make better scheduling decisions.

Morten recalls some research on this ... within the DC. Can he follow up?

Sebastian thinks that there is a draft where that information is available in VLAN tags ... called CSIG (aka Poseidon).

## April 17, 2024

### Agenda

- User education re: latency and its importance to the experience of network applications.

## April 10, 2024

### Agenda

- Outreach and advocacy including Jeff Greely support
- iperf 2 basic uses cases

## February 21, 2024

### Agenda

None

### Notes

Interesting discussion about HOL blocking. Stuart relayed the HOL is not really a problem (in real situations). He and Jana did studies on it (with went into the development of the Minion protocol).

Bob was attempting to debug some packet dumps. He tuned his TCP protocol settings aggressively.

## February 7, 2024

### Agenda

None

### Notes

Got an update from the WGLC for QoO from Bjorn!

We got to a question about physical cabling and what we can do with it!

QoO:

Bjorn is giving us the rundown and sales pitch.

It is a means of an application saying, "Here is the throughput and the latency that I need to operate". Then, based on *actual* measurements, it is possible for the network to say whether the application should work.

Each of the requirements is given as a range ... as long as the measurements are within the range defined by the application, then it will work okay.

Link to Bjorn's description from the previous IETF: [link](https://youtu.be/ly7wkVQePjg?si=xu-AqZkiL81Hk2Dq&t=3314)

## January 31, 2024

### Agenda

_Please add items as you see fit!_

### Notes

Going back to the "network-sized-for-Mother's-Day" topic:

There is an open question about the number of different classification levels. Is 2 enough?

Are people really doing per-flow queuing on the backbone routers?

What is the difference between queue delay and propogation delay? Is there a meaningful difference?

Morten reported that there are unloaded latency spikes that correlate to peak usage on intercontinental links. He seems to think that these switches are the bottleneck link at certain points in the day. But, the question is: Don't intercontinental links have infinite bandwidth? How can that ever be the bottleneck?

As the amount of bandwidth increases, people seem to want to add additional throughput to make the queues go away. And yet, we just keep sending more packets than there is capacity.

There will always be applications that are going to expand to use the available capacity. It's almost necessary because leaving the provisioned capacity "dark" is uneconomic.

What is different about packet-switched networking than telephones is that the application can be adaptive to the available bandwidth. The telephone system can give you a certain *thing* and, if it cannot do that, it gives you nothing. With the internet, we can scale to the available amount of capacity.

## January 24, 2024

### Agenda

1. (continue from two weeks ago) Discussion re: NQB

### Notes

1. Introduction from Morten Brorup. We are glad to have him here and he gave us a quick introduction about his work at [SmartShare systems](https://www.smartsharesystems.com/).

2. Bob gives context about why things are "harder" on wifi. Sebastian asked about how we are able to explore "higher" and learn an upper limit on the availability of bandwidth.

3. One of the hard things is to determine where the target of the test is to make sure that test results are reasonable.

4. Designing for peak or for average. How do you provision capacity?

5. Is it easier to provision capacity in the backbone than in the end point?

6. Bjorn is going to help write a blog post about the IETF's work on latency. He will share a link to the WIP in the slack channel. Here is a [link](https://docs.google.com/document/d/1VhP0oTR7Q_MURMSo_3XT03pmsFTr1Tl2Q-JCTV6K7UY/edit#heading=h.7po69p7up69j) to the document if you would like to contribute.

7. We are going to work on building a "Wording" _best practices_ document: [Starting here](https://github.com/network-quality/community/wiki/Getting-People-to-Care)

## January 17, 2024

### Agenda

1. (continue from last week) Discussion re: NQB

### Notes

Those driving last week's discussion re: NQB were not present at this meeting so we postponed that discussion until next meeting.

We discussed the possibility of adding a generic "metadata" field in the json "config" for a RPM test. The metadata field could contain details about the server hosting the RPM test such as abuse contact information, description of the server's network connection, etc.

Whether it is possible to add to the spec during WGLC is an open question. Any proposed addition to the spec would be very generic to accommodate a wide range of informational fields.

**Action**: Will to send email to investigate whether such an addition to the spec at this point in time is possible.

## January 10, 2024

### Agenda

Implementing Responsiveness at (nee) SamKnows.

### Notes

#### Ben Reports on RPM On "Weak" Devices
Sam Knows background by Ben
Part of Cisco, provide ISP measurements
Have an agent runs on WiFi routers
Has latency capabilities & new tests
Data stays in the kernel, CPUs are underpowered for these tests, no TLS
Use TCP stack RTT estimate
Sending out asks to IPPM, asking about process
Overheads TLS & http2 omit options for CPU workarounds
IETF process - send comments in email to get them on the record and transparent to all, these RFC authors are using git hub (not a mandate for all IETF RFCs)
Fair amount of interest from wired ISPs deploying low latency DOCSIS, concerned about WiFi extenders. Sam Knows doesn't control kernel in CPE so can't affect or enable L4S dual queue or congestion control.
Stuart: There may be a way to enable L4S by using QUIC which is user/app space L4S. Apple kernel still doesn't have Prague CCA. Supports ECN and hence downstream L4S only. QUIC has CPU burden too

### General Discussion About Low-Latency DOCSIS
Using dscp markings: sender cubic will oscillate per ECN, L4S much smaller corrections.

Discussion about queue protection when devices aren't marking properly.

Sebastian: How to tell if probes and load are using the same L queue. Many times the probes may go through L queue and load through the C queue.

Stuart: DSCP schedulig priorities may work for low data rate flows (e.g. VoIP) but not so much for capacity seeking zoom flows

Will requests Stuart attend Cable Labs meeting about these issues. Stuart to respond to email from Will

RPM test is designed to protect against transports & probes (e.g. ICMP) that game the system, even if unintentionally, hence the use of TCP payloads, etc.

Sebastian: Tests should inform test info, e.g. if using TLS or not, etc.

Will/Sebastian: Should go rpm test support DSCP or IP_TOS, Sebastian thinks yes

NQB: Stuart suggests NQB (fyi: [NQB IETF](https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/)) is misguided. Sender/network contract needs to be honored or sender can be punished.

"Do not use more than your fair share of the link, or else ..." <- well, what *is* my fair share?

Stuart: What we want: An application that degrades nicely when it cannot have the rate that it wants. We do not all have "ample" bandwidth, no matter how "low" that ample bandwidth seems to be.

Bob: The variability in wifi makes it "impossible" for end systems to do capacity seeking.

QQ: What do endpoints (typically) do w.r.t. echoing back DSCP markings?

SM comment: Each side of a connection will choose its DSCP independently, and often the original DSCPs are changed along the path between endpoints. For Linux/OpenWrt/cake we came up with a partial solution, where we store the DSCP from egress packets into the connection tracking database of the firewall (used for masquerading/NAT) and restore the same DSCP for ingressing packets. This works surprisingly well but obviously only covers the home network....
ISPs, even if well intended, so far do not have a good track record of "sanitizing" DSCPs passed to user networks; e.g. ComCastt as patr of its L4S/NQB testing only recently addresses a long standing issue where considerable fractions of packets where re-marked CS1 before being forwarded to end-users... CS1 however was/is defined to label lower priority data and will be scheduled by most default APs (using WiFi WMM) as AC_BK, that is with lowest air access probablity. TI think ComCast fixed this now, but I think comcast are hardly alone in not having a fully debugged DSCP to end user passing set-up, given that they so far had little interest...

### One Way Delay & other

Bob: How can we measure OWD? Measurements need a geographical distance

SM comment: as you know with sufficiently well synchronized clocks we can, for many internet paths NTP synchronisation over the internet will likely suffice, for more local lab testing higher precision time might be required, but even there just running a local NTP/PTP timer server should be enough. I would live it if we would change the RPM draft to make sure the small file we read as latency probe contains a reasonably accurate time in UTC that gets updated at least every millisecond, that way the RPM test would be able to work with OWDs.
Geographical distance is another trickier issue, geoIP can be laughably incorrect (my home gets located in Hamburg (a different federal satate), while I live 250 Km away, the longest distance in Germany is ~850Km, so 250Km is way off) AND it is not all that relevant (only in giving a lower bound for possible distances and hence transmission delays). Conceptually I think the best one can do is to trinagulate a set of well known servers at known locations and use the RTT distributions to try to pinpoint the true location (as the intersection of "circles" around the known server location that can be served at the minimal RTT measured to the point of interest), but that will still be imprevise but should give an upper limit (which for users behing geostationary satellites will essentially be not all that helpful).