netdev - Re: [PATCH] netem: fix rate extension and drop accounting

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 linux-cve-announce PHC
Open Source and information security mailing list archives

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

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

Message-ID: <1342546773.2626.909.camel@edumazet-glaptop>
Date:	Tue, 17 Jul 2012 19:39:33 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Mark Gordon <msg@...gle.com>
Cc:	Hagen Paul Pfeifer <hagen@...u.net>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Yuchung Cheng <ycheng@...gle.com>,
	Andreas Terzis <aterzis@...gle.com>
Subject: Re: [PATCH] netem: fix rate extension and drop accounting

Please Mark :

1) Dont top post on netdev

2) Dont write HTML mails on netdev (your mail never went to netdev,
   only to CCed people). Only text mails are allowed.

On Tue, 2012-07-17 at 10:20 -0700, Mark Gordon wrote:
> Even the static delay case seems wrong with the new patch.  Assume all
> packets have the same sched_time.  Then if you spam packets that get
> processed at the same time by netem they will all get scheduled with
> the same time_to_send because the first packet will get time_to_send
> of [1] = clock_time + sched_time.  Then packet n compute 'now' as
> [n-1] and delay as sched_time - (clock_time - [1]) = 0 so that [n] =
> [n-1].  Therefore every packet gets scheduled at the same time.
> 
> 
> The above modification seems to fix the issue when latency/jitter is 0
> but suffers from a missing non-linearity when delay is present.  Is
> there a technical reason I'm missing that prevents us from doing rate
> and latency here?  Why wouldn't the 'official' patch have correct
> rate?

Because delay is variable (jitter)

netem as is is not working correctly if you have both a rate limit and
delay.

Hagen is working on a solution, but there is no easy fix.

The right solution is to have :

1) A rate stage, using a child qdisc (that you can graft to install your
own qdisc hierarchy if needed, say if you want codel or fq_codel ;))

  Thats basically a TBF...

2) skb orphan

3) drops/reorders/corrupt/additional delay (variable delay)
   using an internal tfifo, to mimic real networks behavior.

Thats the reverse of how its currently done.

Alternatively, this could be implemented as a special network device,
like bonding, instead of a qdisc.



--
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