<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://www.ispreview.co.uk/index.php/2026/06/sky-broadband-users-accidentally-blocked-from-uk-nhs-website-and-app.html"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-tcp-connection-management-on-ec2/"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/homelab/comments/1sz9li4/invisible_bend_insensitive_bidi_fiber_is_amazing/"/>
	<rdf:li rdf:resource="https://www.jeffgeerling.com/blog/2026/new-10-gbe-usb-adapters-cooler-smaller-cheaper/"/>
	<rdf:li rdf:resource="https://restofworld.org/2026/iran-blackout-tiered-internet/"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=45055604"/>
	<rdf:li rdf:resource="https://www.elastic.co/observability-labs/blog/debugging-aks-packet-loss"/>
	<rdf:li rdf:resource="https://jan.wildeboer.net/2025/04/Web-is-Broken-Botnet-Part-2/"/>
	<rdf:li rdf:resource="https://store-eu.gl-inet.com/products/flint-2-gl-mt6000-wi-fi-6-high-performance-home-router"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2025/03/aws-waf-ja4-fingerprinting-aggregation-ja3-ja4-fingerprints-rate-based-rules/"/>
	<rdf:li rdf:resource="https://mehdio.substack.com/p/duckdb-goes-distributed-deepseeks"/>
	<rdf:li rdf:resource="https://github.com/almeidapaulopt/tsdproxy"/>
	<rdf:li rdf:resource="https://www.waveform.com/tools/bufferbloat"/>
	<rdf:li rdf:resource="https://gist.github.com/jmason/aabd9d3acc86d9098654e8559e93b707"/>
	<rdf:li rdf:resource="https://ripe89.ripe.net/presentations/34-Sky-UK-MAP-T-RIPE89.pdf"/>
	<rdf:li rdf:resource="https://arstechnica.com/gadgets/2024/10/ward-christensen-bbs-inventor-and-architect-of-our-online-age-dies-at-age-78/"/>
	<rdf:li rdf:resource="https://infosec.exchange/@briankrebs/111434534909543769"/>
	<rdf:li rdf:resource="https://encore.dev/blog/retries"/>
	<rdf:li rdf:resource="https://exple.tive.org/blarg/2024/04/24/magic-numbers/"/>
	<rdf:li rdf:resource="https://torrentfreak.com/piracy-shield-cloudflare-disaster-blocks-countless-sites-fires-up-opposition-240226/"/>
	<rdf:li rdf:resource="https://github.com/louislam/uptime-kuma"/>
	<rdf:li rdf:resource="https://domagalski-j.medium.com/aws-alb-returns-503-for-istio-enabled-pods-a6942383143c"/>
	<rdf:li rdf:resource="https://smithy.io/2.0/aws/protocols/aws-json-1_0-protocol.html"/>
	<rdf:li rdf:resource="https://github.com/eldadru/ksniff"/>
	<rdf:li rdf:resource="https://karlstoney.com/2019/05/31/istio-503s-ucs-and-tcp-fun-times/"/>
	<rdf:li rdf:resource="https://www.mattb.nz/w/2023/06/02/calling-time-on-dnssec/"/>
	<rdf:li rdf:resource="https://dropbox.tech/frontend/investigating-the-impact-of-http3-on-network-latency-for-search"/>
	<rdf:li rdf:resource="https://elk.zone/mastodon.ie/@danhon@dan.mastohon.com/110209358807929291"/>
	<rdf:li rdf:resource="https://www.cablemonkey.ie/cat6a-modules-outlets/9215-cat6a-ftp-tool-less-keystone-module-5056045700332.html"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2023/02/ena-express-15-new-ec2-instances/"/>
	<rdf:li rdf:resource="https://www.airwire.ie/index.php/avail/main/"/>
	<rdf:li rdf:resource="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html"/>
	<rdf:li rdf:resource="https://nogalliance.org/our-task-forces/keep-ukraine-connected/"/>
	<rdf:li rdf:resource="https://itnext.io/what-exactly-are-vpc-endpoints-and-why-they-need-real-inter-region-support-283a9987fe51"/>
	<rdf:li rdf:resource="https://www.cablemonkey.ie/"/>
	<rdf:li rdf:resource="https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3"/>
	<rdf:li rdf:resource="https://siteviewer.comreg.ie/"/>
	<rdf:li rdf:resource="https://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html"/>
	<rdf:li rdf:resource="https://eng.snap.com/quic-at-snap"/>
	<rdf:li rdf:resource="https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/"/>
	<rdf:li rdf:resource="https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed"/>
	<rdf:li rdf:resource="https://jimmysong.io/en/blog/sidecar-injection-iptables-and-traffic-routing/"/>
	<rdf:li rdf:resource="https://berthub.eu/articles/posts/5g-elephant-in-the-room/"/>
	<rdf:li rdf:resource="https://wiki.dd-wrt.com/wiki/index.php/Parental_control"/>
	<rdf:li rdf:resource="https://www.waveform.com/tools/bufferbloat?test-id=e2656f6c-bebe-44c7-8005-c7fdfe013678"/>
	<rdf:li rdf:resource="https://nelsonslog.wordpress.com/2021/03/11/speedify-and-multipath/"/>
	<rdf:li rdf:resource="https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/"/>
	<rdf:li rdf:resource="https://www.duckware.com/tech/wifi-in-the-us.html#PHY"/>
	<rdf:li rdf:resource="https://wimoodshop.nl/"/>
	<rdf:li rdf:resource="https://arstechnica.com/gadgets/2020/02/the-ars-technica-semi-scientific-guide-to-wi-fi-access-point-placement/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/"/>
	<rdf:li rdf:resource="http://gm4fvm.blogspot.com/2018/06/power-line-adapter-noise-interference.html"/>
	<rdf:li rdf:resource="https://github.com/slackhq/nebula"/>
	<rdf:li rdf:resource="http://blog.thescorpius.com/index.php/2016/03/14/dd-wrt-network-statistics-graphics-using-grafana-and-influxdb/"/>
	<rdf:li rdf:resource="https://github.com/trevorndodds/dd-wrt-grafana"/>
	<rdf:li rdf:resource="https://rokt.com/engineering_blog/learnings-grpc-aws/"/>
	<rdf:li rdf:resource="https://medium.com/bridgefy/how-to-use-the-bridgefy-offline-messaging-app-b4799af7649b"/>
	<rdf:li rdf:resource="https://kazu-yamamoto.hatenablog.jp/entry/2019/09/20/165939"/>
	<rdf:li rdf:resource="https://www.pixelbeat.org/systems/FTTH/"/>
	<rdf:li rdf:resource="https://cloud.google.com/blog/topics/inside-google-cloud/an-update-on-sundays-service-disruption"/>
	<rdf:li rdf:resource="https://stressgrid.com/blog/pps_limits_in_ec2/"/>
	<rdf:li rdf:resource="https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44"/>
	<rdf:li rdf:resource="https://twitter.com/MarcJBrooker/status/1093650148708691969"/>
	<rdf:li rdf:resource="https://blog.benjojo.co.uk/post/eve-online-bgp-internet"/>
	<rdf:li rdf:resource="https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/programming/comments/9wncor/httpoverquic_to_be_renamed_http3/"/>
	<rdf:li rdf:resource="https://blog.hostedgraphite.com/2018/10/30/deadlines-lies-and-videotape-the-tale-of-a-grpc-bug/"/>
	<rdf:li rdf:resource="https://triplebyte.com/blog/how-triplebyte-solved-its-office-wifi-problems"/>
	<rdf:li rdf:resource="https://www.cncf.io/blog/2018/08/31/grpc-on-http-2-engineering-a-robust-high-performance-protocol/"/>
	<rdf:li rdf:resource="https://twitter.com/clare_liguori/status/1034829325306978304"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://www.ispreview.co.uk/index.php/2026/06/sky-broadband-users-accidentally-blocked-from-uk-nhs-website-and-app.html">
    <title>Sky Broadband Users Accidentally Blocked from UK NHS Website and App - ISPreview UK</title>
    <dc:date>2026-06-26T11:37:05+00:00</dc:date>
    <link>https://www.ispreview.co.uk/index.php/2026/06/sky-broadband-users-accidentally-blocked-from-uk-nhs-website-and-app.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Customers of the UK Sky Broadband ISP spent most of the 23rd of June unable to access the main NHS website and app:

