Re: [pmtud] Draft-ietf-pmtud-method-05

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 10 November 2005 16:15 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaF5G-000079-5g; Thu, 10 Nov 2005 11:15:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaF5E-000074-OQ for pmtud@megatron.ietf.org; Thu, 10 Nov 2005 11:15:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13806 for <pmtud@ietf.org>; Thu, 10 Nov 2005 11:15:00 -0500 (EST)
Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFLU-0006t2-0N for pmtud@ietf.org; Thu, 10 Nov 2005 11:32:16 -0500
Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id jAAGExQU029505 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 10 Nov 2005 16:15:12 GMT
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Thu, 10 Nov 2005 08:14:02 -0800
Subject: Re: [pmtud] Draft-ietf-pmtud-method-05
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: John Heffner <jheffner@psc.edu>
Message-ID: <BF98B1CA.407A%gorry@erg.abdn.ac.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: Matt Mathis <mathis@psc.edu>, pmtud@ietf.org
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Sender: pmtud-bounces@ietf.org
Errors-To: pmtud-bounces@ietf.org

On 8/11/05 10:19 am, "John Heffner" <jheffner@psc.edu> wrote:


>> ---
>> At the end of section 8.7, the document concludes the minimum safe packet
>> size for IPv4 is 68 bytes - why not 576 bytes - some explanation seems to be
>> needed.
> 
>  From RFC 791:
> 
>    Every internet module must be able to forward a datagram of 68
>    octets without further fragmentation.  This is because an internet
>    header may be up to 60 octets, and the minimum fragment is 8 octets.
> 
>    Every internet destination must be able to receive a datagram of 576
>    octets either in one piece or in fragments to be reassembled.
> 
> I'll add a citation.
> 

OK

>> ---
>> Section 10.1, para 2
>> - I disagree that limiting the largest probe size offers any guarentee that
>> TCP FR will not be triggeered. FR *can* still be triggered by packet
>> re-ordering (which is why we have a DupACK threshold) - so this doesn't
>> eliminate this, but it does mitigate the probability that FR is triggeered.
> 
> I guess what we should say is that if your probe is a full cur_mss
> larger than the dupack threshold * cur_mss, a successful probe *will*
> trigger fast retransmit (unless you have DSACK), so you don't want to do
> that. :)
> 
Yep :-)
> I'm tempted to pull the description of this method from the draft since
> it's not clear to me it has any benefits over the other way.
> 
> 

>> ---
>>  In section 10.2, the I-D seems to advocate using any unassigned Type as
>> padding, whilst this is true, it seems to be bad IETF practice to advocate
>> this, can we simply request an type to do this instead, it seems clean and
>> guards against use of the option for two different purposes.
> 
> We're working on trying to get a PAD chunk type defined.
> 
OK.

> 
>> Security Considerations:
>> - I think this section should highlight again the PMTUD DoS vulnerabilbity
>> when used in multicast (and refer back to the earlier section.
> 
> Do you mean joining a multicast group doing PMTUD, and reporting a small
> MTU?
> 
Yes - although that's not very profound, I think it is very worth stating
with a section ref to the text.

> Thanks,
>    -John
> 



_______________________________________________
pmtud mailing list
pmtud@ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud