| This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
| and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
| work and packet size should be set independently on two half
| connections.
I disagree with this solution: it solves one problem by introducing two
new ones:
* the options are redundant:
--at the sender the packet size is implicitly communicated via the
`len' argument of dccp_sendmsg()
--the receiver samples the packet sizes of incoming packets
* it makes the programming interface more complex; currently these options
only work for CCID 3 (cf. patch 6/7)
* both CCID 2/3 are for fixed-packet sizes anyway, and the upcoming
CCID 4 draft-ietf-dccp-tfrc-voip-05.txt looks much rather like a
fixed `mini' packet size rather than a variable-size protocols
* for varying packet sizes, the sender should calculate the mean/avg
packet size by itself, rather than relying on information. For TFRC,
[draft-floyd-rfc3448bis-00, sec. 4.1] suggests here:
"where the segment size varies depending on the data, the sender MAY estimate the
segment size s as the average segment size over the last four loss intervals."
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.
-- 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