<blockquote>customers of Sky Broadband reported that they were unable to access the main NHS website and app earlier in the week, seemingly after the internet provider accidentally managed to block it. But Sky has since suggested that the fault might have been with the NHS. The issue prevented people being able to access their medical data and manage appointments etc.

The problem appears to have occurred on Tuesday morning (23rd June 2026) and was reported across social media (X, Facebook etc.), including via threads on Reddit and Sky’s Community Forum. Customers initially thought the problem was with the NHS itself, but the health service instead pointed the finger of blame at the ISP (no other internet providers seem to have experienced the issue).</blockquote>

(via gwire, who notes that all DNS traffic for Sky customers is filtered...)]]></description>
<dc:subject>sky broadband isps uk networking via:gwire dns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6c756c58cb03/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sky"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:broadband"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:gwire"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-tcp-connection-management-on-ec2/">
    <title>Best Practices for TCP Connection Management on EC2</title>
    <dc:date>2026-06-02T10:49:57+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-tcp-connection-management-on-ec2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Well _this_ is a really crappy thing for AWS to mess around with, and then hide the announcement on a "best practices" page:

"With sixth-generation AWS Nitro (Nitro V6) instances, launched in June 2025 [c8, r8, etc], the default TCP connection tracking idle timeout changed from 432,000 seconds (5 days) to 350 seconds. Applications that hold idle connections open for long periods, such as [uhhh pretty much everything built on TCP - jm] may experience unexpected connection drops after migrating to these instances."

They go on to recommend that you "implement keepalives and connection lifecycle management", which is great fun if you don't control the code implementing your TCP-based network protocols.  This is a very fundamental change for many protocols so it'll be fun dealing with it.

Kudos to Adam C in the ITC Slack for spotting this a while back.]]></description>
<dc:subject>networking protocols tcp idle-timeouts aws architecture nitro conntrack idle-connections</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d3963371f1ff/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:idle-timeouts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nitro"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:conntrack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:idle-connections"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/homelab/comments/1sz9li4/invisible_bend_insensitive_bidi_fiber_is_amazing/">
    <title>&quot;Invisible&quot; bend insensitive bidi fiber</title>
    <dc:date>2026-05-05T09:19:23+00:00</dc:date>
    <link>https://www.reddit.com/r/homelab/comments/1sz9li4/invisible_bend_insensitive_bidi_fiber_is_amazing/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bookmarking for a future home-network upgrade.... this tiny fiber cable is practically invisible, bends easily, and supports 10Gbps:

> "invisible" bend insensitive fiber (G.657.A2 / G.657.B3). It's under a millimeter in diameter and basically vanishes into corners and base board crevices. From more than a meter away is't completely unnoticeable. Together with a pair of bidirectional SFP transceivers this makes an amazing retrofit option for locations where laying new runs is not an option. ]]></description>
<dc:subject>10gbps networking home fibre fiber wiring via:itc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2cdebcc39bfd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:10gbps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fibre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fiber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.jeffgeerling.com/blog/2026/new-10-gbe-usb-adapters-cooler-smaller-cheaper/">
    <title>New 10 GbE USB adapters are cooler, smaller, cheaper - Jeff Geerling</title>
    <dc:date>2026-04-27T08:45:23+00:00</dc:date>
    <link>https://www.jeffgeerling.com/blog/2026/new-10-gbe-usb-adapters-cooler-smaller-cheaper/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Not sure I'm at the point where I need a 10 gigabit ethernet USB adaptor, but this is good to have bookmarked]]></description>
<dc:subject>ethernet usb networking hardware via:hn reviews 10gbe</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:14e53f7877ac/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethernet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:hn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:10gbe"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://restofworld.org/2026/iran-blackout-tiered-internet/">
    <title>Iran is building a two-tier internet that locks 85 million citizens out of the global web</title>
    <dc:date>2026-01-26T12:03:59+00:00</dc:date>
    <link>https://restofworld.org/2026/iran-blackout-tiered-internet/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Following a repressive crackdown on protests, the government is now building a system that grants web access only to security-vetted elites, while locking 90 million citizens inside an intranet:

<blockquote>Government spokesperson Fatemeh Mohajerani confirmed international access will not be restored until at least late March. Filterwatch, which monitors Iranian internet censorship from Texas, cited government sources, including Mohajerani, saying access will “never return to its previous form.”

The system is called Barracks Internet, according to confidential planning documents obtained by Filterwatch. Under this architecture, access to the global web will be granted only through a strict security whitelist.

The idea of tiered internet access is not new in Iran. Since at least 2013, the regime has quietly issued “white SIM cards,” giving unrestricted global internet access to approximately 16,000 people, while 85 million citizens remain cut off.</blockquote>

]]></description>
<dc:subject>barracks-internet iran censorship internet networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d680eaa84ade/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:barracks-internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iran"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:censorship"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=45055604">
    <title>censorship circumvention via VPN</title>
    <dc:date>2025-09-02T15:25:29+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=45055604</link>
    <dc:creator>jm</dc:creator><description><![CDATA["I've got experience working on censorship circumvention for a major VPN provider" -- good HN comment on this ever-more-relevant topic.  Mullvad gets a thumbs up]]></description>
<dc:subject>censorship vpns networking privacy politics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:27c9c09d5677/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:censorship"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:privacy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:politics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.elastic.co/observability-labs/blog/debugging-aks-packet-loss">
    <title>Debugging Azure Networking for Elastic Cloud Serverless</title>
    <dc:date>2025-06-10T08:46:06+00:00</dc:date>
    <link>https://www.elastic.co/observability-labs/blog/debugging-aks-packet-loss</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good writeup of fixing a Linux packet loss issue in Azure, using low-level access to the VMs running k8s nodes.

<blockquote>
Elastic's Site Reliability Engineering team (SRE) observed unstable throughput and packet loss in Elastic Cloud Serverless running on Azure Kubernetes Service (AKS). After investigation, we identified the primary contributing factors to be RX ring buffer overflows and kernel input queue saturation on SR-IOV interfaces. To address this, we increased RX buffer sizes and adjusted the netdev backlog, which significantly improved network stability.
</blockquote>]]></description>
<dc:subject>sr-iov linux networking bugs azure debugging ops sre drivers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aac45eb89c4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sr-iov"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drivers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://jan.wildeboer.net/2025/04/Web-is-Broken-Botnet-Part-2/">
    <title>How &quot;Residential Proxies&quot; work</title>
    <dc:date>2025-06-10T08:33:30+00:00</dc:date>
    <link>https://jan.wildeboer.net/2025/04/Web-is-Broken-Botnet-Part-2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is kinda shady -- it seems there are mobile SDKs that are included in some apps which proxy network traffic for their customers?]]></description>
<dc:subject>scraping apps mobile networking residential-proxies proxies botnets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:351f8a81655f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scraping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:residential-proxies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proxies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:botnets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://store-eu.gl-inet.com/products/flint-2-gl-mt6000-wi-fi-6-high-performance-home-router">
    <title>GL-MT6000</title>
    <dc:date>2025-03-15T20:46:43+00:00</dc:date>
    <link>https://store-eu.gl-inet.com/products/flint-2-gl-mt6000-wi-fi-6-high-performance-home-router</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Looking at the OpenWRT forums, this is the current recommended device for running OpenWRT for the wifi6 generation.  Handles running wireguard at 900Mbps, which seems speedy enough]]></description>
<dc:subject>openwrt devices hardware routers ap networking wireguard</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b4a69fb44930/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openwrt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireguard"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2025/03/aws-waf-ja4-fingerprinting-aggregation-ja3-ja4-fingerprints-rate-based-rules/">
    <title>AWS WAF adds JA4 fingerprinting</title>
    <dc:date>2025-03-07T09:52:47+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2025/03/aws-waf-ja4-fingerprinting-aggregation-ja3-ja4-fingerprints-rate-based-rules/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[TIL:

<blockquote>A JA4 TLS client fingerprint contains a 36-character long fingerprint of the TLS Client Hello which is used to initiate a secure connection from clients. The fingerprint can be used to build a database of known good and bad actors to apply when inspecting HTTP[S] requests. These new features enhance your ability to identify and mitigate sophisticated attacks by creating more precise rules based on client behavior patterns. By leveraging both JA4 and JA3 fingerprinting capabilities, you can implement robust protection against automated threats while maintaining legitimate traffic flow to your applications.</blockquote>
]]></description>
<dc:subject>fingerprinting http https tls ja3 ja4 inspection networking firewalls waf web</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:383a5952e2e9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fingerprinting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:https"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ja3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ja4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:inspection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:firewalls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:waf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mehdio.substack.com/p/duckdb-goes-distributed-deepseeks">
    <title>DeepSeek’s smallpond</title>
    <dc:date>2025-03-03T10:36:11+00:00</dc:date>
    <link>https://mehdio.substack.com/p/duckdb-goes-distributed-deepseeks</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some interesting notes about smallpond, a new high-performance DuckDB-based distributed data lake query system from DeepSeek:

