Gorry and Richard - Many thanks for the feedback about smalll PMTUs. I took your suggestions, and some of your text, and have (I think) now made all of the revisions to the draft from the final comments after WGLC. The revised draft is at: http://www.icir.org/floyd/papers/draft-ietf-dccp-tfrc-voip-07.txt http://www.icir.org/floyd/papers/draft-ietf-dccp-tfrc-voip-07.ps I thought I would wait a day or two before submitting it, in case you had feedback about the PMTU language. I am appended to the end of this document. This includes a change saying that if the sender knows the path MTU, and it is less than 1500 bytes, then the sender SHOULD set the nominal segment size s appropriately. The changes are as follows: Changes from draft-ietf-dccp-tfrc-voip-06.txt: * Fixed nits introduced in the last round of editing. Feedback from Gorry Fairhurst. * Fixed Tables 1-4, in terms of taking account of packet header sizes for 536-byte packets. Feedback from Ladan Gharai. * Added a paragraph about apps gaming about the packet size, in Section 6 on "TFRC-SP with Applications that Modify the Packet Size". Feedback from Gorry Fairhurst. * Added a paragraph that if the endpoint knows the MSS of the path, the endpoint SHOULD use that for the nominal segment size. From discussions with Gorry Fairhurst and Richard Nelson. * Added several paragrahs about TFRC-SP over paths with small MTUs. Feedback from Gorry Fairhurst and Richard Nelson. * Added pseudocode to Section 3 on "TFRC-SP Congestion Control" for the change of not using the current interval in estimating the loss event rate if the current interval is short. Feedback from Ladan Gharai. - Sally http://www.icir.org/floyd/ PMTU language: Section 3: TFRC-SP changes this behavior in the following ways. o The nominal segment size: The nominal segment size s is set to 1460 bytes. Following [RFC3714], this provides a goal of fairness, in terms of the sending rate in bytes per second, with a TCP flow with 1460 bytes of application data per packet but with the same packet drop rate. If the endpoint knows the MTU (Maximum Transmission Unit) of the path and the derived MSS (Maximum Segment Size) is less than 1460 bytes, then the endpoint SHOULD set the nominal segment size s to MSS bytes. In addition, if the endpoint knows the MTU of the path and the resulting MSS is less than 536 bytes, then the endpoint MUST set the nominal segment size s to MSS bytes. However, this document does not require that TFRC-SP endpoints determine the path MTU. While most paths allow an MSS of 1460 bytes, some paths have a slightly smaller MSS due to tunnels, IPv6, and the like, and some other paths only allow a significantly smaller MSS of only 536 bytes. Due to the complications of estimating the path MTU, and to the fact that most paths support an MSS of at least 536 bytes, TFRC-SP as a default uses a nominal segment size of 1460 bytes. ... 4.5.2. Fragmentation and the Path MTU This document doesn't specify TFRC-SP behavior in terms of packet fragmentation and Path MTU Discovery (PMTUD). That is, should the transport protocol using TFRC-SP use PMTUD information to set an upper bound on the segment size? Should the transport protocol allow packets to be fragmented in the network? We leave these as questions for the transport protocol. As an example, we note that DCCP requires that endpoints keep track of the current PMTU, and says that fragmentation should not be the default [RFC4340] (Section 14). 4.5.3. The Nominal Segment Size and the Path MTU When TFRC-SP is used with a nominal segment size s of 1460 bytes on a path where the TCP MSS is in fact only 536 bytes, the TFRC-SP flow could receive almost three times the bandwidth, in bytes per second, as that of a TCP flow using an MSS of 536 bytes. Similarly, in an environment with an MSS close to 4000 bytes, a TCP flow could receive almost three times the bandwidth of a TFRC-SP flow with its nominal segment size s of 1460 bytes. In both cases, we feel that these levels of "unfairness" with factors of two or three are acceptable; in particular, they won't result in one flow grabbing all of the available bandwidth, to the exclusion of the competing TCP or TFRC-SP flow. All IPv4 *end hosts* are required to accept and reassemble IP packets of size 576 bytes [RFC791], but IPv4 *links* do not necessarily have to support this packet size. In slow networks, the largest possible packet may take a considerable amount of time to send [RFC3819], and a smaller MTU may be desirable, e.g. 100's of bytes. If the first-hop link had a small MTU, then TCP would choose an appropriately small MSS [RFC879]. [RFC1144] quotes cases of very low link speeds were the MSS may be tens of bytes (and notes this is an extreme case). We note that if TFRC-SP is used over a path with an MTU considerably smaller than 576 bytes, and the TFRC-SP flow uses a nominal segment size s of 1460 bytes, then the TFRC-SP flow could receive considerably more than three times the bandwidth of competing TCP flows. If TFRC-SP is used with a nominal segment size s of less than 536 bytes (becauses the path MTU is known to be less than 576 bytes), then TFRC-SP is likely to be of minimal benefit to applications. If TFRC-SP was to be used on paths that have a path MTU of considerably less than 576 bytes, and the transport protocol was not required to keep track of the path MTU, this could result in the TFRC-SP flow using the default nominal segment size of 1460 bytes, and as a result receiving considerably more bandwidth than competing TCP flows. As a result, TFRC-SP is not recommended for use with transport protocols that don't maintain some knowledge of the path MTU.
