Re: [Bloat] Possibly interesting video on atomic clocks

2021-08-24 Thread Carsten Bormann
On 2021-08-24, at 20:00, Michael Yartys via Bloat wrote: > > https://www.youtube.com/watch?v=JK3eTGkX6qY OMG. Among other things, he says: A cheap Rubidium clock module has a deviation of less than 1 second in 100 million years (that would be 3e-16!) (1). Because it’s an atomic clock, it sur

Re: [Bloat] [Ecn-sane] sce materials from ietf

2019-11-30 Thread Carsten Bormann
On Nov 30, 2019, at 15:32, Jonathan Morton wrote: > > There are unfortunate problems with introducing new TCP options, in that some > overzealous firewalls block traffic which uses them. This would be a > deployment hazard for SCE, which merely using a spare header flag avoids. So > instead

Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint)

2019-03-17 Thread Carsten Bormann
>> The end-to-end argument applies: Ultimately, there needs to be resequencing at the end anyway, so any reordering in the network would be a performance optimization. It turns out that keeping packets lying around in some buffer somewhere in the network just to do reseque

Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint)

2019-03-17 Thread Carsten Bormann
>> The end-to-end argument applies: Ultimately, there needs to be resequencing >> at the end anyway, so any reordering in the network would be a performance >> optimization. It turns out that keeping packets lying around in some buffer >> somewhere in the network just to do resequencing before

Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint)

2019-03-17 Thread Carsten Bormann
On Mar 14, 2019, at 22:43, Sebastian Moeller wrote: > > if a specific link technology is prone to introduce reordering due to > retransmit it might as well try to clean up after itself The end-to-end argument applies: Ultimately, there needs to be resequencing at the end anyway, so any reorde