<blockquote>
DeepSeek is introducing smallpond, a lightweight open-source framework, leveraging DuckDB to process terabyte-scale datasets in a distributed manner. Their benchmark states: “Sorted 110.5TiB of data in 30 minutes and 14 seconds, achieving an average throughput of 3.66TiB/min.”

The benchmark on 100TB mentioned is actually using the custom DeepSeek 3FS framework: Fire-Flyer File System is a high-performance distributed file system designed to address the challenges of AI training and inference workloads. [...] compared to AWS S3, 3FS is built for speed, not just storage. While S3 is a reliable and scalable object store, it comes with higher latency and eventual consistency [...] 3FS, on the other hand, is a high-performance distributed file system that leverages SSDs and RDMA networks to deliver low-latency, high-throughput storage. It supports random access to training data, efficient checkpointing, and strong consistency.
</blockquote>

So -- this is very impressive. However!

1. RDMA (remote direct memory access) networking for a large-scale storage system! That is absolutely bananas.  I wonder how much that benchmark cluster cost to run... still, this is a very interesting technology for massive-scale super-low-latency storage.  https://www.definite.app/blog/smallpond also notes "3FS achieves a remarkable read throughput of 6.6 TiB/s on a 180-node cluster, which is significantly higher than many traditional distributed file systems."

2. it seems smallpond operates strictly with partition-level parallelism, so if your data isn't partitioned in exactly the right way, you may still find your query bottlenecked:

<blockquote>
Smallpond’s distribution leverages Ray Core at the Python level, using partitions for scalability. Partitioning can be done manually, and Smallpond supports:

- Hash partitioning (based on column values);
- Even partitioning (by files or row counts);
- Random shuffle partitioning
</blockquote>

As I understand it, Trino has a better idea of how to scale out queries across worker nodes even without careful pre-partitioning, which is handy.]]></description>
<dc:subject>data-lakes deepseek duckdb rdma networking 3fs smallpond trino ray</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:694c7fc28aa3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-lakes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deepseek"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:duckdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rdma"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3fs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smallpond"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trino"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ray"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/almeidapaulopt/tsdproxy">
    <title>tsdproxy</title>
    <dc:date>2025-02-24T11:24:41+00:00</dc:date>
    <link>https://github.com/almeidapaulopt/tsdproxy</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I'm pretty happy with my current setup for the home network, but this is one I'll keep in the back pocket for future possible use:

<blockquote>[Tailscale Docker Proxy] simplifies the process of securely exposing services and Docker containers to your Tailscale network by automatically creating Tailscale machines for each tagged container. This allows services to be accessible via unique, secure URLs without the need for complex configurations or additional Tailscale containers.</blockquote>

]]></description>
<dc:subject>docker tailscale containers home networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3ab6b36864bf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tailscale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.waveform.com/tools/bufferbloat">
    <title>Bufferbloat Test</title>
    <dc:date>2025-01-10T10:48:08+00:00</dc:date>
    <link>https://www.waveform.com/tools/bufferbloat</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A handy tool to test your internet connection for "bufferbloat", the error condition involving "undesirable high latency caused by other traffic on your network. It happens when a flow uses more than its fair share of the bottleneck. Bufferbloat is the primary cause of bad performance for real-time Internet applications like VoIP calls, video games, and videoconferencing."

(My home internet connection is currently rating a C: "your latency increased considerably under load", jumping from a min/mean/p95/max of 10.7, 16.9, 23.7, 30.1ms to 35.3, 98.4, 121.0, 286.0ms under load, yikes, so looks like I need to do some optimising.)]]></description>
<dc:subject>bufferbloat internet networking optimisation performance testing tools</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:93a6fb532124/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bufferbloat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gist.github.com/jmason/aabd9d3acc86d9098654e8559e93b707">
    <title>Ridding my home network of IP addresses</title>
    <dc:date>2024-12-04T12:25:50+00:00</dc:date>
    <link>https://gist.github.com/jmason/aabd9d3acc86d9098654e8559e93b707</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I have a bunch of self-hosted web apps and services running on my home network, each with a bare IP address and a high port number. I recently took on the project of getting rid of these IP addresses, prettifying the URLs and adding decent HTTPS to the mix.  Here's a write-up of what I did and how it now works.]]></description>
<dc:subject>https caddy home-network networking lan reverse-proxies lets-encrypt tailscale dns tls cloudflare ops hacks home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8361601e79d4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:https"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caddy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home-network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reverse-proxies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lets-encrypt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tailscale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudflare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ripe89.ripe.net/presentations/34-Sky-UK-MAP-T-RIPE89.pdf">
    <title>[pdf] Sky UK on their IPv6/IPv4 gateways</title>
    <dc:date>2024-11-19T15:13:17+00:00</dc:date>
    <link>https://ripe89.ripe.net/presentations/34-Sky-UK-MAP-T-RIPE89.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A presentation from RIPE89 detailing Sky's MAP-T setup, "IPv6-only with IPv4aaS (MAP-T)".  Basically they now use MAP-T translation devices to provide "IPv4 as a service", transparent NAT mapping between IPv6 and IPv4.  I suspect this is similar to how Virgin Media operates their network, too, in Ireland.

Interestingly, there are now network features (like local CDN POPs) which are more performant when using IPv6 natively, as they avoid a "trombone" route via a network-border translation device to get an IPv4 address.  As a result, it's actually starting to be worthwhile running an IPv6 home network....]]></description>
<dc:subject>ipv4 ipv6 networking home sky isps ripe map-t nat ip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:72c4404ac7c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipv4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipv6"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sky"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ripe"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:map-t"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arstechnica.com/gadgets/2024/10/ward-christensen-bbs-inventor-and-architect-of-our-online-age-dies-at-age-78/">
    <title>Obituary for Ward Christensen</title>
    <dc:date>2024-10-15T10:52:12+00:00</dc:date>
    <link>https://arstechnica.com/gadgets/2024/10/ward-christensen-bbs-inventor-and-architect-of-our-online-age-dies-at-age-78/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Ward Christensen, BBS inventor and architect of our online age, dies at age 78":

<blockquote>
On Friday, Ward Christensen, co-inventor of the computer bulletin board system (BBS), died at age 78 in Rolling Meadows, Illinois. Christensen, along with Randy Suess, created the first BBS in Chicago in 1978, leading to an important cultural era of digital community-building that presaged much of our online world today.

Prior to creating the first BBS, Christensen invented XMODEM, a 1977 file transfer protocol that made much of the later BBS world possible by breaking binary files into packets and ensuring that each packet was safely delivered over sometimes unstable and noisy analog telephone lines. It inspired other file transfer protocols that allowed ad-hoc online file sharing to flourish.

While Christensen himself was always humble about his role in creating the first BBS, his contributions to the field did not go unrecognized. In 1992, Christensen received two Dvorak Awards, including a lifetime achievement award for "outstanding contributions to PC telecommunications." The following year, the Electronic Frontier Foundation honored him with the Pioneer Award.
</blockquote>]]></description>
<dc:subject>bbses history computing ward-christensen xmodem networking filesharing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:875da72f2890/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bbses"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ward-christensen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xmodem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesharing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://infosec.exchange/@briankrebs/111434534909543769">
    <title>Evading wireless tether speed caps</title>
    <dc:date>2024-10-07T10:45:36+00:00</dc:date>
    <link>https://infosec.exchange/@briankrebs/111434534909543769</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Handy tip from Brian Krebs - if you are tethering to a mobile phone, and network speeds are mysteriously limited, it may be your provider is throttling tethering.  Changing the TTL may help, since some providers in the US at least are using a really stupid mechanism to detect tethering]]></description>
