[{"author": "Brian Trammell", "text": "

sorry, did i steal everyone's question? :)

", "time": "2023-03-29T06:50:16Z"}, {"author": "George Michaelson", "text": "

why not administravely re-define the anti-amp goal to 6x from 3x and declare success?

", "time": "2023-03-29T06:50:44Z"}, {"author": "Rich Salz", "text": "

Seems to be the consensus, maybe 4 or 6. (Why does that sound familiar?)

", "time": "2023-03-29T06:52:37Z"}, {"author": "Brian Trammell", "text": "

heh. this time, let's do five, just to be different :)

", "time": "2023-03-29T06:53:11Z"}, {"author": "Michael B", "text": "

My question was going to be: Regarding the mitigation of replacing RSA with ECDSA, won't we be back to where we were (or worse) after the eventual introduction of post quantum or hybrid certificates? Due to public keys being larger.

", "time": "2023-03-29T06:53:14Z"}, {"author": "Brian Trammell", "text": "

more seriously, \"success\" in this case is slippery though. the thing I found really interesting here is that we have a very clear and nice measurement of \"implementors ignoring the RFC in a protocol they helped define because the benefits of doing so far outweigh the risk\"

", "time": "2023-03-29T06:53:39Z"}, {"author": "Matthias W\u00e4hlisch", "text": "

honestly, the smarter way is to get the configuration of certs right. unnecessarily blowing up certs is not helpful in several scenarios (e.g., think about mobiles). QUIC just nicely reveals that there is room for improvement.

", "time": "2023-03-29T06:53:40Z"}, {"author": "Brian Trammell", "text": "

+1 matthias

", "time": "2023-03-29T06:53:53Z"}, {"author": "George Michaelson", "text": "

ephemeral ECC from a TA in the browser set: 1 jump chain to edge

", "time": "2023-03-29T06:54:14Z"}, {"author": "George Michaelson", "text": "

bit of a bugger updating the TA of course.

", "time": "2023-03-29T06:54:23Z"}, {"author": "Brian Trammell", "text": "

so yeah i guess i withdraw my suggestion, to the extent the sea of orange in that graph drives (to whatever extent) (slowish) cleanup of the cert chain then cool

", "time": "2023-03-29T06:54:39Z"}, {"author": "Martin Duke", "text": "

Am I the only one who lost audio?

", "time": "2023-03-29T06:55:32Z"}, {"author": "Dave Plonka", "text": "

I have audio

", "time": "2023-03-29T06:55:40Z"}, {"author": "Marcin Nawrocki", "text": "

Michael B said:

\n
\n

My question was going to be: Regarding the mitigation of replacing RSA with ECDSA, won't we be back to where we were (or worse) after the eventual introduction of post quantum or hybrid certificates? Due to public keys being larger.

\n
\n

Yes, for hybrid methods (which use both types of secrets => more data) the situation will get even worse. I will have a short note on that tomorrow during quicwg. Thank you for pointing out that already!

", "time": "2023-03-29T06:58:10Z"}, {"author": "George Michaelson", "text": "

I;d call 50% fit comfortably inside the path lifetime \"good engineering\"

", "time": "2023-03-29T07:00:08Z"}, {"author": "George Michaelson", "text": "

I also think given the sats are up there, comparing their model to reality would make sense

", "time": "2023-03-29T07:02:11Z"}, {"author": "George Michaelson", "text": "

(for starlink at least)

", "time": "2023-03-29T07:02:18Z"}, {"author": "Geoff Huston", "text": "

I wonder if a LEO constellation would chose an exit poin t cloest\" to the client or cloests to the destination. I suspect that the former is simpler , while the latter is far more challenging

", "time": "2023-03-29T07:03:00Z"}, {"author": "George Michaelson", "text": "

if I read this slide right, the latency benefit is really marginal

", "time": "2023-03-29T07:03:02Z"}, {"author": "Gorry Fairhurst", "text": "

Is Starlink actually using ISLs at this moment.

", "time": "2023-03-29T07:03:12Z"}, {"author": "Gorry Fairhurst", "text": "

The Latency isn't the big issue, it's connectivity to places with no ground terminal

", "time": "2023-03-29T07:03:39Z"}, {"author": "Geoff Huston", "text": "

This is all simulation according to an earlier slide

", "time": "2023-03-29T07:03:40Z"}, {"author": "George Michaelson", "text": "

the spatial structure is going to be orbital mechanics surely

", "time": "2023-03-29T07:04:16Z"}, {"author": "George Michaelson", "text": "

(and Gorry your point is well made I dont think ISLs are live yet)

", "time": "2023-03-29T07:04:39Z"}, {"author": "Geoff Huston", "text": "

so My question is what are they sumulation - I think they are simulating destination-based routing - i.e. keep the packet in space for as long as possible, but IO suspect that its simpler to drop it back to earth as soon as possible

", "time": "2023-03-29T07:04:44Z"}, {"author": "Ingemar Johansson", "text": "

Is there a paper available for the LEO stuff

", "time": "2023-03-29T07:04:50Z"}, {"author": "Gorry Fairhurst", "text": "

Yes, I see - the orbits are known

", "time": "2023-03-29T07:04:51Z"}, {"author": "Mirja K\u00fchlewind", "text": "

yes was a paper at PAM last week

", "time": "2023-03-29T07:05:20Z"}, {"author": "Michael B", "text": "

Marcin Nawrocki said:

\n
\n

Michael B said:

\n
\n

My question was going to be: Regarding the mitigation of replacing RSA with ECDSA, won't we be back to where we were (or worse) after the eventual introduction of post quantum or hybrid certificates? Due to public keys being larger.

\n
\n

Yes, for hybrid methods (which use both types of secrets => more data) the situation will get even worse. I will have a short note on that tomorrow during quicwg. Thank you for pointing out that already!

\n
\n

Thanks Marcin, looking forward to it. Excellent research & talk btw :)

", "time": "2023-03-29T07:05:48Z"}, {"author": "Joerg Ott", "text": "

Practical measurements with Starlink show RTT variation of 20..70ms, but the variation doesn't seem to haave that much of an impact at first glance

", "time": "2023-03-29T07:05:49Z"}, {"author": "Geoff Huston", "text": "

yes - they are simulating passing the packet scross the spacecraft traversing \"across\" the mesh and making assumptions about the service model as well.

", "time": "2023-03-29T07:05:56Z"}, {"author": "Gorry Fairhurst", "text": "

.. our analysis of real measurements show very wide variation in the RTT for the current service

", "time": "2023-03-29T07:06:36Z"}, {"author": "Geoff Huston", "text": "

Starlink has a signal propagation time of 5 - 10 ms to get up to 550km and back twice. The question in my head is what are the other 10ms to 15ms used for?

", "time": "2023-03-29T07:06:52Z"}, {"author": "Joerg Ott", "text": "

@Geoff: good question. The measurements were endpoint behind a starlink dish to a data center in Frankfurt where the Starlink ground station used seemed to be located. So, you would not expect much extra interference. Traceroutes didn't reveal further details.

", "time": "2023-03-29T07:10:10Z"}, {"author": "Louis Chan", "text": "

For LEO topic, are the link speeds between nodes constant or varying?

", "time": "2023-03-29T07:10:16Z"}, {"author": "Geoff Huston", "text": "

@Louis if you assume a starlink-style mesh there are two \"constant\" ISKL links to the satellite ahead and behind in the satellite chain, but the ones coming across from left to right have a closing speed of some 7km per second and are useful for around 1 - 2 seconds I guess

", "time": "2023-03-29T07:11:54Z"}, {"author": "Ahmed Saeed", "text": "

A follow up point regarding the service model, one of the findings in the paper is that the main source of variability are the links between ground stations and satellites. So even with hot potato routing, variability will still be very high. Relying on the mesh (under the strong assumptions about routing being done centrally in zero time) introduces lower variability.

", "time": "2023-03-29T07:12:15Z"}, {"author": "Louis Chan", "text": "

@Geoff Huston That is the intent of my question. If the link speed is changing, latency per link is also changing too.

", "time": "2023-03-29T07:13:57Z"}, {"author": "Ahmed Saeed", "text": "

@Louis Chan all simulations in the slides were just looking at route lengths. There are some simulations in the paper looking at the performance of congestion control algorithms under LEO variability. In those simulations, we looked at scenarios where capacity was fixed and scenarios where capacity varies.

", "time": "2023-03-29T07:14:01Z"}, {"author": "Geoff Huston", "text": "

@Ahmed - yes, but with particular reference to Starlink's curent bent pipe service they seem to add some 10ms to 30ms per RTT interval beyond the times that packet propagation would dictate. There seems to be some large buffers at play and in my measurements some of this buffer space is used to absorb some of the the impacts of the constant switching from spacecraft to spacecraft.

", "time": "2023-03-29T07:15:54Z"}, {"author": "Brian Trammell", "text": "

new paper: ftl communication using RIPE Atlas

", "time": "2023-03-29T07:16:06Z"}, {"author": "Brian Trammell", "text": "

ah. haha. :)

