Subject: [pmtud] draft-ietf-pmtud-mwthod-00.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 05 Nov 2003 11:22:44 +0000

A few comments on draft-ietf-pmtud-mwthod-00.txt (November, 2003)

----
Section 4. "True MTU" - I don't understand this terminology?

Is this defined?

e.g. Does this contradict with the recommendation to use  "transparent
implicit fragmentation of the IP datagram" in RFC 3366 for links performing
ARQ?

---
Section  5.2 NiT: [FRAG] missing, e.g. this could be:
 
         Kent, C. A. and J. C. Mogul, "Fragmentation
                 Considered Harmful", Proceedings of ACM SIGCOMM 1987,
                 ACM Computer Communications Review, 17(5), pp. 390-401,
                 1987.
---
Section 5.3 Multicast Scaling

Do you think it would be possible to say more about the scaling issues when
you have large numbers of  down-stream hosts acting as multicast receivers
for a group for which you will use PMTUD?

- Is this also a network infrastucture DoS vulnerability?

---
Section 5.9, Note after para 2.

I'm not clear here what mitigation you provide for a host connected via a
slow link (i.e. one for which a large PMTU could create a significant
serialisation delay).

The procedure outlined in the ID suggests the host could change the probe
timeout - but doesn't this apply only to packets originated by the host? The
host also has to receive packets (and in many "slow" scenarios, I'd expect
bigger packets to be received than to be sent), and this mitigation does not
appear to help here. Although for TCP, the receiver MSS negociation may set
an upper bound on the size of probe? May be it would be useful to explicitly
describe a case for a host receiving by a  slow link.

---
Section 5.10 (p16) "Many TCP implementations incorporate"....

Don't the RFCs REQUIRE TCP Implementations to support slow-start, etc?

---

Best wishes,

Gorry Fairhurst

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