|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: I-D on operational MTU/fragmentation issues in tunneling
Stephen J. Wilcox wrote: On Thu, 14 Oct 2004, Joe Maimon wrote:A mix of schemes is needed. Some inband to the protocol conversation at hand and some not. Should one fail negotiation can still happen. In most cases traffic should still flow. I think the DF bit is a mistake and should not be used, except when probing with multiple packets on the wire. I think giving vendors a free pass on bad fragmentation performance is also a problem. Nothing that couldnt have been solved with the ooddles of cheaply available memory we have now. And by that I mean the vendors who consistently shipped routers that had only performance resources for bare bones routing. (OT Rant: The price margin of the routers being high enough that doubling the shipped memory load and enabling upgrades to limits comparably available to popular cheap computing equipment out there should not have broke the bank on these routers. There really was no excuse for 10K equipment coming in with a tenth of available computing resources that can be had at 1K. It boggles the mind the free pass they got on that. Saying performance is only required of the ASICS that switch was incredibly short sighted -- and selfish) (OT Rant #2: The whole firewall is not a router -- merely a copout because all these routers turn out to be wimps doing anything not limited to switching packets from one interface to another. The best place to handle policies and security detection for packets is where they are already being handled -- the router. ANd the reward for the copout? Big bucks for commodity computers with mediocre software.)(OT #3: How about a firewall protocol to exchange return traffic information between a set of firewalls so that assymetricity works again and firewalling can be done at the SP level. Does such a thing exist and if so who supports it) How about some more tcp or ip options so that machines can tell each other what packet sizes are actually coming in, fragmented or not? No dropping of packets. The larger they are when they come in the better. Any protocol that detects duplicate data can probe with multiple packets on the wire. Must be better for slow start, exponential back-off model. -- Inband How about a UDP port designated for IP packets with these options and magic cookie values to prevent spoofing? -- Completely outband Easy enough so that firewall vendors will have that on by default. How about an additional ICMP type dedicated precisely for this? "Packet was sent fragmented, to avoid this lower sending packet size to X". Kind of the opposite of Frag needed but DF set message.If this fails to work, well we have more fragments. Much better than having stalled traffic. -- a little different than current algorithm of drop first notify later It seem everyone keeps trying to figure out how to fix the implementation of PMTUD or to work around it. Perhaps a new solution will gain enough traction that the current mechanism will become obsolete. Problem solved. Add in some algorithm fixes as mentioned for the broken PMTUD of today and conversing hosts should have more tools than they can use to discover and take maximum advantage of pmtu, OR in the alternative, still exchange network traffic. Much better than a single mechanism for detecting PMTU which if fails can cause a blackhole of your packets. If we ever want to aggressively lift MTU's in tomorrows network we really need to solve this with enough nails and screws that it aint coming back out again. And I dont want to hear that ipv6 fixed this or that -- except if its possible to apply the lesson learned to the protocol most of us actually use. (not that I actually know if/how it works better in ipv6) because we all know that ipv4 is here to stay in its dominant position for at least 5-10 more years. It will need to be supported for possibley another 20. Joe Steve |