", "time": "2023-03-29T07:16:20Z"}, {"author": "Qi Zhang", "text": "

\u54c8\u54c8\u54c8\u54c8\u54c8

", "time": "2023-03-29T07:17:43Z"}, {"author": "Qi Zhang", "text": "

hahahaha

", "time": "2023-03-29T07:17:56Z"}, {"author": "Ahmed Saeed", "text": "

@Geoff Huston you are absolutely right, our focus was on propagation delay variability but as soon as you include queueing artifacts, the results are bound to be much worse. It's not hard to imagine 4x variability in the RTT on a congested path.

", "time": "2023-03-29T07:18:12Z"}, {"author": "Jonathan Hoyland", "text": "

France just chilling with their 12 timezones

", "time": "2023-03-29T07:18:35Z"}, {"author": "Geoff Huston", "text": "

@Ahmed Like many others I am keenly waiting the release of the Starlink V2 service and see what choices they've made in managing their inter-spacecraft links.

", "time": "2023-03-29T07:19:59Z"}, {"author": "Vaibhav Bhosale", "text": "

@Geoff - The current queueing implementation in Starlink can lead to a lot of issues. For example, one of the papers at IMC last year observed that Starlink drops packets when it switches from one satellite to another. So that in itself can bloat up latency every 2-3 minutes.
\nBut then, there's also the part about the backhaul that is being used, which is fairly opaque. So it is harder to comment on the variability they add.

