Hi Eddie,
| The "intended average packet size", a congestion control parameter used by
| CCID 3 and CCID 4, is different from the actually _observed_ packet size. I
| could see how an explicit setting for this congestion control parameter might
| be useful in addition to the information communicated by 'len' and incoming
| packet sizes.
|
| CCID 3, for example, says that 's' MAY be calculated from a running average,
| OR from the maximum segment size. I think an option like
| DCCP_SOCKOPT_TX_PACKET_SIZE, by which the app can declare an intended average
| packet size, is also acceptable.
It is acceptable but not useful. The kernel module already has the information
available to derive `s' in either way:
* it knows the maximum segment size (which a user would have to retrieve via another
socket option call)
* it has information about packet header lengths and option lengths
* it can track the average of past payload lengths
Why burden the application programmer to handcode an estimation of the average each
time? I can not see a justification for this, certainly not for CCIDs which
are intended to be used with (on average) fixed packet sizes.
I think that a priority is to keep the user programming interface as simple as
possible -- like UDP's interface, as stated in RFC 4340.
| > In summary, I think it would be better to let the sender/receiver determine the
| > packet size from already available data. That is, derive s from the `len' of dccp_sendmsg(),
| > and use a weighted-average mechanism like
| > s = q * len + (1-q) * s
| > to smooth out variations: in accordance with draft-floyd-rfc3448bis-00.
|
| This would be fine with me, and perhaps even preferable in terms of the
| programming API. But the drafts I think would allow the socket option, so if
| it's needed now, why not?
To encourage programmers to use DCCP by providing a simple-to-use programming API with a minimal
set of required options to program into the application code.
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
