Hi, Carlos,
On 6/2/2013 12:22 PM, Carlos Pignataro (cpignata) wrote:
Joe,
On May 29, 2013, at 4:31 PM, Joe Touch <[email protected]
<mailto:[email protected]>> wrote:
...
I agree; my general recommendation has always been "the egress should
always clean up any mess created by an ingress" - which means using
"outer" fragmentation rather than "inner".
Why do you characterize this as a "mess"?
The ingress is creating a situation that takes work to correct (the
"mess" I refer to).
A. Using outer fragmentation places that work at the egress.
B. Using inner fragmentation pushes that work to the destination.
Note that fragmentation is a lot cheaper (less work) than reassembly. So
(A) makes it easy for routers to support GRE more cost-effectively, but
drains things like my iPhone battery as a result.
I don't like that optimization. If you make a mess, IMO you should clean
it up.
> Thinking of the tunnel as a
logical link with its own logical link MTU (LMTU), and this link is
unwilling/incapable of performing fragmentation and reassembly at its
"data-link",
There's a *big* difference between incapable and unwilling.
Incapable is fine - drop and send the ICMP.
Unwilling isn't a reason to skip the hard work.
then the appropriate behavior would be:
* If the incoming IPv4 datagram has DF=1, drop and send a PTB back; and
* if the incoming IPv4 datagram has DF=0, then fragment it and send it
over the link.
What's different?
It's exactly the difference between incapable and unwilling.
Here's the difference for GRE:
- GRE adds N bytes total (GRE header + IP header)
- GRE over IP supports 65536-byte packets
So if a packet arrives that is smaller than 65536-N, IMO GRE ought to
fragment and reassemble it.
If a packet arrives that is larger than that, then GRE *cannot* tunnel
it, and *MUST* drop it and sent a PTB.
I.e., only 65536 is "too big". Everything else is just whining about
"bigger than I want it to be" ;-)
Yes, this can cause repeated frag/reassembly, but the alternative is
to shift work to the end host, which I think is inappropriate.
I do not understand why it is "inappropriate" -- when thinking of the
tunnel as a link.
See above.
There is also a potential mischaracterization when you say "shift work
to the end host", because that can lead to assumptions that there is "a
single" end host (singular). In the case of a p2p tunnel, the challenge
is that there is a single pair of endpoints in the tunnel, but a
multitude of hosts behind and before them. A different view would be
that it's more efficient to distribute reassembly to many endpoints
instead of attacking the tunnel tailend and making it work on behalf of
many hosts/
It would be an attack, except that you're talking about a tunnel. A
tunnel is an ingress and an egress. Are you suggesting that making an
egress do its job is an "attack"?
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