", "time": "2023-03-29T07:21:31Z"}, {"author": "Joerg Ott", "text": "

Given the substantial multipath opportunities this would offer, it'd be interesting to understand the routing schemes behind (and its artifacts) how to influence path choice if at all possible

", "time": "2023-03-29T07:22:34Z"}, {"author": "Ahmed Saeed", "text": "

There are already some discussions about the impact of using ISLs on Starlink, using real data https://old.reddit.com/r/StarlinkEngineering/comments/11h9oah/why_are_intersatellite_links_so_bad/

", "time": "2023-03-29T07:24:46Z"}, {"author": "Jonathan Hoyland", "text": "

No such thing as a failed experiment, just a negative result.

", "time": "2023-03-29T07:25:05Z"}, {"author": "Dave Plonka", "text": "

Assumptions and construction of the experiment can be wrong. I guess I would call that a \"failed experiment.\" :)

", "time": "2023-03-29T07:25:50Z"}, {"author": "Ruediger Geib", "text": "

Yep, if your measurement set up starts to influence the result, the set up is bad

", "time": "2023-03-29T07:26:39Z"}, {"author": "Ahmed Saeed", "text": "

@Joerg Ott There has been some work exploring traffic engineering schemes exploring how to exploit all the available paths in satellite networks (e.g., for load balancing or improving resilience). Unfortunately, it's hard to figure out what Starlink actually does.

", "time": "2023-03-29T07:26:44Z"}, {"author": "Jonathan Hoyland", "text": "

I started my Ph.D. by trying to extend a proof to an extra case. It transpired the original proof had a mistake. Not a failed experiment, I just got an unexpected result.

", "time": "2023-03-29T07:28:20Z"}, {"author": "Brian Trammell", "text": "

...i'm not sure I believe in the existence of any measurement setup that doesn't influence the result...

", "time": "2023-03-29T07:28:21Z"}, {"author": "George Michaelson", "text": "

I think the power of differential analysis is really showing in Ana and Gorry's stuff here.

", "time": "2023-03-29T07:28:51Z"}, {"author": "Brian Trammell", "text": "

there are only measurements with known sources of influence, and those with not-yet-known sources of influence.

", "time": "2023-03-29T07:29:13Z"}, {"author": "Brian Trammell", "text": "

+1 george

", "time": "2023-03-29T07:29:16Z"}, {"author": "Reese Enghardt", "text": "

\"Don't assume you understand how the Internet works\" is a great quote for... lots of contexts

", "time": "2023-03-29T07:30:44Z"}, {"author": "Brian Trammell", "text": "

reese, that might be the only true layer-invariant statement about the internet....

", "time": "2023-03-29T07:31:44Z"}, {"author": "Jonathan Hoyland", "text": "

The more I learn about the Internet the less likely I am to make that assumption :sweat_smile:

", "time": "2023-03-29T07:31:45Z"}, {"author": "Ruediger Geib", "text": "

I still prefer to design my experiments in a way that the set up doesn't create \"noise\" dominating the parameters, my measurement is supposed to correlate with.

", "time": "2023-03-29T07:32:56Z"}, {"author": "Brian Trammell", "text": "

the byte offset thing is... hilarious

", "time": "2023-03-29T07:33:03Z"}, {"author": "Brian Trammell", "text": "

clap clap clap clap

", "time": "2023-03-29T07:33:13Z"}, {"author": "Ana Custura", "text": "

@Brian Trammell it's unfortunately more common than you think

", "time": "2023-03-29T07:35:24Z"}, {"author": "Ana Custura", "text": "

saw this on maybe 30% of the paths we measured

", "time": "2023-03-29T07:36:15Z"}, {"author": "Brian Trammell", "text": "

i mean it makes perfect sense, \"a packet is a byte array\" is a common abstraction violation

", "time": "2023-03-29T07:36:51Z"}, {"author": "Robert Kisteleki", "text": "

wait, it isn't?

", "time": "2023-03-29T07:37:34Z"}, {"author": "Anna Brunstrom", "text": "

If you are interested in the papers for the talks from PAM, papers are freely available from the PAM program page https://pam2023.networks.imdea.org/program/ for the next three weeks or so. There you can also find recorded talks for all the papers.

", "time": "2023-03-29T07:44:05Z"}, {"author": "Marcus Ihlar", "text": "

Would be interesting to compare the overhead of this method with monitoring of the QUIC spin bit.

", "time": "2023-03-29T07:44:41Z"}, {"author": "Anna Brunstrom", "text": "

On the future work list :)

", "time": "2023-03-29T07:45:27Z"}, {"author": "Brian Trammell", "text": "

+1 marcus

", "time": "2023-03-29T07:45:28Z"}, {"author": "Brian Trammell", "text": "

yay

", "time": "2023-03-29T07:45:34Z"}, {"author": "Brian Trammell", "text": "

clap clap clap clap

", "time": "2023-03-29T07:45:41Z"}, {"author": "Justin Iurman", "text": "

Missed the first slides so don't know if it was mentioned or not but... is it using tc/ebpf or xdp?

", "time": "2023-03-29T07:45:41Z"}, {"author": "David Alfonso Guzman Cabascango", "text": "

or native xdp?

", "time": "2023-03-29T07:46:12Z"}, {"author": "Simon Sundberg", "text": "

It was not mentioned in the presentation. But for egress we're using tc-BPF and for ingress we can either use tc or XDP

", "time": "2023-03-29T07:47:21Z"}, {"author": "Simon Sundberg", "text": "

In our evaluation we used XDP (driver supported, not generic) for ingress

", "time": "2023-03-29T07:47:45Z"}, {"author": "Chris Box", "text": "

I'm getting used to hearing how eBPF radically improves the performance of packet handling in different applications. Quite something.

", "time": "2023-03-29T07:47:57Z"}, {"author": "Masaki Matsushita", "text": "

What is the motivation to improve performance as a middlebox instead of receiving mirrored traffic in another box?

", "time": "2023-03-29T07:47:59Z"}, {"author": "Simon Sundberg", "text": "

If you have the capability to set up a separate box and mirror all traffic there that's of course ideal, but not everyone have those resources. And on that separate box you will either need to still keep up with the traffic, or be able to store a lot of traffic for later offline analysis

", "time": "2023-03-29T07:51:50Z"}, {"author": "Shivan Sahib", "text": "

are the Apple folks okay with Private Relay being called a VPN

", "time": "2023-03-29T07:53:49Z"}, {"author": "Andrew Campling", "text": "

@Chairs: Given time limitations, it would be better if Martino got to the measurement element rather than explaining Private Relay, Oblivious to this audience!

", "time": "2023-03-29T07:53:51Z"}, {"author": "Simon Sundberg", "text": "

While it's not something we've worked on, having access to real-time latency measurements might also be useful for the middlebox operation, ex. making routing decisions based on observed latency

", "time": "2023-03-29T07:53:53Z"}, {"author": "Andrew Campling", "text": "

How do these results to the performance testing recently undertaken by Comcast?

", "time": "2023-03-29T07:59:37Z"}, {"author": "Chris Box", "text": "

Significant variation by location. It would have been good to use far more than these three locations.

", "time": "2023-03-29T08:00:05Z"}, {"author": "Andrew Campling", "text": "

@Chris Agreed, also use locations without such tight upload limits (Hawaii)

", "time": "2023-03-29T08:02:35Z"}, {"author": "Brian Trammell", "text": "

clap clap clap clap that was an admirable speedrun

", "time": "2023-03-29T08:06:38Z"}, {"author": "Chris Box", "text": "

As Ana said, measurement is hard. Loved the last presentation too.

", "time": "2023-03-29T08:06:54Z"}]