Hi, Fred,
On 6/26/2013 8:42 AM, Templin, Fred L wrote:
Hi Joe,
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Tuesday, June 25, 2013 8:10 PM
To: Templin, Fred L
Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area
Subject: Re: [Int-area] New Version Notification for draft-bonica-
intarea-gre-mtu-00.txt
Hi, Fred,
On 6/25/2013 3:32 PM, Templin, Fred L wrote:
Hi Joe,
The constraint you seem to be missing is that RFC2460 only requires
IPv6 nodes to reassemble as much as 1500 bytes.
Right; sorry for not noticing that further. Had IPv4 on the brain.
OK, but IPv4 also has a limit of minMRU=576. So, we have:
IPv4 minMTU = 576 (*)
IPv4 minMRU = 576
IPv6 minMTU = 1280
IPv6 minMRU = 1500
(*) Even though the specs say that IPv4 minMTU = 68, everyone
seems to be saying that for practical purposes it is now 576.
There needs to be a difference between the minMTU and the minMRU; if
not, then IP-in-IP tunnels will never succeed without a separate
fragmentation and reassembly layer - and although SEAL provides that, we
currently do not require anything like that for X-in-X encapsulation.
...
Granted, my algorithm is asking GRE egress tunnel endpoints to
configure a reassembly buffer size of 1500 *plus* the tunnel
encapsulation overhead, which is more than RFC2460 ensures.
Agreed.
Right. So, then the fragmentation threshold for GRE over IPv6
needs to be (1500 - HLEN) instead of 1500.
...
Also think about it this way. Why should the tunnel work hard to
pass a packet that is larger than 1500 bytes and also larger than
the minimum link MTU within the tunneled path when the source could
instead adjust the size of the packets it is sending downward?
That's not a good argument. I agree that all that need be satisfied is
the largest reassembled IPv6 packet, but not that we should assume the
source can or will adjust downward - if that were the case, you could
ignore the overhead of GRE and just claim that the MTU is 1280.
In my lab, my implementation sends a single packet for packet
sizes no larger than (1280 - HLEN). For packets that are larger
than (1280 - HLEN) but no larger than 1500, it fragments the
packet into two pieces and sends both pieces to the tunnel far
end which then needs to reassemble. But, reassembly will be
delayed by the inter-packet delay plus the time it takes to
run the reassembly routine, and the delay is measurable. So,
we really only want to use frag/reass when we absolutely have to.
My view is that discovering the path MTU for the purposes of avoiding
frag/reassembly is either necessary or an optimization (such as you
mention above, to avoid delays and conserve resources). That's in
keeping with the "work first, optimize later" approach of the Internet.
So frag/reassemble unless you CANNOT. Send too-big messages back to help
the system optimize. But never deliberately drop anything you could have
sent with frag/reassembly.
Joe
Thanks - Fred
[email protected]
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
