Iljitsch van Beijnum wrote:
On 25 okt 2003, at 2:51, Fred Templin wrote:
General comment - it would be nice if folks would reveiw and comment on my drafts: http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt
Ok, the second one first:
As far as I can tell, not being someone who builds routers, some of the mechanisms outlined here are problematic. For instance, determining whether the IP packet that carries a tunneled packet was fragmented means transferring information from one place in the architecture (reception and reassembly of IP packets) to another (handling protocol 41).
(We are talking here about the specific instance of IPv4 used as a link-layer
for IPv6.) Your point about instrumenting the IPv4 reassembly code is well
taken. But, this is just one option and perhaps not the best for all architectues.
For example, Linux offers a "packet socket" abstraction ("man 7 packet")
whereby an application can capture selected L2 packets based on filters.
It is a rather trivial thing to write a Linux packet socket filter that captures
all IPv4 packets with fragment headers for ip-proto-41 w/o having to touch
a line of kernel code. The only arguement then becomes one of performance,
since ip-proto-41 fragmented packets would be handled at the application
level. But, the protocol is designed to naturally minimize the number of
fragmented packets for ip-proto-41 so fast-path processing is not necessary.
Another: doing a router sollicitation triggered by wanting to transmit a packet of a certain size is not a good thing.
You've gotten wires crossed between Method 1 (section 3.3.1) and Method 2
(section 3.2) in my draft. Method 1 uses fragmentation sensing in the receiver
as the method for detecting path MTU changes and does not require the
encapsulator to send an RS triggered by wanting to send a packet of a certain
size. In the fragmentation sensing method, each data packet also serves as a
probe packet w/o having to introduce any additional messages. (Method 2
does suggest on-demand probing based on the arrival of large packets, but it
is intended only for those circumstances in which the fragmentation-sensing
scheme is not supported.)
But why bother in the first place?
Presonally, I would happily let my tunnel packets be fragmented as this way I don't incur a reduced MTU when using a tunnel.
Yes, *you* might be happy about letting your tunnel packets be fragmented, but would the *network* be happy about it? Certainly not. A quick read of "Fragmentation Considered Harmful" and "Beyond Folklore: Observations on Fragmented Traffic" should easily convince you of this. See:
http://research.compaq.com/wrl/techreports/abstracts/87.3.html http://www.caida.org/outreach/papers/2002/Frag/
Sure, this costs extra CPU time for the tunnel endpoints but in most cases this isn't a problem.
See the above documents. It isn't so much the CPU time for the tunnel
endpoints we are concerned with as the case of fragments lost due to
congestion which results in a loss unit (a packet fragment) that is smaller
than the retransmission unit (a packet). So, I take back my statement above
that "you" might be happy about letting your tunneled packets be fragmented
since the original source of the large packets will also suffer in the long run.
And when it is, the tunnel endpoints should be able to do PMTUD over the tunnel.
IPv4 PMTUD you mean? If so, please see the second paragraph in the introduction of my document for why this is undesireable in terms of efficiency and robustness.
And if that doesn't work, it's always possible to configure a smaller MTU.
Well, the smallest static MTU we can assign for IPv6-in-IPv4 tunnels is 1280 bytes, since 1280 is the min MTU for IPv6 interfaces. Even at that size, however, it is still possible that we might encounter IPv4 paths that will fragment the 1280byte packets due to, e.g., too many nested layers of encapsulation.
Don't forget that tunnels are typically pretty static so once everything is set up, there shouldn't be too many surprises.
The only static thing about the tunnels is the endpoints. The intervening IPv4 path may be arbitrarily long and dynamically fluctuating. That's why path MTU discovery can never be a once-and-done deal but must be continuous throughout the tunnel's operational lifetime.
I think this draft is solving a non-problem.
Please re-read and reconsider in light of the above.
Fred [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
