Re: [RAM] Tunneling overheads and fragmentation

[Robin Whittle <rw at firstpr.com.au>]

Gert Doering wrote:

RW> For instance, if all provider and transit routers happily handle
RW> packets significantly longer than whatever hosts normally produce
RW> (say 1500 bytes) then adding the encapsulation won't lead to any
RW> fragmentation.  Is this a reasonable assumption?

> No.  As of today, too many links and routers still have issues handling
> more than 1500 bytes of IP packets (like "most FastEthernet interfaces on 
> Cisco routers", which is still considered "high bandwidth" over here).

In the thread "New LISP draft available ..." (msg01756), Dino wrote:

> All tunneling protocols have this problem. But I believe in
> practice it's not a real issue. Hosts send no larger, typically
> than 1500 byte packets and routers are now more and more on 9K
> MTU links.

These two statements don't seem to be reconcilable.

The further the ITRs and ETRs are from the sending and receiving
hosts, the less routers will be in the tunnel part of the path -
and the larger and newer those routers are likely to be, I guess.

For scaling purposes - to distribute the encapsulation and
decapsulation workload over more devices - we want to have more
ITRs and ETRs, which means they will be closer to the hosts (or
Customer Edge routers).  This is especially true for the ETR,
because as I argue in:

http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-14.1.2.5

ETRs must handle packets from ITRs in the same network

I think that packets to all LISP/APT/Ivip-mapped addresses sent by
hosts in the same network in which the hosts/CE-routers with the
destination LISP/APT/Ivip-mapped addresses reside . . . should be
forwarded via an ITR tunneling the packets to the right ETR,
rather than by the local routing system.  Only ITRs are likely to
be up-to-date on where the packets should be delivered to.

Otherwise (relying on the local routing system to forward raw
packets to the destination with the LISP/APT/Ivip-mapped address),
the local routing system has to have ITR functionality, which is
simple enough in Ivip - follow the database mapping - but very
complex for the other proposals.  I doubt the local routing system
could respond quickly enough to Ivip mapping changes, and I doubt
it could implement the functionality of LISP/eFIT-APT ITRs.

If this argument is accepted, then ETRs will be very close to the
destination, probably with a direct link - since they won't be
relying on the local routing system to get raw decapsulated
packets to the destination (unless they use a tunnel to the CE
router or the LISP/APT/Ivip-mapped host, which requires software
in the latter).

For scaling (load sharing) reasons, we probably want as many ITRs
as possible, which means they will be closer to the sending hosts
and that the larger encapsulated packets will flow through more
internal routers, which may be older (I guess) with lower
capacities and perhaps lower MTU sizes.

Gert also wrote:

RW> What about routers in end-user networks, or CE routers of
RW> providers?

> Even worse, due to DSL encapsulation you already end up with an
> IP MTU of 1492 bytes or less.

Putting an ITR function in a DSL modem (or HFC cable modem) NAT
device will require that the device use DHCP to give all hosts on
the private network a lower MTU so it can safely encapsulate the
packets which are addressed to mapped addresses, and not run into
MTU problems on its own DSL/cable link.

As far as I can see, this will lead to all application programs
being limited to somewhat lower packet lengths, unless somehow the
application (and operating system?) can be sure the packet is not
affected by LISP/APT/Ivip etc. mapping, and therefore is not going
to be encapsulated.

Is there a WG working on MTU issues, path MTU discovery etc.?

I have added this:

  IPv6 Extensions for Multi-MTU Subnets

    tools.ietf.org/html/draft-van-beijnum-multi-mtu-00

to my To-Do reading list: http://www.firstpr.com.au/ip/ivip/to-do/


 - Robin


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram