RFC 3448/4340/4342 state in their introductory sections that these request
"discussion and suggestions for improvements"
I would like to raise the following suggestion for improvements: currently the
RFCs are elusive and ambiguous with regard to whether `s' in the TCP throughput
equation is fixed or not. Presently, reading these documents admits three entirely
different interpretations:
(1) `s' is fixed (i.e. bona fide constant)
(2) `s' is an average which MAY be calculated over four RTT or longer (cf. below)
(3) `s' equals the MSS
These ambiguities do cause implementers a lot of unnecessary trouble and confusion;
and contribute to an ongoing non-existence of a consistent DCCP stack.
The problem with (1) is: what kind of application will send fixed size packets all the
time? It is a constraint which is helpful for numerical simulation, but becomes a
hinderance in dealing with actual applications.
Secondly, there is substantial evidence that using (3), while allowing the
application to choose its `s' freely, is detrimental:
The problem in assuming that `s' may vary and in allowing it to be set to
some other (but fixed) value, such as the path MTU minus header/option
lengths, lies in required changes to the loss rate estimation algorithm.
References which explicitly warn against this are given below; in both
[Wid00, p. 21] and [FHP+00, 3.1.2] it is pointed out that this part has taken
much discussion and testing; for good reasons, since any changes endanger
both efficiency and fairness wrt competing TCP flows.
Theorems and numerical examples that attest that inaccuracies in parameter
estimation lead to either non-TCP-friendly or suboptimal application behaviour
can be found in [RR99]; to be later confirmed later by the much more comprehensive
analysis in [VLB05].
These findings were validated and corroborated by Widmer et al in [WBLB04]. This
article, as well as the earlier technical report [Vas00], warn against using the
MTU as `fixed' packet size parameter of the throughput equation, in such scenarios
where the application is allowed to send variable-sized packets. To solve the problem
of a non-`fixed' s, Widmer et al introduce a number of changes to the loss
estimation algorithm in [WBLB04].
In summary: there are several publications which explicitly warn against clamping
`s' to the path MTU / MSS [Vas00, WBLB04,VLB05,RR99] and thereby allowing applications
to be liberal with (the length of) what they send.
Suggestion for improvement: until resolved by further research, suggest use of
EWMA for computing `s' in the througput equation, but not setting `s' equal to MSS.
| > One reason for including the packet size s is discussed in
| > Section 5.3 of RFC 4342:
| >
| > "The packet size s is used in the TCP throughput equation. A CCID 3
| > implementation MAY calculate s as the segment size averaged over
| > multiple round trip times -- for example, over the most recent four
| > loss intervals, for loss intervals as defined in Section 6.1.
| > Alternately, a CCID 3 implementation MAY use the Maximum Packet Size
| > to derive s. In this case, s is set to the Maximum Segment Size
| > (MSS), the maximum size in bytes for the data segment, not including
| > the default DCCP and IP packet headers. Each packet transmitted then
| > counts as one MSS, regardless of the actual segment size, and the TCP
| > throughput equation can be interpreted as specifying the sending rate
| > in packets per second."
| >
| > Thus, an implementation MAY calculate the allowed sending rate
| > in bytes per second, using for s the average segment size.
| > Or an implementation may use the MSS for s, and in fact calculate
| > the allowed sending rate simply in packets per second. This would be
| > a purely local implementation decision.
Unfortunately the latter choice is not backed up by current research (cf. above)
and thus does not appear to be sound.
| Why do we have to assume s = MSS? If we actually track the number of
| packets this makes the situation far worse and we can't send at a fair
| rate. For example if MSS is 1500 bytes and we are actually using 50
| byte packets then we can only send 1/30 th of what we are permitted
| under the TCP throughput equation.
|
| Using MSS is fair if we are using a byte rate per second
| implementation but if we do a packet per second implementation (given
| X and s act to cancel out) this seems patently wrong.
See comments above.
References
--------------
[RR99] Ramesh, Sridhar and Injong Rhee. Issues in TCP Model-Based Flow
Control. Technical report, TR-99-15, NCSU, North Carolina State
University, Raleigh, 1999.
[VLB05] Vojnovic, Milan and Jean-Yves Le Boudec. On the long-run behavior
of equation-based rate control. IEEE/ACM Transactions on
Networking (TON), 13(3):568--581, 6/2005.
[WBLB04] Widmer, Jörg, Catherine Boutremans and Jean-Yves Le Boudec.
End-to-End Congestion Control for TCP-Friendly Flows with
Variable Packet Size. ACM SIGCOMM Computer Communication Review,
34(2):137--151, 4/2004.
[Vas00] Vasallo, Pedro Reviriego. Variable Packet Size Equation Based
Congestion Control. Technical Report, tr-00-008, ICSI, 4/2000.
[FK06] Floyd, Sally and Eddie Kohler. TCP Friendly Rate Control (TFRC):
the Small-Packet (SP) Variant. draft-ietf-dccp-tfrc-voip-05.txt,
1/3/2006.
[HFPW06] draft-floyd-rfc3448bis-00.txt
[Wid00] Widmer, Jörg. Equation-Based Congestion Control. Diploma Thesis,
Department of Mathematics and Computer Science, University of
Mannheim, Germany, 2/2000.
[FHP+00] Floyd, Sally, Mark Handley, Jitendra Padhye and Jörg Widmer.
Equation-Based Congestion Control for Unicast Applications. ACM
SIGCOMM Computer Communication Review, 30(4):43--56, 10/2000.
