I think you summarise the issues.
If we were heading for a standards-track RFC, we may have to think
through this and several other deployment-related cases in much more
detail. Given, this is being put for EXP RFC status, I'd be happy for
you to submit an I-D with these changes (see one NiT in the text).
Thanks for your patience and attentiomn to detail,
Best wishes,
Gorry Fairhurst
Sally Floyd wrote:
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
Change /IPv6, and the like/ to /IPv6/IPv4 as an example/
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.
