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.
-
Show this thread
-
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread -
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 likesShow this thread
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.
-
-
It is surprising that the Internet works.
9 replies 27 retweets 157 likesShow this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Replying to @colmmacc
Random: At some point I may end up strangling the next “security expert” that tells me I should block ICMP within an internal network ICMP, and ping, are pretty much essential lifesavers when debugging weird network routing issues, and monitoring network health in general.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.