| Hi, a bit of re-clarification: CCIDs 2 and 3 are *not* meant for apps that
| NEVER vary their packet size. Rather, they are meant for apps that very
| packet size *for application reasons* (such as codec output), but *not* in
| response to congestion. CCIDs 2 and 3 expect to reduce application RATES in
| response to congestion.
My understanding is that there is very little wisdom currently regarding
applications
which vary their packet sizes due to application reasons; I have copied the
quotes
I am referring to below. The work-in-progress draft-ietf-dccp-tfrc-voip-05.txt
is not very outspoken about what happens if the application changes its packet
size.
[RFC 4341, sec. 5.3]: "CCID 2 is optimized for applications that generally use
a fixed
packet size and vary their sending rate in packets per
second in
response to congestion."
[RFC 4342, sec. 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."
If we allow applications to violate these premises then I don't know how to fix
this in the code.
| In summary, in the longer-term deriving 's' from observations would work,
but
| I don't see any objection to this socket option in the short term or the
long
| term. It allows the application to explicitly state its intent, which is
| usually useful.
I would like to suggest a compromise: retaining an experimental patch which
allows
this socket option and can be used for people interested in experimenting with
these
ideas, to gain new insights; and to leave the main kernel API as simple as it
can
possibly be made.
--Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