<dc:subject>tethering mobile wireless networking ttl via:brian-krebs networks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fe45e554de45/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tethering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ttl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:brian-krebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://encore.dev/blog/retries">
    <title>Retries, illustrated</title>
    <dc:date>2024-07-10T22:46:42+00:00</dc:date>
    <link>https://encore.dev/blog/retries</link>
    <dc:creator>jm</dc:creator><description><![CDATA["An interactive study of common retry methods" -- basically graphical, interactive demos of retry patterns, backoff, and jittering]]></description>
<dc:subject>retries retrying backoff jitter networking soa services interactive demos</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:25d687fb2382/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retrying"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backoff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interactive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:demos"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://exple.tive.org/blarg/2024/04/24/magic-numbers/">
    <title>How did Ethernet get its 1500-byte MTU?</title>
    <dc:date>2024-04-29T15:58:08+00:00</dc:date>
    <link>https://exple.tive.org/blarg/2024/04/24/magic-numbers/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Now this is a great bit of networking trivia!

<blockquote>1500 bytes is a bit out there as numbers go, or at least it seems that way if you touch computers for a living. It’s not a power of two or anywhere close, it’s suspiciously base-ten-round, and computers don’t care all that much about base ten, so how did we get here?

Well, today I learned that if you add the Ethernet header – 36 bytes – then an MTU of 1500 plus that header is 1536 bytes, which is 12288 bits, which takes 2^12 microseconds to transmit at 3Mb/second, and because the Xerox Alto computer for which Ethernet was invented had an internal data path that ran at 3Mhz, then you could just write the bits into the Alto’s memory at the precise speed at which they arrived, saving the very-expensive-then cost of extra silicon for an interface or any buffering hardware.

Now, “we need to pick just the right magic number here so we can take data straight off the wire and blow it directly into the memory of this specific machine over there” is, to any modern sensibilities, lunacy. It’s obviously, dangerously insane, there are far too many computers and bad people with computers in the world for that. But back when the idea of network security didn’t exist because computers barely existed, networks mostly didn’t exist and unvetted and unsanctioned access to those networks definitely didn’t exist, I bet it seemed like a very reasonable tradeoff.

It really is amazing how many of the things we sort of ambiently accept as standards today, if we even realize we’re making that decision at all, are what they are only because some now-esoteric property of the now-esoteric hardware on which the tech was first invented let the inventors save a few bucks.</blockquote>

]]></description>
<dc:subject>ethernet networking magic-numbers via:itc hardware history xerox alto</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:74dd2f82839b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethernet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:magic-numbers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xerox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alto"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://torrentfreak.com/piracy-shield-cloudflare-disaster-blocks-countless-sites-fires-up-opposition-240226/">
    <title>Italy's &quot;Piracy Shield&quot; blocked Cloudflare</title>
    <dc:date>2024-03-04T10:16:03+00:00</dc:date>
    <link>https://torrentfreak.com/piracy-shield-cloudflare-disaster-blocks-countless-sites-fires-up-opposition-240226/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Italy recently installed the AGCOM "anti-pezotto" system -- a web filtering system for the entire country, to block piracy.  After only a few weeks, it suffered its first major false positive by blocking a Cloudflare IP:

"Around 16:13 on Saturday, an IP address within Cloudflare’s AS13335, which currently accounts for 42,243,794 domains according to IPInfo, was targeted for blocking."

The false positive block lasted for 5 hours before being quietly reverted:

"Around five hours after the blockade was put in place, reports suggest that the order compelling ISPs to block Cloudflare simply vanished from the Piracy Shield system."

Cloudflare have written about the risk of false positives from IP blocking in the past: https://blog.cloudflare.com/consequences-of-ip-blocking/]]></description>
<dc:subject>cloudflare ip-blocks blocking piracy anti-pezzoto agcom fail filtering false-positives networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:986c513a9105/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudflare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip-blocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:piracy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:anti-pezzoto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agcom"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filtering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:false-positives"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/louislam/uptime-kuma">
    <title>louislam/uptime-kuma</title>
    <dc:date>2024-02-26T12:11:22+00:00</dc:date>
    <link>https://github.com/louislam/uptime-kuma</link>
    <dc:creator>jm</dc:creator><description><![CDATA["A fancy self-hosted [network] monitoring tool".  This is very pretty, offers a compellingly wide
set of uptime monitoring features including HTTPS cert validation, can notify via Slack or Telegram,
and is self-hosted as a Docker container:

- Monitoring uptime for HTTP(s) / TCP / HTTP(s) Keyword / HTTP(s) Json Query / Ping / DNS Record / Push / Steam Game Server / Docker Containers;
- Fancy, Reactive, Fast UI/UX;
- Notifications via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services, click here for the full list
- 20-second intervals.

If I hadn't already built out a load of uptime monitoring, I might add this one.  I may just add it anyway,
as you can never have too much monitoring, right?

(via Tristam on ITC Slack)]]></description>
<dc:subject>monitoring uptime network-monitoring networking ops via:itc via:tristam</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:01d82b0fa274/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network-monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:tristam"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://domagalski-j.medium.com/aws-alb-returns-503-for-istio-enabled-pods-a6942383143c">
    <title>AWS ALB returns 503 for Istio enabled pods</title>
    <dc:date>2023-10-25T10:38:31+00:00</dc:date>
    <link>https://domagalski-j.medium.com/aws-alb-returns-503-for-istio-enabled-pods-a6942383143c</link>
    <dc:creator>jm</dc:creator><description><![CDATA[yes, yes it does. I am not a fan of istio at the moment]]></description>
<dc:subject>istio aws alb bugs networking tcp fail k8s</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2e144dfcee66/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:istio"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://smithy.io/2.0/aws/protocols/aws-json-1_0-protocol.html">
    <title>AWS JSON 1.0 protocol - Smithy 2.0</title>
    <dc:date>2023-07-28T20:07:47+00:00</dc:date>
    <link>https://smithy.io/2.0/aws/protocols/aws-json-1_0-protocol.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Looks like AWS are switching to a new wire protocol:

"AWS JSON protocol is more efficient at serialization and deserialization of requests and responses when compared to AWS query protocol. Based on AWS performance tests for a 5 KB message payload, JSON protocol for Amazon SQS reduces end-to-end message processing latency by up to 23%, and reduces application client side CPU and memory usage."]]></description>
<dc:subject>aws json protocols wire sqs networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aed717e73f79/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wire"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/eldadru/ksniff">
    <title>eldadru/ksniff</title>
    <dc:date>2023-07-12T13:58:22+00:00</dc:date>
    <link>https://github.com/eldadru/ksniff</link>
    <dc:creator>jm</dc:creator><description><![CDATA["A kubectl plugin that utilize tcpdump and Wireshark to start a remote capture on any pod in your Kubernetes cluster.  You get the full power of Wireshark with minimal impact on your running pods.

When working with micro-services, many times it's very helpful to get a capture of the network activity between your micro-service and it's dependencies.

ksniff use kubectl to upload a statically compiled tcpdump binary to your pod and redirecting it's output to your local Wireshark for smooth network debugging experience."

This would be an absolutely vital piece of software once you get into the nitty-gritty of debugging TCP issues in K8S; I've been on the verge of needing a packet capture once or twice, but managed to just about avoid it so far. I'll be keeping this one in the back pocket.

]]></description>
<dc:subject>debugging kubernetes network networking packet-captures tcpdump wireshark ops k8s eks sniffing kubectl</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f25141e7690f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-captures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcpdump"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireshark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sniffing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubectl"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://karlstoney.com/2019/05/31/istio-503s-ucs-and-tcp-fun-times/">
    <title>Istio: 503's with UC's and TCP Fun Times</title>
    <dc:date>2023-07-12T13:54:04+00:00</dc:date>
    <link>https://karlstoney.com/2019/05/31/istio-503s-ucs-and-tcp-fun-times/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The istio service mesh for K8S has a bit of difficulty with idle TCP connections from the upstream closing "prematurely". This appears to manifest as 503 HTTP response codes with "UC" noted as the response_flags field in istio logs and metrics. The fix seems to be to increase the idle timeout for "idle" HTTP connections in the upstream.]]></description>
