> c int dccp_hdlr_ack_ratio(struct sock *sk, u64 ratio, bool rx)
> | {
> | -#ifndef __CCID2_COPES_GRACEFULLY_WITH_DYNAMIC_ACK_RATIO_UPDATES__
> | - /*
> | - * FIXME: This is required until several problems in the CCID-2 code are
> | - * resolved. The CCID-2 code currently does not cope well; using dynamic
> | - * Ack Ratios greater than 1 caused instabilities. These were manifest
> | - * in hangups and long RTO timeouts (1...3 seconds). Until this has been
> | - * stabilised, it is safer not to activate dynamic Ack Ratio changes.
> | - */
> | - dccp_pr_debug("Not changing %s Ack Ratio from 1 to %u\n",
> | - rx ? "RX" : "TX", (u16)ratio);
> | - ratio = 1;
> | -#endif
> | if (rx)
> | dccp_sk(sk)->dccps_r_ack_ratio = ratio;
> | else
> |
> This also affects the remote ack ratio in ccid2_hc_rx_packet_recv() -- did you observe any
> interactions with that?
Since this patch changes the remote ack ratio, that obviously causes
ccid2_hc_rx_packet_recv() to change how often it sends acks. (which is
the point)
Fortunately, ccid2_hc_rx_packet_recv() is very simple and does exactly
what it should if the ack ratio changes: it immediately switches to
using the new value.
This is exactly what we need if the congestion window is very small (say
1 packet). To wait for another cycle of the current ack ratio (i.e. to
switch right after sending an ack), would very likely cause timeouts.
Samuel Jero
Internetworking Research Group
Ohio University
Attachment:
signature.asc
Description: This is a digitally signed message part
