Re: [RRG] Path MTU Discovery: a new approach

[bill@herrin.us (William Herrin)]

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 <rw@firstpr.com.au> 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 ................ herrin@dirtside.com  bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com 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