netdev - Re: [RFC 2/3] TCP: cubic - eliminate use of receive time stamp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 19 Jul 2007 13:47:27 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
cc:	"David S. Miller" <davem@...emloft.net>,
	Sangtae Ha <sha2@...u.edu>, Luca De Cicco <ldecicco@...il.com>,
	Gavin McCullagh <gavin.mccullagh@...m.ie>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC 2/3] TCP: cubic - eliminate use of receive time stamp

Hi all,

It's definately better to do rtt measurements in the proper callback
like you're suggesting since the call to cong_avoid depends on too many
factors (ECN, FRTO) that shouldn't inhibit rtt sampling though they,
for a period, determine how cwnd must be set...

-- 
 i.

On Thu, 19 Jul 2007, Stephen Hemminger wrote:

> Remove use of received timestamp option value from RTT calculation in Cubic.
> A hostile receiver may be returning a larger timestamp option than the original
> value. This would cause the sender to believe the malevolent receiver had
> a larger RTT and because Cubic tries to provide some RTT friendliness, the
> sender would then favor the liar.
> 
> Instead, use the jiffie resolutionRTT value already computed and
> passed back after ack.
> 
> Signed-off-by: Stephen Hemminger <shemminger@...ux-foundation.org>
> 
> --- a/net/ipv4/tcp_cubic.c	2007-07-19 08:21:42.000000000 +0100
> +++ b/net/ipv4/tcp_cubic.c	2007-07-19 08:24:58.000000000 +0100
> @@ -246,38 +246,12 @@ static inline void bictcp_update(struct 
>  		ca->cnt = 1;
>  }
>  
> -
> -/* Keep track of minimum rtt */
> -static inline void measure_delay(struct sock *sk)
> -{
> -	const struct tcp_sock *tp = tcp_sk(sk);
> -	struct bictcp *ca = inet_csk_ca(sk);
> -	u32 delay;
> -
> -	/* No time stamp */
> -	if (!(tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr) ||
> -	     /* Discard delay samples right after fast recovery */
> -	    (s32)(tcp_time_stamp - ca->epoch_start) < HZ)
> -		return;
> -
> -	delay = (tcp_time_stamp - tp->rx_opt.rcv_tsecr)<<3;
> -	if (delay == 0)
> -		delay = 1;
> -
> -	/* first time call or link delay decreases */
> -	if (ca->delay_min == 0 || ca->delay_min > delay)
> -		ca->delay_min = delay;
> -}
> -
>  static void bictcp_cong_avoid(struct sock *sk, u32 ack,
>  			      u32 seq_rtt, u32 in_flight, int data_acked)
>  {
>  	struct tcp_sock *tp = tcp_sk(sk);
>  	struct bictcp *ca = inet_csk_ca(sk);
>  
> -	if (data_acked)
> -		measure_delay(sk);
> -
>  	if (!tcp_is_cwnd_limited(sk, in_flight))
>  		return;
>  
> @@ -337,14 +311,30 @@ static void bictcp_state(struct sock *sk
>  static void bictcp_acked(struct sock *sk, u32 cnt, s32 rtt_us)
>  {
>  	const struct inet_connection_sock *icsk = inet_csk(sk);
> +	struct bictcp *ca = inet_csk_ca(sk);
> +	u32 delay;
>  
>  	if (cnt > 0 && icsk->icsk_ca_state == TCP_CA_Open) {
> -		struct bictcp *ca = inet_csk_ca(sk);
>  		cnt -= ca->delayed_ack >> ACK_RATIO_SHIFT;
>  		ca->delayed_ack += cnt;
>  	}
> -}
>  
> +	/* Some calls are for duplicates without timetamps */
> +	if (rtt_us < 0)
> +		return;
> +
> +	/* Discard delay samples right after fast recovery */
> +	if ((s32)(tcp_time_stamp - ca->epoch_start) < HZ)
> +		return;
> +
> +	delay = usecs_to_jiffies(rtt_us) << 3;
> +	if (delay == 0)
> +		delay = 1;
> +
> +	/* first time call or link delay decreases */
> +	if (ca->delay_min == 0 || ca->delay_min > delay)
> +		ca->delay_min = delay;
> +}
>  
>  static struct tcp_congestion_ops cubictcp = {
>  	.init		= bictcp_init,
> 
> 


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html