nanog mailing list archives
Re: MTU path discovery and IPSec
From: Crist Clark <crist.clark () globalstar com>
Date: Thu, 04 Dec 2003 17:22:23 -0800
Joe Maimon wrote:
Tony Rall wrote:On Wednesday, 2003-12-03 at 09:38 PST, David Sinn <dsinn () dsinn com> wrote:<snipped>(And note that frag 1 often is not the first fragment to arrive at downstream nodes. In my example in (1), frequently frag 2 will reach places before frag 1 does (if any router along the path reorders its transmit queue based on packet size).)I agree with all I have snipped. I was wondering would it not be wiser for fraggers to frag in half instead of just the overflow? For instance, suppose router has to fragment 1500 byte packet to go over 1476 GRE. Instead of having a big packet/little fragment why not just divide in half? This would give them more equal buffer treatment, but an even bigger potential win is to avoid perhaps a second (maybe ipsec?) fragmenting later on down the pipe. Once you are going to do it, do it right. It is not as if your decreasing header overhead by producing small fragment packets. And I am assuming the whole packet is already in buffer when it comes time to fragment it.
Programmers are lazy. Excerise for the reader: Devise an algorthm that will take an arbitrarily sized packet 20-65535 octets and an arbitrarily sized MTU, > 576 octets, and split the packet into the minimum number of "n" fragments where each fragment is (1) less than the MTU, (2) no two fragments differ by more than 8 octets, and the fragments obey the IP fragmentation rules, (3) data payload must end on an 8-octet boundary for all but the last fragment and (4) each fragment has an exact copy of the original header except for differences in the fragmentation fields and checksum. Compare to the algorithm of cutting the data in to "m" (mtu - ip_hl)- chunks and putting the leftovers into the final fragment. -- Crist J. Clark crist.clark () globalstar com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster () globalstar com
Current thread:
- Re: Firewall stateful handling of ICMP packets, (continued)
- Re: Firewall stateful handling of ICMP packets Valdis . Kletnieks (Dec 03)
- Re: Firewall stateful handling of ICMP packets Owen DeLong (Dec 03)
- Re: Firewall stateful handling of ICMP packets Henry Linneweh (Dec 03)
- Re: MTU path discovery and IPSec Tony Rall (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Valdis . Kletnieks (Dec 04)
- Re: MTU path discovery and IPSec Barney Wolff (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Valdis . Kletnieks (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Crist Clark (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Laurence F. Sheldon, Jr. (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 04)
- Re: MTU path discovery and IPSec Valdis . Kletnieks (Dec 04)
- Re: MTU path discovery and IPSec Joe Maimon (Dec 10)
- Re: MTU path discovery and IPSec Barney Wolff (Dec 10)