| I don't think the RFCs are nearly as ambiguous as you claim. RFC 4342
| explicitly allows interpretations (2) 's' is an average and (3) 's = MSS'.
| (1) is not mentioned.
Section 5.3: "CCID 3 is intended for applications that use a fixed packet size,
and
that vary their sending rate in packets per second in response to
congestion."
| You clearly believe that (3) 's = MSS' is a bad idea. However, the
documents
| allow it.
I was not stating a personal `belief', these are results published in the
literature.
That the documents allow it is of no help: as explained, they allow `s' to be
interpreted
in three entirely different ways. This variability is clearly not implementable.
| I believe you are asking for (3) 's = MSS' to be officially deprecated. I
see
| no need for that. In general 's = MSS' is conservative (yes?) so there is
no
| need to deprecate it.
No I am asking for clearer specification of this issue so that implementers (not
trained researchers) can unambiguously derive an implementation from it.
| I would want a future revision of RFC 4342 to consider something like the
| "virtual packets" idea in [WBLB04]. I agree with their conclusion that
| estimating packet sizes with estimators is danger fraught, and that one
should
| instead modify the way losses are defined. "Virtual packets" also feel like
| TCP-ABC.
To me LIP Scaling seemed to be the most promising proposal, but we are entering
a
domain here which was not my intention - we here need a consistent, working
DCCP
implementation based on existing standards-track specifications.
- Gerrit
| > 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.
| >
| >
|
|