<dc:subject>istio kubernetes k8s eks http tcp timeouts connection-pools networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3e01e8a914df/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:istio"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timeouts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:connection-pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.mattb.nz/w/2023/06/02/calling-time-on-dnssec/">
    <title>Calling time on DNSSEC - Matt Brown</title>
    <dc:date>2023-06-26T16:34:35+00:00</dc:date>
    <link>https://www.mattb.nz/w/2023/06/02/calling-time-on-dnssec/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["For almost all domains and use-cases, the costs and risks of deploying DNSSEC outweigh the benefits it provides. Don’t bother signing your zones":

<blockquote>DNSSEC is complex and risky to deploy. Choosing to sign your zone will almost inevitably mean that you will experience lower availability for your domain over time than if you leave it unsigned. Even if you have a team of DNS experts maintaining your zone and DNS infrastructure, the risk of routine operational tasks triggering a loss of availability (unrelated to any attempted attacks that DNSSEC may thwart) is very high - almost guaranteed to occur. Worse, because of the nature of DNS and DNSSEC these incidents will tend to be prolonged and out of your control to remediate in a timely fashion.

The only benefit you get in return for accepting this almost certain reduction in availability is trust in the integrity of the DNS data a subset of your users (those who validate DNSSEC) receive. Trusted DNS data that is then used to communicate across an untrusted network layer. An untrusted network layer which you are almost certainly protecting with TLS which provides a more comprehensive and trustworthy set of security guarantees than DNSSEC is capable of, and provides those guarantees to all your users regardless of whether they are validating DNSSEC or not.

In summary, in our modern world where TLS is ubiquitous, DNSSEC provides only a thin layer of redundant protection on top of the comprehensive guarantees provided by TLS, but adds significant operational complexity, cost and a high likelihood of lowered availability.</blockquote>

]]></description>
<dc:subject>dns dnssec security networking protocols tls</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b813bb37b4ff/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dnssec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dropbox.tech/frontend/investigating-the-impact-of-http3-on-network-latency-for-search">
    <title>Dropbox testing HTTP3</title>
    <dc:date>2023-05-22T10:02:25+00:00</dc:date>
    <link>https://dropbox.tech/frontend/investigating-the-impact-of-http3-on-network-latency-for-search</link>
    <dc:creator>jm</dc:creator><description><![CDATA["dark testing", live in production, to a separate test domain. Great way to gather some real-world data.  Latencies are appreciably better, particularly for low-quality connections]]></description>
<dc:subject>dropbox http3 http2 http protocols udp networking ip testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9d832e568456/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropbox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://elk.zone/mastodon.ie/@danhon@dan.mastohon.com/110209358807929291">
    <title>Moca adapters</title>
    <dc:date>2023-04-17T13:33:49+00:00</dc:date>
    <link>https://elk.zone/mastodon.ie/@danhon@dan.mastohon.com/110209358807929291</link>
    <dc:creator>jm</dc:creator><description><![CDATA[TIL you can run ethernet over coax at 2.5gbps.  Long gone are the days of vampire taps and 10BASE2]]></description>
<dc:subject>coax ethernet networking wired moca cabling home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:55552fad1374/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethernet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wired"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:moca"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cabling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.cablemonkey.ie/cat6a-modules-outlets/9215-cat6a-ftp-tool-less-keystone-module-5056045700332.html">
    <title>Cat6a FTP Tool-Less Keystone Module</title>
    <dc:date>2023-03-15T10:01:38+00:00</dc:date>
    <link>https://www.cablemonkey.ie/cat6a-modules-outlets/9215-cat6a-ftp-tool-less-keystone-module-5056045700332.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[For future use -- CAT6A cable endpoints which don't require tricky crimping: "no crimp tool required at all, very much worth the extra cost, and they clip into the wall sockets or a patch panel ... you can do them with your fingers and a flush snips to get rid of the ends after you push the wires in" says Adam C on ITC Slack, at https://irishtechcommunity.slack.com/archives/C11BG27L2/p1678841261913069]]></description>
<dc:subject>cat6a wiring home networking cables via:itc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a328cbd07414/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cat6a"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wiring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2023/02/ena-express-15-new-ec2-instances/">
    <title>AWS' proprietary SRD protocol</title>
    <dc:date>2023-02-16T11:48:02+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2023/02/ena-express-15-new-ec2-instances/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["ENA Express is a networking feature that uses the AWS Scalable Reliable Datagram (SRD) protocol to improve network performance in two key ways: higher single flow bandwidth and lower tail latency for network traffic between EC2 instances. SRD is a proprietary protocol that delivers these improvements through advanced congestion control, multi-pathing, and packet reordering directly from the Nitro card."

Right now this supports only intra-EC2 networking between instances running on the latest generation of instance types.]]></description>
<dc:subject>srd networking protocols ip ena-express aws amazon multi-pathing congestion-control nitro</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:adb42574c16a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:srd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ena-express"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multi-pathing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:congestion-control"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nitro"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.airwire.ie/index.php/avail/main/">
    <title>Irish FTTH line checker</title>
    <dc:date>2023-02-01T10:19:49+00:00</dc:date>
    <link>https://www.airwire.ie/index.php/avail/main/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A rather retro-looking (but very functional) aggregated line checker website to check availability of fibre to the home broadband services at your Eircode.]]></description>
<dc:subject>via:itc ftth broadband internet networking fibre siro openeir</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f3d376b1b0c6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ftth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:broadband"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fibre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:siro"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openeir"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html">
    <title>EC2 instance network error metrics</title>
    <dc:date>2023-01-24T11:03:07+00:00</dc:date>
    <link>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[looks like Amazon are now exposing a bunch of error metrics for their EC2 instance network drivers in Linux]]></description>
<dc:subject>metrics ec2 ops drivers networking bandwidth errors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3176cdd6fec2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drivers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bandwidth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nogalliance.org/our-task-forces/keep-ukraine-connected/">
    <title>Keep Ukraine Connected</title>
    <dc:date>2022-04-13T14:10:53+00:00</dc:date>
    <link>https://nogalliance.org/our-task-forces/keep-ukraine-connected/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A project by the NOG Alliance:

<blockquote>We are creating a platform so that we can collect what our colleagues in Ukraine need to keep the internet up and running. We will be the link between the tech community, manufacturers, whoever else wants to get involved and Ukraine. Where absolutely necessary we can even transport the required hardware from Europe to the Ukraine. The aim of the “Keep Ukraine Connected” task force is not only to mediate, but also to actively help the Ukrainian internet stay up.</blockquote>

]]></description>
<dc:subject>inog nogs networking internet ukraine</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:72791fb4d8fa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:inog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nogs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ukraine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://itnext.io/what-exactly-are-vpc-endpoints-and-why-they-need-real-inter-region-support-283a9987fe51">
    <title>What Exactly are AWS VPC Endpoints</title>
    <dc:date>2022-03-07T17:34:20+00:00</dc:date>
    <link>https://itnext.io/what-exactly-are-vpc-endpoints-and-why-they-need-real-inter-region-support-283a9987fe51</link>
    <dc:creator>jm</dc:creator><description><![CDATA[VPC endpoints are AWS magic to allow private, secure access to S3, DynamoDB, and other AWS services without any traversal outside of your private VPC network. This blog post is a good description of how this is accomplished, and very useful if you need to debug AWS networking issues.

(via Last Week In AWS)]]></description>
<dc:subject>aws networking vpc vpc-endpoints architecture ops s3 dynamodb security</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ada6e9069db1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpc-endpoints"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.cablemonkey.ie/">
    <title>CableMonkey.ie</title>
    <dc:date>2022-01-06T10:25:40+00:00</dc:date>
    <link>https://www.cablemonkey.ie/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[decent local supplier for networking gear, smart plugs, cables etc.]]></description>
<dc:subject>cables networking networks ireland hardware shopping</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e4e7283f9aaf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shopping"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3">
    <title>Cache warming: Leveraging EBS for moving petabytes of data</title>
    <dc:date>2021-12-01T10:09:14+00:00</dc:date>
    <link>https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting idea for EC2-based high-volume workload rebalancing, exploiting a feature of EC2 networking -- EBS gets a dedicated additional network bandwidth allocation]]></description>
