Skip to content
By using Twitter’s services you agree to our Cookies Use. We and our partners operate globally and use cookies, including for analytics, personalisation, and ads.

This is the legacy version of twitter.com. We will be shutting it down on June 1, 2020. Please switch to a supported browser, or disable the extension which masks your browser. You can see a list of supported browsers in our Help Center.

  • Home Home Home, current page.
  • About

Saved searches

  • Remove
  • In this conversation
    Verified accountProtected Tweets @
Suggested users
  • Verified accountProtected Tweets @
  • Verified accountProtected Tweets @
  • Language: English
    • Bahasa Indonesia
    • Bahasa Melayu
    • Català
    • Čeština
    • Dansk
    • Deutsch
    • English UK
    • Español
    • Filipino
    • Français
    • Hrvatski
    • Italiano
    • Magyar
    • Nederlands
    • Norsk
    • Polski
    • Português
    • Română
    • Slovenčina
    • Suomi
    • Svenska
    • Tiếng Việt
    • Türkçe
    • Ελληνικά
    • Български език
    • Русский
    • Српски
    • Українська мова
    • עִבְרִית
    • العربية
    • فارسی
    • मराठी
    • हिन्दी
    • বাংলা
    • ગુજરાતી
    • தமிழ்
    • ಕನ್ನಡ
    • ภาษาไทย
    • 한국어
    • 日本語
    • 简体中文
    • 繁體中文
  • Have an account? Log in
    Have an account?
    · Forgot password?

    New to Twitter?
    Sign up
colmmacc's profile
Colm MacCárthaigh
Colm MacCárthaigh
Colm MacCárthaigh
@colmmacc

Tweets

Colm MacCárthaigh

@colmmacc

AWS, Apache, Crypto, Irish Music, Haiku, Photography

Seattle
notesfromthesound.com
Joined April 2008

Tweets

  • © 2020 Twitter
  • About
  • Help Center
  • Terms
  • Privacy policy
  • Imprint
  • Cookies
  • Ads info
Dismiss
Previous
Next

Go to a person's profile

Saved searches

  • Remove
  • In this conversation
    Verified accountProtected Tweets @
Suggested users
  • Verified accountProtected Tweets @
  • Verified accountProtected Tweets @

Promote this Tweet

