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

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 05 Nov 2005 20:27:39 -0800

This document looks in good shape, can I offer a few comments from my
reading?

Best wishes,

Gorry

Comments on the protocol:

---
Some of section 8.1 and 8.2 (also 8.6.2)  seems like it would benefit from
RFC2119 standards language.
---
In section 8.4, the I-D concludes by saying that applications may wish to
delay for a period of time. I think leaving this open to an unbounded delay
period seems wrong, shouldn't the delay be bounded - at least a warning that
excessive delay could result in Timeouts at higher layers is worth noting.
---
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.
---
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.

---
 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.

------------------------------------
NiTs/ English:

Check for consistent use of Path MTU (which I prefer):
/path MTU/Path MTU/
 ^
---
Check for consistent use of (which mostly seems correct)
/Packetization Layer/
 ^             ^
---
Page 7, Line 2:
/[12] Probing/[12]. Probing/
----
Page 7 final paragraph: add s
/can be used a the sole/ can be used as the sole/
                                      ^
----
Page 14, final para:
/calculations. [11]/calculations [11]./
                                     ^
----
Page 15, section 6.1: Add reference for SACK Scoreboards?
/Many protocol implementations... SACK Scoreboards.../
----
Page 16, section 6.2: Add reference for SCTP Heartbeat?
/Many Packetization Layer protocols... SCTP Heartbeat.../
---
Page 16, section 6.2: final para add "be"
/may no reasonable mechanisms/may be no reasonable mechanisms/
                                  ^^
---
Page 16, section 6.2: final para add comma
/As a last resort it/As a last, resort it/
                              ^
---
Page 18, 8.1
/packetization layer/Packetization Layer/
                     ^             ^
---
Page 19:  para 2:
/may have na impact/may have no impact/
                             ^^
---
Page 19:  para 2:
/may have na impact on ... in all cases/
- The words "in all cases" seem to be rather hard to read in this sentence.
---
Page 20:  para 1:
/For a protocol which uses/For a protocol that uses/
                                          ^^^^
---
Page 20:  para 2:
/Fpr a packet's worth of available data/
- This could be better phrased.
---
Section 8.7
/ICMP messages was ignored/ ICMP messages was ignored/
             ^
---
Section 8.8 para 2
/However, if ICMP is..../
The first line is very hard to read.
---
Section 10.3
/far node/remote host/
          ^^^^^^^^^^^
---
Page 25: Section 10.3, para 3:
/To error/to err/ ;-)
             ^^^
---
Page 26: para 2
/and only the saved PTB/
- I don't understand the English in the last sentence of this paragraph.
---
Section 10.4 last para -2
/Some applucation  s.../
- I think the case is when the transmission rate causes there to be a chance
that ID is not unique (within an MSL)... So this is high-speed links, right?
---
Section 10.4 last para, bad apostrophe:
/datagram's over all/ datagrams over all/
         ^   
---    
Security Considerations:
- I think this section should highlight again the PMTUD DoS vulnerabilbity
when used in multicast (and refer back to the earlier section.

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: John Heffner <[email-masked]>
Date: Tue, 08 Nov 2005 10:19:36 -0800

> excessive delay could result in Timeouts at higher layers is worth noting.

Good points.  Will think about these.

> size for IPv4 is 68 bytes - why not 576 bytes - some explanation seems to be

 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.

> 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. :)

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.

> guards against use of the option for two different purposes.

We're working on trying to get a PAD chunk type defined.

Will apply, thanks.

> 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?

Thanks,
   -John