<dc:subject>architecture ebs memcache caching networking ec2 netflix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1e40b505a3ec/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://siteviewer.comreg.ie/">
    <title>ComReg SiteViewer</title>
    <dc:date>2021-09-27T14:46:14+00:00</dc:date>
    <link>https://siteviewer.comreg.ie/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Handy to explore what 3G/4G/5G coverage a particular rural spot in Ireland may get]]></description>
<dc:subject>comreg telecoms 3g 4g 5g networking isps coverage ireland</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ac78c6a46d97/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comreg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telecoms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:3g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:4g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:5g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coverage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html">
    <title>why Apple devices have wifi problems on non-Apple APs</title>
    <dc:date>2021-09-15T09:14:35+00:00</dc:date>
    <link>https://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I've always suspected some bullshit like this -- Apple devices (Macs and iPhones) expect a specific non-standard wifi setting. If you've noticed Apple devices falling off the network and taking a long time (many seconds) to rejoin, where devices with other OSes do not have the same problem, this may be the cause.

tl;dr: the DTIM (delivery traffic indication message) setting, which defaults to 1 in a standards-compliant AP, is expected to be set to 3 by Apple devices, in order to improve battery life.

Source: https://twitter.com/revolutionwifi/status/725489216768106496 ("Apple engineers have strongly suggested a DTIM of 3.")]]></description>
<dc:subject>dtim wifi wireless 802.11 apple aps hardware networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acf092a6c784/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dtim"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:802.11"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://eng.snap.com/quic-at-snap">
    <title>QUIC at Snapchat - Snap Engineering</title>
    <dc:date>2021-06-28T09:59:25+00:00</dc:date>
    <link>https://eng.snap.com/quic-at-snap</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Snapchat are fans, using cronet on the Android/iPhone client side. The HN comment thread at https://news.ycombinator.com/item?id=27626394 is also a decent read, some insightful discussion]]></description>
<dc:subject>http3 quic tcp networking mobile udp cronet snapchat</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:58d065b4f47c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cronet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:snapchat"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/">
    <title>Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance | talawah.io</title>
    <dc:date>2021-05-21T08:54:01+00:00</dc:date>
    <link>https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is very cool. Updating the old "C10K" problem space to C1.2M -- the current state of Linux userspace networking -- using libreactor and a whole load of up-to-date tweaks.

Interesting to note that this scale is feasible to run in Docker (using --network=host, of course).
]]></description>
<dc:subject>http servers c10k linux performance scalability ops tuning libreactor networking tcp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:022774113a4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c10k"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libreactor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed">
    <title>Boosting Dropbox upload speed—and making Windows’ TCP stack resilient to network reordering - Dropbox</title>
    <dc:date>2021-05-18T22:04:37+00:00</dc:date>
    <link>https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Featuring an interesting dig into the current state of Windows system and network-level diagnostic tools:

<blockquote>netsh trace [...] correlates events on the wire with events that happen on the TCP layer, timers, buffer management, socket layer, and even the Windows asyncio subsystem (IOCP).</blockquote>

]]></description>
<dc:subject>windows tools cli networking dropbox iocp tcp ip internet kernel</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9b45779da44f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:windows"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropbox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iocp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://jimmysong.io/en/blog/sidecar-injection-iptables-and-traffic-routing/">
    <title>Sidecar injection and transparent traffic hijacking process in Istio explained in detail · Jimmy Song</title>
    <dc:date>2021-04-29T13:11:00+00:00</dc:date>
    <link>https://jimmysong.io/en/blog/sidecar-injection-iptables-and-traffic-routing/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A solid explanation of Istio's traffic-hijacking mode using iptables and its sidecar pattern]]></description>
<dc:subject>kubernetes iptables sidecars istio service-mesh networking k8s eks routing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3b0dfec4d9d9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iptables"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sidecars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:istio"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-mesh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://berthub.eu/articles/posts/5g-elephant-in-the-room/">
    <title>Bert Hubert on the Huawei/5G backdoor controversy</title>
    <dc:date>2021-04-19T09:42:24+00:00</dc:date>
    <link>https://berthub.eu/articles/posts/5g-elephant-in-the-room/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some context -- European telcos no longer operate their equipment:

<blockquote>As an icebreaker, [telco operators] were asked if they thought the Chinese could eavesdrop through “backdoors” in Huawei equipment. Every single hand went up. One of the bankers then asked, for balance, if they thought the US could access communications through key Cisco equipment. “All the hands went straight back up without hesitation” [....]

In a modern telecommunications service provider, new equipment is deployed, configured, maintained and often financed by the vendor. Just to let that sink in, Huawei (and their close partners) already run and directly operate the mobile telecommunication infrastructure for over 100 million European subscribers.

The host service provider often has no detailed insight in what is going on, and would have a hard time figuring this out through their remaining staff. Rampant outsourcing has meant that most local expertise has also left the company, willingly or unwillingly.
</blockquote>

(via ITS slack)]]></description>
<dc:subject>telcos telecoms ops networking eu 5g china huawei nsa tapping</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d2ae6fa81687/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telcos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telecoms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:5g"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:china"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:huawei"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tapping"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://wiki.dd-wrt.com/wiki/index.php/Parental_control">
    <title>Parental control - DD-WRT Wiki</title>
    <dc:date>2021-04-12T10:09:57+00:00</dc:date>
    <link>https://wiki.dd-wrt.com/wiki/index.php/Parental_control</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Using DD-WRT to turn off the internet for certain devices during night-time hours]]></description>
<dc:subject>dd-wrt networking parenting parental-controls kids internet home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:034169cdf375/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dd-wrt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:parenting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:parental-controls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.waveform.com/tools/bufferbloat?test-id=e2656f6c-bebe-44c7-8005-c7fdfe013678">
    <title>Bufferbloat Test by Waveform</title>
    <dc:date>2021-04-08T10:42:54+00:00</dc:date>
    <link>https://www.waveform.com/tools/bufferbloat?test-id=e2656f6c-bebe-44c7-8005-c7fdfe013678</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Handy link to test bufferbloat effects on your internet connection]]></description>
<dc:subject>bufferbloat buffering internet networking isps congestion</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:17562d7c6f19/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bufferbloat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buffering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:congestion"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nelsonslog.wordpress.com/2021/03/11/speedify-and-multipath/">
    <title>Speedify and multipath</title>
    <dc:date>2021-03-12T10:23:07+00:00</dc:date>
    <link>https://nelsonslog.wordpress.com/2021/03/11/speedify-and-multipath/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting blog post from Nelson about Speedify, a proprietary multipath VPN service to bond two internet links to improve reliability]]></description>
<dc:subject>speedify multipath vpn vpns internet networking via:nelson</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b11da9b67abb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speedify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multipath"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/">
    <title>Apple tells app devs to use IPv6 as it's 1.4 times faster than IPv4</title>
    <dc:date>2020-07-31T10:32:56+00:00</dc:date>
    <link>https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>"when IPv6 is in use, the median connection setup is 1.4 times faster than IPv4. This is primarily due to reduced NAT usage and improved routing."</blockquote>

This is counterintuitive?]]></description>
<dc:subject>ipv6 ipv4 networking apple internet performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c0b2ebac997/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipv6"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipv4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.duckware.com/tech/wifi-in-the-us.html#PHY">
    <title>Understand Wi-Fi 4/5/6/6E (802.11 n/ac/ax)</title>
    <dc:date>2020-06-29T10:01:44+00:00</dc:date>
    <link>https://www.duckware.com/tech/wifi-in-the-us.html#PHY</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some excellent advice regarding the currently available wifi devices out there, 802.11ac, 4x4 MIMO, beamforming, and DFS channels. Top recommendations are the Ubiquiti nanoHD AP and the Netgear R7800]]></description>
<dc:subject>wifi 802.11n 802.11ac networking wireless home mimo mu-mimo dfs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a30d6f7c18a5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:802.11n"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:802.11ac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mimo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mu-mimo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dfs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://wimoodshop.nl/">
    <title>WiMood shop</title>
    <dc:date>2020-04-27T09:22:05+00:00</dc:date>
    <link>https://wimoodshop.nl/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good source for Ubiquiti gear in the EU (via ITS Slack)]]></description>
<dc:subject>via:its ubiquiti unifi wifi wireless shopping networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b9fe5ba97183/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:its"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubiquiti"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shopping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arstechnica.com/gadgets/2020/02/the-ars-technica-semi-scientific-guide-to-wi-fi-access-point-placement/">
    <title>The Ars Technica semi-scientific guide to Wi-Fi Access Point placement</title>
    <dc:date>2020-02-24T17:51:33+00:00</dc:date>
    <link>https://arstechnica.com/gadgets/2020/02/the-ars-technica-semi-scientific-guide-to-wi-fi-access-point-placement/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[top tips]]></description>
<dc:subject>wifi ops networking ieee802.11 wireless ars-technica tips advice radio</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1134f19d1050/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ieee802.11"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wireless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ars-technica"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:radio"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/">
    <title>Amazon EBS Multi-Attach now available on Provisioned IOPS io1 volumes</title>
    <dc:date>2020-02-17T10:49:05+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Attach multiple EC2 instances to the same EBS volume.  Now that is pretty cool]]></description>
<dc:subject>ebs ec2 filesystems networking ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f99d09d89c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://gm4fvm.blogspot.com/2018/06/power-line-adapter-noise-interference.html">
    <title>Power Line Adapter noise interference</title>
    <dc:date>2020-01-06T13:27:48+00:00</dc:date>
    <link>http://gm4fvm.blogspot.com/2018/06/power-line-adapter-noise-interference.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[oh dear, I use this model....

<blockquote>About 3 weeks ago our neighbour installed power line adapters. The PLAs in question were branded TP-Link [....]
How did I know that my neighbour had installed these? Well, the 50MHz band was immediately submerged under a wall of radio noise. Much tinkering with the Noise Blanker settings on the Icom IC-7300 allowed me to separate out two distinct types of noise - 1st a sound like a chicken clucking which was there 24 hours per day and - 2nd a wideband swoosh of white noise of varying strength which happened at certain times.</blockquote>

]]></description>
<dc:subject>noise rf wifi powerline networking home hardware radio</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e2319196b653/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:noise"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:powerline"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:radio"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/slackhq/nebula">
    <title>Nebula</title>
    <dc:date>2019-11-20T13:56:22+00:00</dc:date>
    <link>https://github.com/slackhq/nebula</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a scalable overlay networking tool with a focus on performance, simplicity and security. It lets you seamlessly connect computers anywhere in the world. Nebula is portable, and runs on Linux, OSX, and Windows. [...] It can be used to connect a small number of computers, but is also able to connect tens of thousands of computers.

Nebula incorporates a number of existing concepts like encryption, security groups, certificates, and tunneling, and each of those individual pieces existed before Nebula in various forms. What makes Nebula different to existing offerings is that it brings all of these ideas together, resulting in a sum that is greater than its individual parts.

Nebula is a mutually authenticated peer-to-peer software defined network based on the Noise Protocol Framework. Nebula uses certificates to assert a node's IP address, name, and membership within user-defined groups. Nebula's user-defined groups allow for provider agnostic traffic filtering between nodes. Discovery nodes allow individual peers to find each other and optionally use UDP hole punching to establish connections from behind most firewalls or NATs. Users can move data between nodes in any number of cloud service providers, datacenters, and endpoints, without needing to maintain a particular addressing scheme.
Nebula uses elliptic curve Diffie-Hellman key exchange, and AES-256-GCM in its default configuration.

Nebula was created to provide a mechanism for groups [of] hosts to communicate securely, even across the internet, while enabling expressive firewall definitions similar in style to cloud security groups.</blockquote>

]]></description>
<dc:subject>networking vpn nebula slack ops crypto overlay-networks tunnelling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:84f3329308a5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nebula"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:overlay-networks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tunnelling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.thescorpius.com/index.php/2016/03/14/dd-wrt-network-statistics-graphics-using-grafana-and-influxdb/">
    <title>DD-WRT Network Stats Graphics using Grafana and InfluxDB</title>
    <dc:date>2019-10-21T09:55:23+00:00</dc:date>
    <link>http://blog.thescorpius.com/index.php/2016/03/14/dd-wrt-network-statistics-graphics-using-grafana-and-influxdb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A slightly hackier approach to DD-WRT grafana metrics, but with a workaround when JFFS isn't an option]]></description>
<dc:subject>grafana networking metrics dd-wrt routers jffs influxdb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a686ad6da3e2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grafana"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dd-wrt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jffs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:influxdb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/trevorndodds/dd-wrt-grafana">
    <title>trevorndodds/dd-wrt-grafana</title>
    <dc:date>2019-10-21T09:54:29+00:00</dc:date>
    <link>https://github.com/trevorndodds/dd-wrt-grafana</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Send DD-WRT router metrics to a graphite server, and a nice Grafana dashboard for same.   Needs JFFS enabled on the router]]></description>
<dc:subject>dd-wrt wrt routers networking grafana graphite metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:59555aef5c79/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dd-wrt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wrt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grafana"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://rokt.com/engineering_blog/learnings-grpc-aws/">
    <title>Rokt.com's bad experiences with gRPC on AWS</title>
    <dc:date>2019-10-03T09:40:20+00:00</dc:date>
    <link>https://rokt.com/engineering_blog/learnings-grpc-aws/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ugh.  Sounds like AWS load balancers' HTTP/2 support is pretty immature, and this screws up gRPC:

<blockquote>With ALB, a client sends request to the ALB via HTTP/1.1 and then the ALB forwards the request to the backend targets to distribute the load. Unfortunately, with gRPC, it was not as simple because gRPC uses HTTP/2. The AWS ALB only supports HTTP/2 from client to ALB. The ALB then downgrades the request to HTTP/1.1 before forwarding it through to the backend target. Additionally, AWS ALB lacks support for HTTP trailers. Full support for HTTP/2 and trailers is required for gRPC to function. This left us with two options: spin up our own HTTP/2 compliant load balancer (e.g. Envoy, Nginx), or, use one of AWS’s lower-level, L4 Load Balancers such as the Elastic Load Balancer, ELB, or the newer Network Load Balancer, NLB.</blockquote>

Thereafter follows a parade of issues with NLB.  All pretty sucky.
]]></description>
<dc:subject>grpc aws alb elb nlb http2 http protocols networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:eea1b9e098c6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nlb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/bridgefy/how-to-use-the-bridgefy-offline-messaging-app-b4799af7649b">
    <title>How To Use The Bridgefy Offline Messaging App</title>
    <dc:date>2019-09-30T09:21:47+00:00</dc:date>
    <link>https://medium.com/bridgefy/how-to-use-the-bridgefy-offline-messaging-app-b4799af7649b</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Decent offline messaging system for smartphones -- uses Bluetooth to connect p2p, without requiring working internet]]></description>
<dc:subject>apps mobile offline networking bluetooth chat emergency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7a6bbce82790/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:offline"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bluetooth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emergency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://kazu-yamamoto.hatenablog.jp/entry/2019/09/20/165939">
    <title>Implementing graceful-close in Haskell network library</title>
    <dc:date>2019-09-27T10:19:20+00:00</dc:date>
    <link>https://kazu-yamamoto.hatenablog.jp/entry/2019/09/20/165939</link>
    <dc:creator>jm</dc:creator><description><![CDATA[One of the nice bits about HTTP 1.0 and 1.1 was the strong connection direction semantics, avoiding the classic TCP deadlock scenarios seen in bidirectional protocols.  But now HTTP/2 supports bidirectionality, so HTTP/2 servers need to be more careful about how they close connections, as this blog post describes -- tl;dr: shutdown(SHUT_WR) .
]]></description>
<dc:subject>http networking protocols http2 bidirectional-protocols tcp ip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9fc9cf60d72b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bidirectional-protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.pixelbeat.org/systems/FTTH/">
    <title>Replacing Eir's FTTH WiFi router with a NetGear Orbi</title>
    <dc:date>2019-09-16T11:07:30+00:00</dc:date>
    <link>https://www.pixelbeat.org/systems/FTTH/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great writeup from Padraig Brady. sounds like solid hardware -- I'd get one if I needed to replace my current setup based on this]]></description>
