From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: Packet size s on CCID3
Date: Fri, 22 Sep 2006 13:42:07 +0000 [thread overview]
Message-ID: <200609221442.07896@strip-the-willow> (raw)
In-Reply-To: <5640c7e00609202022j1b97cf1g30797ffcd9b650b6@mail.gmail.com>
Quoting Ian McDonald:
| I have been discussing the packet size s for CCID3 (TFRC) with my
| supervisor and also been discussing related issues with Gerrit and I
| am wondering why we have this?
|
| CCID3 is datagram based and the whole point of s is to keep packets at
| a certain rate per second. In effect provided s is calculated
| correctly it cancels out of the equation but it becomes more
| complicated in the code! If it is miscalculated (accidentally or
| deliberately) it becomes worse because you are either starved or send
| too much.
|
| Why not just calculate a packet rate per second? Or am I missing
| something obvious?
I think this is confusing, as it mixes implementation issues with the theory.
Theory:
-------
One cannot remove s since it is part of the underlying model. A good explanation
is in [3, chapter 2]. The throughput equation used for TFRC has the form
X = s/RTT * f(loss_rate)
The `s' originates from the TCP throughput equations where it originally meant
maximum segment size (see [1,2]), which relates to the previous two comments.
Practice:
---------
Both CCID 2 and CCID 3 are for fixed packet sizes (cf sections 5.3 of RFC 4341/2),
i.e. s is a constant and hence you can indeed normalize the equation by dividing
both sides of the equation by s.
The problem is that an application may be malicious and alter its sending packet
sizes, rfc3448bis suggests to average such changes out. With regard to the implemen-
tation, it may be good to use a weighted average of the form such as e.g.:
s = q * len + (1-q) * s
where `len' is either the buffer length at the sender or the size of an incoming
packet at the receiver.
Gerrit
References:
-----------
[1] Mathis, Matthew, Jeffrey Semke, Jamshid Mahdavi and Teunis Ott.
The Macroscopic Behavior of the Congestion Avoidance Algorithm.
ACM SIGCOMM Computer Communication Review, 27(3):67--82, 7/1997.
[2] Padhye, J., V. Firoiu, D. Towsley and J. Kurose. Modeling TCP
Throughput: A Simple Model and its Empirical Validation. ACM
Computer Communication Review, 28(4):303--314, 1998.
[3] Widmer, Jörg. Equation-Based Congestion Control. Diploma Thesis,
University of Mannheim, Germany, 2/2000.
next prev parent reply other threads:[~2006-09-22 13:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 3:22 Packet size s on CCID3 Ian McDonald
2006-09-21 16:19 ` [dccp] " Gorry Fairhurst
2006-09-21 23:37 ` Ian McDonald
2006-09-22 13:26 ` Sally Floyd
2006-09-22 13:42 ` Gerrit Renker [this message]
2006-09-22 17:30 ` Eddie Kohler
2006-09-26 12:19 ` Gorry Fairhurst
2006-10-03 3:26 ` Ian McDonald
2006-10-03 3:40 ` Ian McDonald
2006-10-03 15:43 ` Eddie Kohler
2006-10-03 15:50 ` Eddie Kohler
2006-10-03 18:15 ` Ian McDonald
2006-10-03 18:18 ` Eddie Kohler
2006-10-03 19:48 ` Ian McDonald
2006-10-04 16:20 ` Eddie Kohler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200609221442.07896@strip-the-willow \
--to=gerrit@erg.abdn.ac.uk \
--cc=dccp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.