Block

  • Tweet with a location

    You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more

    Your lists

    Create a new list


    Under 100 characters, optional

    Privacy

    Copy link to Tweet

    Embed this Tweet

    Embed this Video

    Add this Tweet to your website by copying the code below. Learn more

    Add this video to your website by copying the code below. Learn more

    Hmm, there was a problem reaching the server.

    By embedding Twitter content in your website or app, you are agreeing to the Twitter Developer Agreement and Developer Policy.

    Preview

    Why you're seeing this ad

    Log in to Twitter

    · Forgot password?
    Don't have an account? Sign up »

    Sign up for Twitter

    Not on Twitter? Sign up, tune into the things you care about, and get updates as they happen.

    Sign up
    Have an account? Log in »

    Two-way (sending and receiving) short codes:

    Country Code For customers of
    United States 40404 (any)
    Canada 21212 (any)
    United Kingdom 86444 Vodafone, Orange, 3, O2
    Brazil 40404 Nextel, TIM
    Haiti 40404 Digicel, Voila
    Ireland 51210 Vodafone, O2
    India 53000 Bharti Airtel, Videocon, Reliance
    Indonesia 89887 AXIS, 3, Telkomsel, Indosat, XL Axiata
    Italy 4880804 Wind
    3424486444 Vodafone
    » See SMS short codes for other countries

    Confirmation

     

    Welcome home!

    This timeline is where you’ll spend most of your time, getting instant updates about what matters to you.

    Tweets not working for you?

    Hover over the profile pic and click the Following button to unfollow any account.

    Say a lot with a little

    When you see a Tweet you love, tap the heart — it lets the person who wrote it know you shared the love.

    Spread the word

    The fastest way to share someone else’s Tweet with your followers is with a Retweet. Tap the icon to send it instantly.

    Join the conversation

    Add your thoughts about any Tweet with a Reply. Find a topic you’re passionate about, and jump right in.

    Learn the latest

    Get instant insight into what people are talking about now.

    Get more of what you love

    Follow more accounts to get instant updates about topics you care about.

    Find what's happening

    See the latest conversations about any topic instantly.

    Never miss a Moment

    Catch up instantly on the best stories happening as they unfold.

    1. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      If you know anything about UDP it's that it's a "Fire and Forget" protocol, it can be lossy. From the perspective of an application, you send a packet, and it gets to the other end or it doesn't. If you want reliability, you have to retry yourself or have some kind of fallback.

      1 reply 0 retweets 8 likes
      Show this thread
    2. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      UDP is a "layer 4" protocol. It runs on top of the Internet Protocol .. which is a "layer 3" protocol. Scarequotes because the OSI layering model is insanely wrong and confusing in modern contexts.

      2 replies 0 retweets 27 likes
      Show this thread
    3. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      Here's what an IP header looks like. Study it. There will be an exam.pic.twitter.com/Ozzri8uvoe

      1 reply 0 retweets 11 likes
      Show this thread
    4. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      And here's a UDP header ...pic.twitter.com/dmAJqYul1l

      1 reply 0 retweets 5 likes
      Show this thread
    5. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      O.k. so back to DNS for a bit. So DNS is a request-response protocol. Requests are like "What's the IP address for http://www.amazon.com " and responses are like "here's the IP addresses for http://www.amazon.com ".

      1 reply 0 retweets 4 likes
      Show this thread
    6. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      IP-based networks have limits for how much data they can handle in a single packet. Now if you study the IP and UDP headers, you'll that they both have "length" fields, and these fields are 16-bits. So you'd think that we should be able to send up to 65535 bytes in a packet.

      1 reply 0 retweets 4 likes
      Show this thread
    7. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      That would be *way* too simple. Historically, the size of the packets we could send has actually limited by the underlying technology. Ethernet is often limited to 1500 bytes per packet, or up to 9,000 if you enable a special mode called "Jumboframes".

      2 replies 0 retweets 6 likes
      Show this thread
    8. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      Satellites, Radio systems, things like POS (Packet over Sonet), ATM, DSL, Token Ring, and more. These could all have different MTUs that actually limit how much data you could send or receive in one packet.

      2 replies 0 retweets 3 likes
      Show this thread
    9. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      The underlying reasons are usually esoteric, like how long you're allowed to send signals for at the electrical level. Anyway, main point: different mediums = different MTUs. MTU stands for "Maximum Transmission Unit".

      1 reply 0 retweets 6 likes
      Show this thread
    10. Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      Different networks can be linked though, and you can only get a packet through all of the links if it's <= the lowest MTU of any of the links, so you need a way to discover the whole paths MTU. We'll come back to this, I promise. Placeholder for now.

      1 reply 0 retweets 7 likes
      Show this thread
      Colm MacCárthaigh‏ @colmmacc Feb 4
      • Report Tweet
      • Report NetzDG Violation

      There's also a minimum MTU that *any* IP network has to support. It's 576 bytes, everything has to handle that. So DNS traditionally takes a shortcut around path MTU discovery and just says "lets use UDP and just stick to the minimum".

      11:07 AM - 4 Feb 2020
      • 6 Likes
      • Yasuhiro Morishita Suraj Nath 🌻 Jona Christopher Sahnwaldt Hiren Panchasara Chris Sylcox (home version) Hella
      2 replies 0 retweets 6 likes
        1. New conversation
        2. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          So it says "Requests and responses have to be be smaller than 512 bytes", which when you add the 20 byte UDP header, and the 20 byte IP header, leaves 24 bytes of space for IP options. So it all fits.

          2 replies 0 retweets 5 likes
          Show this thread
        3. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Fitting a DNS request into 512 bytes isn't too hard, it's why DNS has a limit on how big domain names can be. But since humans have to type them sometimes, long ones would always be a pain. No big deal.

          1 reply 0 retweets 6 likes
          Show this thread
        4. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Fitting an entire DNS response into 512 bytes was easy to start out with .. just a few IPs, but it's gotten harder over time. Email, Anti-Spam measures, IPv6, and DNSSEC (which is garbage, but that's a different topic) have all pushed the size of responses up and up.

          2 replies 0 retweets 14 likes
          Show this thread
        5. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          DNS has a built in mechanism to handle this, called truncation. If the response that a server needs to send is too big, it sends as much as it can and then marks a bit that means "This response was truncated".

          1 reply 0 retweets 5 likes
          Show this thread
        6. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          The requester then retries the request over TCP, instead of UDP. Because TCP is intended for "bigger" messages. Two problems with this: sometimes people block TCP DNS without realizing, and TCP *still* has to figure out what the path MTU is.

          1 reply 1 retweet 12 likes
          Show this thread
        7. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          So here's how path MTU discovery works for TCP. The TCP connection starts with its best guess of what the MTU is, and calculates a "Maximum Segment Size" from this. This isn't the TCP window. It's the maximum data that TCP will put in a single packet.

          1 reply 0 retweets 4 likes
          Show this thread
        8. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          The client sends SYN, the server sends SYN|ACK, usual TCP handshake. These packets are small and rarely trigger path MTU discovery. For DNS; the request packet will be small too and likely won't trigger anything.

          3 replies 0 retweets 5 likes
          Show this thread
        9. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          But when the server sends the response, that will be big, maybe too big. But it sends it out anyway. That packet gets as far as it gets. If it gets to a link that has a smaller MTU, that link sends back an Internet Control Messsage Protocol (ICMP) message that says "MTU exceeded"

          2 replies 0 retweets 4 likes
          Show this thread
        10. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          It sends to this back to the sender ... the DNS server in this case. And so the sender has a clue what even triggered the error, it includes the top part of the packet that triggered the error.

          1 reply 0 retweets 5 likes
          Show this thread
        11. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Basically the server tried to send a long letter by relay mail, and got to a relay that only has small envelopes. So that relay tore the original letter in half and send back that half in a small envelope saying "I only have small envelopes, so try again, good luck".

          1 reply 1 retweet 9 likes
          Show this thread
        12. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          O.k. so now the sender knows a new lower MTU for that path, and it caches it. The kernel keeps a cache of all MTUs it knows for all destinations. Now it recomputes a new TCP MSS and resends the data but in smaller packets. Yay! This is part of why TCP is reliable.

          1 reply 0 retweets 5 likes
          Show this thread
        13. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          This whole process takes a damn while though; the client had to fall back to TCP, and then the path mtu discovery had to happen, and finally the client gets the response ... as long as TCP wasn't blocked to begin with.

          2 replies 0 retweets 4 likes
          Show this thread
        14. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          So the DNS folks are like "Wouldn't it be great if we could just send large responses over UDP". And it's true. It would. And so it was invented, as part of EDNS0, a general extension mechanism for DNS.

          1 reply 0 retweets 7 likes
          Show this thread
        15. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          With EDNS0 enabled, the client can include a little fake sort of record that says "hey, I support EDNS0, and also I'm good if you send me large UDP responses ... up to 4,000 bytes, say".

          1 reply 0 retweets 5 likes
          Show this thread
        16. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          If a server also supports EDNS0, it can just send larger UDP responses, rather than truncating and falling back to TCP. We're now nearing the top of the rollercoaster.

          1 reply 0 retweets 6 likes
          Show this thread
        17. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          What happens when we send a large UDP response? Well as we saw earlier the UDP and IP headers both have length fields. The way it works out is that fragmentation actually happens at the IP layer ...

          2 replies 0 retweets 3 likes
          Show this thread
        18. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Suppose we try to send a 4,000 byte UDP datagram over a 1500 byte MTU IP network, what happens is that it gets broken into 3 IP "fragments". The first contains the first part of the UDP message, including the UDP header itself, and the next packets follow on from there.

          1 reply 0 retweets 4 likes
          Show this thread
        19. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Each fragment will have the same IP "identification" header (IPID) and different fragment offsets. It's the kernel's job to wait for all of the fragments to show up and pass them on to an application.

          1 reply 0 retweets 4 likes
          Show this thread
        20. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Path MTU discovery works the same as with TCP. If the first fragment is too big, the sender will get an error. But since applications usually don't retry UDP responses, it can also just show up as that message being entirely dropped.

          1 reply 0 retweets 4 likes
          Show this thread
        21. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          It also means that fragments of the message look strange to many parts of the network, like firewalls and switches. UDP packets without UDP headers! How are they supposed to know whether the packet is allowed or not? How is flow-switching supposed to work? The internet shrugs.

          1 reply 0 retweets 8 likes
          Show this thread
        22. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          We often end up building in the ability to relate these packets to one another in many places, and since that's expensive, they also have to be rate-limited. It's deeply messy.

          1 reply 0 retweets 3 likes
          Show this thread
        23. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          That's what's going on down there though, and understanding that full picture is key to diagnosing some common network mysteries. O.k. I have a team meeting now, more later!

          1 reply 0 retweets 8 likes
          Show this thread
        24. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Meeting postponed! o.k. so what happens when the DNS server sends a 4K response and the MTU is 1200 bytes? Well the DNS server gets the error, and it fixes the *next* response, but that first is lost. Super annoying. So the client has to retry, but then it works.

          2 replies 0 retweets 8 likes
          Show this thread
        25. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Some more fun: network paths don't have to be symmetrical, so MTUs don't either. If the client needs to send a large amount of data, this whole process happens for them too. A sender and a receiver can legitimately end up with different limits towards one another.

          2 replies 1 retweet 5 likes
          Show this thread
        26. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          Because MTU discovery depends on state, and on ICMP messages being allowed, some folks do something like "MSS clamping" where for TCP they have the network actually meddle with the TCP connection (a little) to offer a different MSS to the other end.

          2 replies 0 retweets 5 likes
          Show this thread
        27. Colm MacCárthaigh‏ @colmmacc Feb 4
          • Report Tweet
          • Report NetzDG Violation

          It is surprising that the Internet works.

          9 replies 27 retweets 157 likes
          Show this thread
        28. End of conversation

      Loading seems to be taking a while.

      Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

        Promoted Tweet

        false

        • © 2020 Twitter
        • About
        • Help Center
        • Terms
        • Privacy policy
        • Imprint
        • Cookies
        • Ads info