Re: [RAM] Tunneling overheads and fragmentation

[Marshall Eubanks <[e-mail]>]

On Jul 21, 2007, at 10:40 AM, Robin Whittle wrote:

> I just read:
>
>   IP Encapsulation within IP
>   http://tools.ietf.org/html/rfc2003
>
>   Generic Routing Encapsulation (GRE)
>   http://tools.ietf.org/html/rfc2784
>
>   MTU and Fragmentation Issues with In-the-Network Tunneling
>   http://tools.ietf.org/html/rfc4459
>
> and the first few pages of:
>
>   Packetization Layer Path MTU Discovery
>   http://tools.ietf.org/html/rfc4821
>
>
> I have added:
>
>   IPv4 Reassembly Errors at High Data Rates
>   http://tools.ietf.org/html/draft-heffner-frag-harmful-05
>
>     IPv4 fragmentation is not sufficiently robust for use under
>     some conditions in today's Internet.  At high data rates, the

I would change "some" to "most", at least as a practical matter.

Regards
Marshall

>     16-bit IP identification field is not large enough to prevent
>     frequent incorrectly assembled IP fragments, and the TCP and
>     UDP checksums are insufficient to prevent the resulting
>     corrupted datagrams from being delivered to higher protocol
>     layers. ...
>
> to the To-Do list:
>
>   http://www.firstpr.com.au/ip/ivip/to-do/	
>
>
> Gert's response and the responses of others makes me think that
> these proposals - LISP-NERD/CONS, eFIT-APT and Ivip - cannot
> succeed in their goal of requiring no changes to hosts, except
> perhaps where host packet sizes are always controlled by DHCP
> settings.
>
> 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.
>
> I wonder to what extent every possible application respects the
> operating system's MTU.  Do operating systems simply refuse to
> send any packet which is longer?  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.
>
> 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.  I am
> assuming a single level of encapsulation is all that is required.
>
> Then, the hosts could generate marginally shorter packets - for
> all packets sent, including those to non-mapped addresses and the
> packets which need to be encapsulated will get to the other end
> without any fragmentation.
>
> 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.
>
> Because there are no prospects of ramping BGP up to coping with
> millions of advertised prefixes, every vaguely practical,
> potentially incrementally deployable proposal for the routing and
> addressing crisis involves tunneling.
>
> I think the most likely way this fragmentation and MTU problem is
> going to be solved is to back off the MTU and MSS settings on all
> hosts, for all packets.  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.
>
> So unless someone figures out a totally different system, the only
> way out of the current crisis will be to force all application
> software on every host on the Net to generate somewhat shorter
> packets.
>
> If so, then I think this would be an argument in favor of the
> shortest possible encapsulation system, which I think for IPv4 is
> the IP-in-IP technique (RFC 3003), which adds 20 bytes.
>
> 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 which presumably
> precedes the encapsulated packet itself.  For instance 32 bits of
> length and other guff and a 32 bit address of the ITR, to identify
> the ITR if my proposal for "outer SA = inner SA" is adopted.  So
> that is 32 bytes of overhead.
>
> 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.
>
> In my previous message:
>     http://www1.ietf.org/mail-archive/web/ram/current/msg01729.html
>
> I suggested a second reason (in addition to the original one of
> making it easy to stop ETRs being used as a back-door around
> filtering) for using "outer SA = inner SA": to allow ICMP messages
> to go straight back to the sending host.  This would absolve the
> ITR of the problematic, onerous or impossible task of receiving
> ICMP messages coming back to it, and figuring out which sending
> host to send back some ICMP message to.  (See RFC 4459.)
>
> As far as I know, "outer SA = inner SA" is at odds with standard
> practice, but I think it has some important benefits.
>
>   - Robin
>
>
> _______________________________________________
> RAM mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ram


_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram