Quick administrative note: psg.com is presently blocking Google Gmail. While it's certainly psg's privilege to do so, blocking the massive email providers does tend to obstruct the discussion here.
550 550 blocked because 209.85.200.170 is in blacklist at qil.mail-abuse.com: On Sun, Apr 20, 2008 at 12:00 PM, Robin Whittle <[EMAIL PROTECTED]> wrote: > Here is a completely different approach to PMTUD to the one I > developed in October. It has the same name (IPTM - ITR Probes > Tunnel MTU) and is at the same place: Hi Robin, If I understand you, your strategy is essentially this: 1. Have the ITR maintain an "uncertainty zone" for sizes of packets that can be sent to a given ETR. The uncertainty zone is bounded by a size previously determined to be smaller than or equal to the actual PMTU (LPME) and a size previously determined to be larger than the actual PMTU (UPME). 2. The ITR encapsulates and transmits packets smaller than LPME normally. It rejects packets larger than UPME immediately with a too-big message. 3. If the packet size is in the uncertainty zone, encapsulate it with RPD2 instead of the normal encapsulation and hold the original packet until the ETR responds. This encapsulation consists of two packets: one in the uncertainty zone and one smaller than LPME. If successfully transmitted, the ETR will reassemble the two packets into one before passing them on. 4. The ETR is required to respond to the ITR with information about all communications associated with RPD2, in addition to delivering the packets. By comparing the ETR's response to the RPD2 messages with the RPD2 messages it sent, the ITR can narrow the uncertainty zone until LPME and UPME meet. Please correct any part of that I misunderstood. Two questions, one note: Question #1: How does the ITR determine that its old PMTU estimate has been invalidated, either because of a route change or because individual packets are being transmitted along multiple channels each with a different PMTU? If I understand you, packets are not transmitted with RPD2 unless the ITR believes the size falls in the uncertainty zone, and not transmitted with the ITR's source IP address regardless, so the ITR has no real hope of seeing normal too-big complaints. So how does it ever decide that its estimated PMTU is no longer valid? Question #2: nearly every ITR->ETR map will trigger the use of RPD2 as two associated end sites begin transmitting data. Given the complexity, you're looking at a general-purpose CPU on both ends to handle this. What sort of impact does that have on the system capacity? Note #1: in your document, you describe the ETR returning multiple packets to the ITR for each received RPD2 packet, until the ITR acknowledges receipt. This potentially resurrects our old friend, the smurf amplifier. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
