cwinfo/yggdrasil-network.github.io
5
0
Fork 0
mirror of https://github.com/cwinfo/yggdrasil-network.github.io.git synced 2024-11-09 16:50:31 +00:00
Code Releases Activity

Update MTU post

Browse Source
This commit is contained in:
Neil Alexander 2018-07-13 10:28:15 +01:00
parent 6a8276ee2d
commit 71e6a5088c
No known key found for this signature in database
GPG Key ID: A02A2019A2BB0944
1 changed files with 9 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
_posts/2018-07-13-about-mtu.md
View File

@ -17,9 +17,8 @@ In fact, this is not a mistake. It is very deliberate.
The MTU is a configurable option which determines how big a packet should be
before you should break out into a new packet. With every packet, the IP headers
and other possible headers (i.e. from TCP or UDP) have to be repeated.
In addition to that, the operating system maintains a link MTU setting for each
and other possible headers (i.e. from TCP or UDP) have to be repeated. In
addition to that, the operating system maintains a link MTU setting for each
network adapter - effectively a value that says "packets smaller than this
number of bytes are safe to send on this link in one piece". Any larger than
that and the operating system will have to fragment the packet down into smaller
@ -41,7 +40,7 @@ headers are better. Using an MTU of 65535 over 1500 packs in almost 43 times
more data before the next set of headers. That's almost 840 bytes saved from IP
headers alone over 65535 bytes! But sending a 65535 byte Yggdrasil packet over a
link with an MTU of 1500 would require the packet to be fragmented 43 times,
right? Well, it would if we were using a stateless protocol like UDP.
right?
Instead, Yggdrasil uses TCP connections for peerings. This not only allows us to
take advantage of SOCKS proxies in a way that we cannot with UDP, but it also
@ -72,8 +71,8 @@ times less - therefore there are far less control messages from the inner
connection which may be affected or amplified by retransmission. This helps to
stabilise performance on the inner TCP connections.
There are also some other clever things taking place at the Yggdrasil TCP layer
- in particular, LIFO queues are used for session traffic, which results in
There are also some other clever things taking place at the Yggdrasil TCP layer.
In particular, LIFO queues are used for session traffic, which results in
reordering at almost the first sign of any congestion on the encapsulating link.
TCP very eagerly backs off in this instance, which helps to deal with real
congestion on the link in a sane manner.
@ -109,12 +108,10 @@ en-route (like a router) can send back an ICMPv6 `Packet Too Big` message to the
sender, signifying that the packet that you sent exceeds the largest supported
packet size (effectively an upstream link MTU). The sending node can then
fragment the packet and resend it in smaller chunks so that it matches that
lower MTU on the path.
Yggdrasil takes advantage of this behaviour by generating `Packet Too Big`
control messages and sending them back to the TUN/TAP adapter when it detects
that you have tried to send a packet across an Yggdrasil session that is larger
than the agreed MTU.
lower MTU on the path. Yggdrasil takes advantage of this behaviour by generating
`Packet Too Big` control messages and sending them back to the TUN/TAP adapter
when it detects that you have tried to send a packet across an Yggdrasil session
that is larger than the agreed MTU.
This causes the operating system to fragment the packets down to the MTU size
supported by the session and resend them. In addition, the operating system