[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RAM] Tunneling overheads and fragmentation
[caught up, yay!]
On 21-jul-2007, at 16:40, Robin Whittle wrote:
Even then, I fear that in order to preserve both reachability and
efficiency (and any reachability problems which arise from
fragmentation), that hosts in all networks, including non-upgraded
networks, will need to adopt a somewhat lower MTU setting - for
all the packets they send.
That would assume that there is something that doesn't support the
"regular" MTU (in theory, there is no such thing, in practice: 1500
bytes) between the place the packets are encapsulated and the place
the packets are decapsulated.
I'm still operating under the assumption that both those places are
in ISP networks. Now obviously there are lots of places in ISP
networks that only support 1500-byte packets, but what would be a
better decision here: push out a reduced packet size EVERYWHERE which
we probably won't be able to raise any time soon, or require ISPs to
either:
1. Implement path MTU discovery correctly, or:
2. Make sure that all encapsulated packets travel over paths that
support at least 1500 byte + encapsulation sized packets
I wonder to what extent every possible application respects the
operating system's MTU.
The two are unrelated. Applications talk to transport protocols. The
most popular one, TCP, breaks large chunks of data into smaller
segments and coalesces multiple small chunks into larger segments.
UDP simply adds its header and hands over the packet to the IP layer.
The IP layer will fragment packets that are too large to be sent out
over the interface of choice and/or the packet's destination. The
only time there are problems (except of course from firewalls that
don't like fragmentation) is when the transport protocol or
application doesn't want fragmentation (DF=1) but the packet is
larger than the interface MTU. Not sure what happens then, except
that there is no way that a packet larger than the interface MTU is
sent in one piece.
I wonder if there are any widely
used applications, such as games, P2P programs etc. which are
hard-coded to assume a certain MTU which is close to, or right at,
the limit of what can safely be sent across most of the Net.
Mostly video streaming, although that's all quickly moving to TCP
these days. A common packet size here is 1450 bytes but I think
that's excluding 28 bytes IPv4 + UDP so the packets are really 1478
bytes.
I also remember seeing fragmented TCP traffic coming from DSL users.
Obviously some link didn't do 1500 bytes in the middle but rather
than use PMTUD the devices involved fragmented. I think DF wasn't set
in this case, but it could have been cleared by a router or other box
somewhere along the way. (I once implemented that myself when I got
dial-up service delivered over a tunnel that only supported a 576-
byte MTU.)
Perhaps, in an optimistic scenario, recognising that some packets
are to be encapsulated by ITRs, an ISP network could set up its
DHCP system or whatever it is which gives DSL modems their
parameters, to reduce the MTU and MSS settings sufficiently that
the ITR-applied encapsulation still results in packets which will
not be fragmented in most transit and border routers.
There are several MTU-related DHCP options but I'm not sure how
widely they are supported. Note by the way that ATM which is used for
both ADSL and DOCSIS (cable) supports MTUs much larger than 1500 bytes.
By the way, I'm currently working on this:
http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-01.txt
It doesn't directly address this issue but it allows for systems with
different MTUs to coexist on the same subnet so it becomes a lot
easier to deploy jumboframes.
This really needs to be done for all hosts in all networks - not
just hosts in networks which have been upgraded with ITRs and ETRs
etc.
Oh joy.
Doing path MTU discovery is probably easier, and note that if one
host in a TCP session has a reduced MTU, it will let the other know
during the three-way handshake so the unencumbered host won't send
packets that are too large.
Even if the host had its own ITFH
(Ingress Tunnel Function in Host) function, I don't see how the
operating system could tell application programs that there is one
MTU and MSS setting for packets going to some addresses and
another setting for packets going to other addresses.
Not a problem, path MTU discovery already does this today.
However, I see issues with hosts doing their own en/decapsulation:
that way, the locators are exposed to hosts and they are at risk for
becoming just as unrenumberable as IP addresses today.
The only way to make sure that you can renumber easily is if there
are no firewall rules looking at locators. And the only way that will
happen is if the relationship between location and identity is strong
enough that spoofing it is not a viable attack vector. Concretely:
today the routing system is unspoofable enough that people filter on
IP addresses. The routing system is run by service providers who
generally aren't in the business of attacking people. But if a
locator mapping system is also open to end-users, it may be possible
for attacks to use this path and people won't be happy to filter on
just identifiers, just like they aren't happy to filter on just DNS
names today. So either the ISPs must run it or there must be a heavy
layer of magic security dust.
UDP encapsulation, as used by LISP and I think eFIT-APT, involves
20 bytes for the IP header, 8 bytes for the UDP header and some
number of bytes, such as 4, for extra stuff
What exactly was the reason for UDP encapsulation again? I think Dino
said something about load balancing and firewalling. I'm not buying
that: you can load balance on the destination IP address and anyone
running firewalls in the middle of the routing system is best served
with a single deny any any rule.
This is where IPv6's long addresses and headers become really
ugly. There would be 40 bytes for IP-in-IP and 52 for basic UDP
encapsulation.
We really need bigger packets to offset the ever-increasing overhead.
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram