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

[Gorry Fairhurst <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pmtud