[{"author": "Shane Kerr", "text": "

I can't even imagine how a proof-of-non-transit would work without quantum networking.

", "time": "2024-11-07T15:42:20Z"}, {"author": "Jen Linkova", "text": "

In a quantum world packet can be transited and not transited at the same time, but by measuring it you might change the packet state...

", "time": "2024-11-07T15:44:07Z"}, {"author": "David Oran", "text": "

you may be able to prove that a packet did not visit a particular forwarder, but sure agree that protection from arbitrary eavesdroppers requires quantum techniques

", "time": "2024-11-07T15:44:41Z"}, {"author": "John Scudder", "text": "

Yeah there\u2019s \u201cproof\u201d and there\u2019s Proof.

", "time": "2024-11-07T15:47:51Z"}, {"author": "Spencer Dawkins", "text": "

@Brian - wow, that was REALLY well done!

", "time": "2024-11-07T15:50:38Z"}, {"author": "David Oran", "text": "

further question: who is the \"you\" in the auditing formulation? The source, the destination, or an arbitrary third party?

", "time": "2024-11-07T15:51:10Z"}, {"author": "Brian Trammell", "text": "

i mean i saw an opportunity to fix some confusion so i decided I'd try to take it :D

", "time": "2024-11-07T15:51:41Z"}, {"author": "Tilmann Z\u00e4schke", "text": "

The header starts with a verison field: https://docs.scion.org/en/latest/protocols/scion-header.html

", "time": "2024-11-07T16:13:00Z"}, {"author": "Luigi Iannone", "text": "

Thanks Tilmann

", "time": "2024-11-07T16:15:47Z"}, {"author": "Shane Kerr", "text": "

\"We probably encountered almost every corner case\" ....

\n

PRESS X TO DOUBT

", "time": "2024-11-07T16:23:02Z"}, {"author": "John Scudder", "text": "

\u201cHold my beer\u201d

", "time": "2024-11-07T16:23:20Z"}, {"author": "Frode Kileng", "text": "

there's been a sharp decline of PEPs in mobile networks in the last years. BBR is a cause for this.

", "time": "2024-11-07T16:36:46Z"}, {"author": "Frode Kileng", "text": "

(When AWS switched to BBR 2-3 years ago, throughput of moblle networks with PEPs either declined or a steady trend, while those without had a significant increase in throughput. I.e. as measured bye 3rd party benchmarks, e.g. Tutela)

", "time": "2024-11-07T16:39:00Z"}, {"author": "Frode Kileng", "text": "

Newer generations of PEPs also learned to stay away if they didn't understand options or would have negative effect. I.e. the ossification stories doesn't necessarily apply today

", "time": "2024-11-07T16:41:47Z"}, {"author": "Michael Welzl", "text": "

That doesn't mean that we shouldn't implement new and good ones!

", "time": "2024-11-07T16:47:13Z"}, {"author": "Shane Kerr", "text": "

So this is all about acking packets on behalf of the end application?

", "time": "2024-11-07T16:49:55Z"}, {"author": "Michael Welzl", "text": "

It's about doing things that PEPs tried to do, but in better ways - and these things generally need ACKs.

", "time": "2024-11-07T16:50:30Z"}, {"author": "Frode Kileng", "text": "

@michel: Not at all. I just addressed some statements on the slides that doesn't necessarily reflects the current situation

", "time": "2024-11-07T16:50:50Z"}, {"author": "Michael Welzl", "text": "

BTW this is the paper that this presentation is about: https://www.usenix.org/conference/nsdi24/presentation/yuan

", "time": "2024-11-07T16:50:57Z"}, {"author": "Spencer Dawkins", "text": "

The last time I looked, GSMA was telling the IETF that they couldn't remove PEPs from a particular path because they weren't sure where they were, and what all the paths that might go through them were.

\n

If the PEPs have learned to bail out of traffic when they don't think they can help, that's good for end users but probably not good for operators who are still trying to find all the PEPs and all the paths that fo through them!

", "time": "2024-11-07T16:52:33Z"}, {"author": "Spencer Dawkins", "text": "

That was 2018, but https://datatracker.ietf.org/doc/html/rfc8462 ...

", "time": "2024-11-07T16:53:24Z"}, {"author": "Michael Welzl", "text": "

Spencer Dawkins said:

\n
\n

The last time I looked, GSMA was telling the IETF that they couldn't remove PEPs from a particular path because they weren't sure where they were, and what all the paths that might go through them were.

\n

If the PEPs have learned to bail out of traffic when they don't think they can help, that's good for end users but probably not good for operators who are still trying to find all the PEPs and all the paths that fo through them!

\n
\n

So this is about operators installing a device and then later not finding it anymore? :rolling_on_the_floor_laughing:

", "time": "2024-11-07T16:54:10Z"}, {"author": "Spencer Dawkins", "text": "

Boy, \"TCPcrypt\" on this slide is the highest form of irony ...

", "time": "2024-11-07T16:54:25Z"}, {"author": "Tim Chown", "text": "

line is closed, but what transport is being used to send the 'hint' back?

", "time": "2024-11-07T16:56:02Z"}, {"author": "Spencer Dawkins", "text": "

Michael - not quite - they know where they are, but they weren't sure how many PEPs might be on all the possible paths between two endpoints, so they could turn them off and do A/B testing :grinning:

", "time": "2024-11-07T16:56:43Z"}]