<dc:subject>orbi netgear han lan home networking wifi ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:678e221848a8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:orbi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netgear"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:han"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloud.google.com/blog/topics/inside-google-cloud/an-update-on-sundays-service-disruption">
    <title>An update on Sunday’s service disruption | Google Cloud Blog</title>
    <dc:date>2019-06-04T18:49:01+00:00</dc:date>
    <link>https://cloud.google.com/blog/topics/inside-google-cloud/an-update-on-sundays-service-disruption</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Google posting the most inappropriately upbeat post-mortem I've ever read...

<blockquote>In essence, the root cause of Sunday’s disruption was a configuration change that was intended for a small number of servers in a single region. The configuration was incorrectly applied to a larger number of servers across several neighboring regions, and it caused those regions to stop using more than half of their available network capacity. The network traffic to/from those regions then tried to fit into the remaining network capacity, but it did not. The network became congested, and our networking systems correctly triaged the traffic overload and dropped larger, less latency-sensitive traffic in order to preserve smaller latency-sensitive traffic flows, much as urgent packages may be couriered by bicycle through even the worst traffic jam.

Google’s engineering teams detected the issue within seconds, but diagnosis and correction took far longer than our target of a few minutes. Once alerted, engineering teams quickly identified the cause of the network congestion, but the same network congestion which was creating service degradation also slowed the engineering teams’ ability to restore the correct configurations, prolonging the outage. The Google teams were keenly aware that every minute which passed represented another minute of user impact, and brought on additional help to parallelize restoration efforts.</blockquote>

]]></description>
<dc:subject>gcp google odd outages post-mortems networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f7abad5a30a2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:odd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://stressgrid.com/blog/pps_limits_in_ec2/">
    <title>Packets-per-second limits in EC2</title>
    <dc:date>2019-04-26T10:26:17+00:00</dc:date>
    <link>https://stressgrid.com/blog/pps_limits_in_ec2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>By running these experiments, we determined that each EC2 instance type has a packet-per-second budget. Surprisingly, this budget goes toward the total of incoming and outgoing packets. Even more surprisingly, the same budget gets split between multiple network interfaces, with some additional performance penalty. This last result informs against using multiple network interfaces when tuning the system for higher networking performance.

The maximum budget for m5.metal and m5.24xlarge is 2.2M packets per second. Given that each HTTP transaction takes at least four packets, we can translate this to a maximum of 550k requests per second on the largest m5 instance with Enhanced Networking enabled.</blockquote>

]]></description>
<dc:subject>aws ec2 networking pps packets tcp ip benchmarking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94369fd8e8b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44">
    <title>Tinder’s move to Kubernetes – Tinder Engineering – Medium</title>
    <dc:date>2019-04-18T12:56:05+00:00</dc:date>
    <link>https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A solid technical writeup of Tinder's k8s migration.  Some problems with Flannel, DNS and (worryingly) ELB, but good +1s for Envoy as a sidecar]]></description>
<dc:subject>kubernetes k8s flannel networking elb aws envoy ec2 ops tinder</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:68e5fb0e2425/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flannel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:envoy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tinder"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/MarcJBrooker/status/1093650148708691969">
    <title>Marc Brooker on leases</title>
    <dc:date>2019-02-08T14:18:15+00:00</dc:date>
    <link>https://twitter.com/MarcJBrooker/status/1093650148708691969</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good advice from Marc Brooker on using leases as a way to handle leader election in a distributed system: 'Leases are a nice primitive because they are easy to understand, easy (if subtle) to implement correctly, require very little co-ordination, optimistic, and don't require much load on the strongly consistent service.']]></description>
<dc:subject>leases primitives distributed-systems distcomp networking coding marc-brooker algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4945e87a8ceb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:primitives"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:marc-brooker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.benjojo.co.uk/post/eve-online-bgp-internet">
    <title>using BGP to compute best paths across the London Underground</title>
    <dc:date>2019-02-07T09:31:08+00:00</dc:date>
    <link>https://blog.benjojo.co.uk/post/eve-online-bgp-internet</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this is deeply silly, but also very impressive (via Tony Finch)]]></description>
<dc:subject>via:fanf bgp networking internet routing london-underground trains</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c84d01a61942/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bgp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:london-underground"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trains"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/">
    <title>Linkerd 2.0</title>
    <dc:date>2018-11-26T16:08:28+00:00</dc:date>
    <link>https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The 2.0 release of Linkerd brings two very significant changes. First, we’ve completely rewritten Linkerd to be orders of magnitude faster and smaller than Linkerd 1.x. Linkerd 2.0’s data plane is comprised of ultralight Rust proxies which consume around 10mb of RSS and have a p99 latency of <1ms. Linkerd’s minimalist control plane (written in Go) is similarly designed for speed and low resource footprint.

Second, with the 2.0 release, Linkerd moves beyond the service mesh model to be something not more, but less: Linkerd 2.0 at its core is a service sidecar, running on a single service without requiring cluster-wide installation. This means that if you’re a developer or service owner who doesn’t have access to the whole Kubernetes cluster, you can run Linkerd on your service and get:

Instant Grafana dashboards of your service’s success rates, latencies, and throughput;
A topology graph of incoming and outgoing dependencies;
A live view of requests being made to your service;
Improved, latency-aware load balancing;
… and much more.
</blockquote>

]]></description>
<dc:subject>linkerd mesh networking services architecture sidecars</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1d41240fa54d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkerd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mesh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sidecars"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/programming/comments/9wncor/httpoverquic_to_be_renamed_http3/">
    <title>HTTP-over-QUIC to be renamed HTTP/3</title>
    <dc:date>2018-11-14T11:27:31+00:00</dc:date>
    <link>https://www.reddit.com/r/programming/comments/9wncor/httpoverquic_to_be_renamed_http3/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Decent newsy comment thread about HTTP/3, QUIC, and how the modern internet treats IP protocols]]></description>
<dc:subject>ip protocols http http3 quic networking internet newsy</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0194d098183b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:newsy"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.hostedgraphite.com/2018/10/30/deadlines-lies-and-videotape-the-tale-of-a-grpc-bug/">
    <title>Deadlines, lies and videotape: The tale of a gRPC bug</title>
    <dc:date>2018-11-09T14:31:04+00:00</dc:date>
    <link>https://blog.hostedgraphite.com/2018/10/30/deadlines-lies-and-videotape-the-tale-of-a-grpc-bug/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[HostedGraphite decided to use gRPC as an internal inter-service protocol and ran into a basic protocol bug -- it does not default to using an application-level keepalive on the TCP channel so can block indefinitely if sending-side buffers fill up. Always use application-level keepalives and don't trust TCP]]></description>
<dc:subject>tcp protocols keepalive grpc rpc architecture networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed03b965998a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:keepalive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://triplebyte.com/blog/how-triplebyte-solved-its-office-wifi-problems">
    <title>How Triplebyte solved its office Wi-Fi problems</title>
    <dc:date>2018-09-27T09:10:23+00:00</dc:date>
    <link>https://triplebyte.com/blog/how-triplebyte-solved-its-office-wifi-problems</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is good general wi-fi infrastructure advice for home use too]]></description>
<dc:subject>internet networking wifi ethernet routers ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94b781f9c525/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethernet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.cncf.io/blog/2018/08/31/grpc-on-http-2-engineering-a-robust-high-performance-protocol/">
    <title>gRPC On HTTP/2: Engineering A Robust, High Performance Protocol</title>
    <dc:date>2018-09-06T15:57:30+00:00</dc:date>
    <link>https://www.cncf.io/blog/2018/08/31/grpc-on-http-2-engineering-a-robust-high-performance-protocol/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Decent writeup on how gRPC uses HTTP/2 efficiently]]></description>
<dc:subject>http2 grpc rpc networking http tcp protocols</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0c050c1f8551/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/clare_liguori/status/1034829325306978304">
    <title>How network clients need to participate in fault tolerance</title>
    <dc:date>2018-08-29T22:22:30+00:00</dc:date>
    <link>https://twitter.com/clare_liguori/status/1034829325306978304</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Top tips on best practices here:

<blockquote>Colm's thread on shuffle sharding reminded me of how important it is that clients participate in fault tolerance, and how frustrated I get when a client library *doesn't* do this by default in my application. Let's talk about some best practices!</blockquote>

Bottom line: use Hystrix :)]]></description>
<dc:subject>retries fault-tolerance networking tcp http exponential-backoff ip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6dfb8a6e0dc7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exponential-backoff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>