Subject: Re: [rmcat] Packet reordering

From: Ingemar Johansson S <[email-masked]>
Date: Sun, 4 May 2014 19:47:46 +0000

Hi

Change subject line a bit.

Thanks for intersting input Keith. Do you have any data on how deep the repordering is?. Is it deep enough to cause 3-duplicate ACKs in TCP ?, I would belive that people would start to complain about poor TCP performance ?. Admit that I occasionally experince poor TCP performance in my home network but I have sofar blamed it not normal packet losses but perhaps there could be other causes.

The precense of reordering in 3GPP networks depend. If we consider just default (best effort) bearers and look at the radio interface only then the answer is that reordering will not happen, the reason is that the default bearers use Acknowledged mode transmission with guaranteed in order delivery to higher layers. There are other e.g QoS bearers that use Unacknowledged mode transmission in which case reordering may occur.
Going to the backhaul. As I mentioned in an earlier email, reordering may occur here due to load balancing and I have seen examples of that, however only enough to trigger one dupACK. In teory GTP-U sequence numbers can be enabled and the packet ordering can be restored at the tunnel egress, doubt however that this is used.

I don't argue against testing robustness against reordering (within reason) but perhaps it should then be a separate test case if necessary ? Somehow I believe however that reordering is a bigger challenge for audio and video rendering (necessiates a receiver buffer) than for the actual rate adaptation algorithms.

/Ingemar

> -----Original Message-----
> From: Keith Winstein [mailto:[email-masked]]
> Sent: den 2 maj 2014 22:09
> To: [email-masked]
> Subject: Re: [rmcat] rmcat Digest, Vol 21, Issue 2
> 
> Our experience with packet reordering has actually been quite different. We
> (Mosh) have found that packet reordering can be extremely common on
> 802.11n networks when the "block acks" feature is used and a link is
> saturated, at least with some receiving 802.11n chipsets, including the ones in
> MacBooks.
> 
> In Mosh version 1.2.2, we turned on an advisory warning when packets were
> reordered in the network, because we thought that in practice reordering
> was rare enough to be notable and might signify an attempted attack.
> 
> After the release, we got a lot of complaints that the warning was showing
> up frequently for users on enterprise 802.11n networks using the MacBook
> and a few other devices. On a full-throttle TCP download to a MacBook Pro,
> we found that something like 30-50% of all TCP segments were being
> delivered out of order! And Mosh's UDP datagrams were seeing similar
> treatment when there was a back-to-back flight of them. We ended up
> disabling the warning in v1.2.3.
> 
> As I understand, the block acks feature means that a sender may transmit a
> whole chunk of frames (some of which will be received without error and
> some won't), and then the receiving station can tell the sender which frames
> were successfully received and which need to be retransmitted. In the
> meantime, the receiver can deliver the successfully-received datagrams to IP
> or wait.
> 
> RFC 3366 3.1 essentially advises link designers that they should use a receive-
> side reordering buffer to try to put datagrams back in order before delivery
> to IP, but our testing suggests that common 802.11n receive chipsets don't
> do this in practice.
> 
> So our experience has been that in the contemporary Internet (at least on
> some 802.11n networks), reordering can be much more common than we
> had initially believed.
> 
> On Fri, May 2, 2014 at 3:00 PM,  <[email-masked]> wrote:
> > ---------- Forwarded message ----------
> > From: Randell Jesup <[email-masked]>
> > To: [email-masked]
> > Cc:
> > Date: Fri, 02 May 2014 05:49:16 -0400
> > Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4
> > RMCAT Flow competing with a long TCP Flow On 4/30/2014 1:51 PM, Colin
> Perkins wrote:
> >>
> >> On 30 Apr 2014, at 07:50, Zaheduzzaman Sarker
> <[email-masked]> wrote:
> >>>
> >>> Are you saying re-ordering is not a phenomena that we can observe in
> the current Internet? And we should not have test cases to handle re-
> ordering of packets in RMCAT?
> >>
> >> One of my students collected some UDP streaming measurements from
> our university to hosts on residential networks, covering all the main UK ISPs,
> a couple of years ago. With everything using wired connections and UDP we
> saw a couple of hundred packets delivered out of order, from ~250 million
> packets sent. I can dig into the details of the re-ordering patterns if there’s
> interest. We didn’t analyse them too closely at the time because packet loss
> and delay spikes were much more common.
> >
> >
> > Having it not fall over on (some) reordering: good.  My experience has
> been only specific unusual network/hardware situations cause more than
> 0.0x% reordering of packet delivery (at the IP level, ignoring things like TCP
> retransmit, which is not an IP-level reordering in the way I'm discussing).
> >
> > I've seen significant reordering only on a network (an old office network of
> mine!) where we had multiple bonded T1's and the packets went across one
> of them randomly (I presume).  I think I got to low-single-digit percent or
> more likely 0.n% (like 0.1-0.9%) reordered.  There may also be some wireless
> networks where this is more likely than on normal wired; I haven't noticed it
> on WiFi though.
> >
> > It's easy to accidentally set up DummyNet/etc to cause massive packet
> reordering, however.  I do not think that should be a primary or even
> secondary testcase, and (to be honest) I don't think we should care much
> about degenerate reordering cases.  I'm not even sure we should bother
> spending much energy in our evaluation tests making it happen at all (which
> isn't to say that the algorithm authors shouldn't consider it and if they feel it
> would affect them, test it or discuss it - plus they will see a small amount of it
> on real networks).
> >
>

---

From: Keith Winstein <[email-masked]>
Date: Sun, 4 May 2014 19:17:02 -0400

Hello Ingemar,

I'd have to do a more careful (and recent!) measurement to answer you
clearly, but my recollection is that it was generally not deep enough
to cause a triple dupack except perhaps very rarely. Generally
speaking, as I recall the typical behavior was to see groups of 3-4
MSS-sized TCP segments randomly swizzled.

My experience matches yours re: commercial service on 1xEV-DO, UMTS
and LTE networks.

Best regards,
Keith

---

From: Lennart Schulte <[email-masked]>
Date: Thu, 8 May 2014 10:12:07 +0300

Hi,
while measuring 3G and 4G networks I also saw reordering: 35% of all
connections (12392 in 3G and 676 in 4G) had reordering. In about 2% of
these reordering events the reordering extent was at least 3 packets
large (which caused TCP to spuriously enter fast recovery).

We are currently working on 2 drafts about TCP robustness to reordering,
maybe they are of interest:
- Detection and quantification
  http://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection
- Reaction and prevention
  http://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-reaction

Regards,
Lennart

---

From: Randell Jesup <[email-masked]>
Date: Thu, 08 May 2014 05:14:13 -0400

> large (which caused TCP to spuriously enter fast recovery).

35% doesn't seem surprising.... I presume reordering can/will happen; my 
interest would be amount of reordering, and depth/distribution of 
reordering.  (More than 30-50ms of reordering effectively == loss from 
an RTP standpoint, generally.)  And unless it affects the congestion 
algorithm (which is of concern here), less than jitter depth reordering 
is pretty much "who cares" (maybe not quite, but close).

Also, since the distribution is very uneven, are there networks (3G, 
4G/LTE, WiFi (of various flavors) where this is dramatically more common?

Thanks!

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Stefan Alfredsson <[email-masked]>
Date: Thu, 8 May 2014 14:10:19 +0200

Hi,

> large (which caused TCP to spuriously enter fast recovery).

35% sounds very high. Have you done detailed studies to see if there
is some common property of flows with reordering?

We've done a lot of 3G/4G live measurements, and in one case we saw
a high degree of reordering and TCP resets of many connections,
especially for shorter flows (less than IW10).

After investigation, the cause was found to be prioritization
of small packets by the operator. It only affected
one of four operators in the measurement, all else equal.

One possible explanation can be that the operator wanted to
prioritize e.g. DNS requests or VoIP packets over bulk data
in times of queueing, but not excluding FIN packets
lead to a very inefficient scenario:

Imagine a short flow, fitting in the initial window:

1. TCP connection is setup
2. All data is sent in one window (e.g. 5 kb or such)
3. Sender closes socket, sends FIN.
4. Receiver should acknowledge data, and fully close.

But since small packets were prioritized over the full sized data
segments and all packets were sent back-to-back, the receiver
*gets the FIN before the data segments*. Oops.

The receiver thus SACK's the "missing" (=reordered) data. Reordered
packets then arrive directly afterwards, gets acknowledged, final
FIN is sent, and the connection is fully closed at the receiver.

Meanwhile, the sender gets the SACK, retransmits the reordered segments,
then gets the final FIN (presumably no uplink reordering?; but not
investigated yet).

Receiver now gets the retransmitted segments which arrive at
the now closed socket, and RST packets go back.

This reordering was also seen at the tail of longer flows,
although to a much lesser extent.

I can send packet captures if anyone wants a closer look.

Regards,
 Stefan

-- 
Stefan Alfredsson, PhD         Tel: +46 (0) 54 700 1668
Datavetenskap                  Kontor: 21F-425 (Hus Vanern)
Karlstads universitet          PGP 0xB19B4B16
SE-651 88 Karlstad             http://www.cs.kau.se/stefalfr/

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 May 2014 14:49:09 +0200 (CEST)

On Thu, 8 May 2014, Randell Jesup wrote:

> interest would be amount of reordering, and depth/distribution of reordering. 
> (More than 30-50ms of reordering effectively == loss from an RTP standpoint, 
> generally.)  And unless it affects the congestion algorithm (which is of 
> concern here), less than jitter depth reordering is pretty much "who cares" 
> (maybe not quite, but close).
>
> Also, since the distribution is very uneven, are there networks (3G, 4G/LTE, 
> WiFi (of various flavors) where this is dramatically more common?

I have historically proposed that applications should log these parameters 
as they happen, and provide this information in aggregate or per-session 
basis to present to the user. This is applicable to RTP and it's 
applicable to TCP (and more). As soon as you have sequence numbers you can 
detect this and you can count it.

So while it's not core to this discussion, where is the best place to gain 
traction for suggestion to count and aggregate data on:

Number of packets lost
Number of packets arrived too late (PDV buffer miss)
Number of packets that arrived out of order
Number of packets that arrived out of order and caused PDV buffer miss

If applications actually logged this to operators and users, they might be 
able to understand the problems and have a better understanding of the 
customers quality of experience, and also the user would have better data 
to do a fault report to the operator with.

Basically, packet re-ordering shouldn't happen. Networks that cause 
packets to be re-ordered should know that this causes bad customer 
experience so they can stop. A lot of the time this is done out of 
ignorance.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jim Gettys <[email-masked]>
Date: Thu, 8 May 2014 11:01:16 -0400

On Thu, May 8, 2014 at 8:49 AM, Mikael Abrahamsson <[email-masked]> wrote:

>> reordering. (More than 30-50ms of reordering effectively == loss from an
>> RTP standpoint, generally.)  And unless it affects the congestion algorithm
>> (which is of concern here), less than jitter depth reordering is pretty
>> much "who cares" (maybe not quite, but close).
>>
> basis to present to the user. This is applicable to RTP and it's applicable
> to TCP (and more). As soon as you have sequence numbers you can detect this
> and you can count it.
>

​It isn't just the cellular operators.  It's often going to be your home
network.​

> experience so they can stop. A lot of the time this is done out of

​This is a naive point of view.  First, current TCP implementations are
overly sensitive to reordering (though I believe there has been recent work
in Linux to help this a lot, but it will take a long time before it is
deployed widely enough to help).

Also, remember today at least one hop of your path is likely to be over a
wireless link (lossy, error prone), whether 802.11 or cellular.

This has had a serious unintended follow-on effect.​  Since the
consequences to TCP performance have been so bad, this has encouraged
driver implementers on wireless (of all sorts) to put buffering in the
receive path (needed anyway for aggregation on 802.11n, for example).  In
these situations, the receiver may "freeze" forwarding already received
packets hoping that damaged packets get repaired quickly to avoid
reordering.  But this introduces delays before the packets get released.
 One of the "interesting" bufferbloat discoveries in the Linux WiFi stack,
for example, was discovering that some drivers would try to repair the
damaged packets effectively infinitely, causing spikes up to 1 second.
 And, btw, this kind of problem is rampant in the current generation of
home routers.

And what do you do if you can't repair the packet quickly (e.g. inside of a
single transmit-op)?  The receiver may decide to then forward the packets
in the aggregate you have, but later (on a subsequent transmit opportunity)
the missing packet(s) may be transmitted by the host, thereby causing out
of order delivery.

But I agree completely that if no information is provided to users the
chance of getting anything fixed anywhere is zero.
                                            - Jim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 May 2014 17:33:36 +0200 (CEST)

> wireless link (lossy, error prone), whether 802.11 or cellular.

802.11 and cellular both have their own L2 re-transmit mechanisms, so I 
wouldn't call them lossy.

> And, btw, this kind of problem is rampant in the current generation of

Absolutely, these link layers often try too hard to avoid loss, which 
causes the problems you're describing.

> chance of getting anything fixed anywhere is zero.

I pitched this to the TCP group 5 years back or so, but unfortunately 
there were no takers. People seem to want to do test traffic instead of 
measuring performance for real traffic.

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 8 May 2014 16:09:30 +0000

Hi Jim,

Am 08.05.2014 um 17:01 schrieb Jim Gettys <[email-masked]>:

> 35% doesn't seem surprising.... I presume reordering can/will happen; my interest would be amount of reordering, and depth/distribution of reordering. (More than 30-50ms of reordering effectively == loss from an RTP standpoint, generally.)  And unless it affects the congestion algorithm (which is of concern here), less than jitter depth reordering is pretty much "who cares" (maybe not quite, but close).
> 
> Also, since the distribution is very uneven, are there networks (3G, 4G/LTE, WiFi (of various flavors) where this is dramatically more common?
> 
> I have historically proposed that applications should log these parameters as they happen, and provide this information in aggregate or per-session basis to present to the user. This is applicable to RTP and it's applicable to TCP (and more). As soon as you have sequence numbers you can detect this and you can count it.
> 
> So while it's not core to this discussion, where is the best place to gain traction for suggestion to count and aggregate data on:
> 
> Number of packets lost
> If applications actually logged this to operators and users, they might be able to understand the problems and have a better understanding of the customers quality of experience, and also the user would have better data to do a fault report to the operator with.
> 
> ​It isn't just the cellular operators.  It's often going to be your home network.​
> 
> Basically, packet re-ordering shouldn't happen. Networks that cause packets to be re-ordered should know that this causes bad customer experience so they can stop. A lot of the time this is done out of ignorance.
> 
> ​This is a naive point of view.  First, current TCP implementations are overly sensitive to reordering (though I believe there has been recent work in Linux to help this a lot, but it will take a long time before it is deployed widely enough to help).  

Only as a side note…
Actually, there is a TCP reordering robustness in Linux for years. However, it has weaknesses and performance not very well.
See our TCPM presentation: http://tools.ietf.org/agenda/89/slides/slides-89-tcpm-7.pdf 

Alex

> 
> Also, remember today at least one hop of your path is likely to be over a wireless link (lossy, error prone), whether 802.11 or cellular.
> 
> This has had a serious unintended follow-on effect.​  Since the consequences to TCP performance have been so bad, this has encouraged driver implementers on wireless (of all sorts) to put buffering in the receive path (needed anyway for aggregation on 802.11n, for example).  In these situations, the receiver may "freeze" forwarding already received packets hoping that damaged packets get repaired quickly to avoid reordering.  But this introduces delays before the packets get released.  One of the "interesting" bufferbloat discoveries in the Linux WiFi stack, for example, was discovering that some drivers would try to repair the damaged packets effectively infinitely, causing spikes up to 1 second.  And, btw, this kind of problem is rampant in the current generation of home routers.
> 
> And what do you do if you can't repair the packet quickly (e.g. inside of a single transmit-op)?  The receiver may decide to then forward the packets in the aggregate you have, but later (on a subsequent transmit opportunity) the missing packet(s) may be transmitted by the host, thereby causing out of order delivery.
> 
> But I agree completely that if no information is provided to users the chance of getting anything fixed anywhere is zero.
>                                             - Jim
> 
> 
> 
> --

---

From: Dave Taht <[email-masked]>
Date: Thu, 8 May 2014 09:52:05 -0700

On Thu, May 8, 2014 at 9:09 AM, Zimmermann, Alexander
<[email-masked]> wrote:
>>> reordering. (More than 30-50ms of reordering effectively == loss from an RTP
>>> standpoint, generally.)  And unless it affects the congestion algorithm
>>> (which is of concern here), less than jitter depth reordering is pretty much
>>> "who cares" (maybe not quite, but close).
>>>
>> customers quality of experience, and also the user would have better data to
>> do a fault report to the operator with.
>
>
> It isn't just the cellular operators.  It's often going to be your home
> network.
>>
>>
> This is a naive point of view.  First, current TCP implementations are

And things like mosh & rtp mostly care about the most recent packets.
If packets arrive out of order, the older packets are dropped anyway.
Better that they not be delivered...

and ledbat/quic don't mind packets arriving out of order.

>
> Only as a side note…
> Actually, there is a TCP reordering robustness in Linux for years. However,
> it has weaknesses and performance not very well.
> See our TCPM presentation:
> http://tools.ietf.org/agenda/89/slides/slides-89-tcpm-7.pdf

What version of linux tcp was this taken against? The entire stack has
evolved considerably between linux 3.3 and linux 3.14.

I am aware of a bunch of reordering fixes that went in fairly
recently, and there's some interesting side effects from the new
sch_fq + pacing stuff that I think make re-ordering events less
likely.

Also I note there was a fairly major bug in rx steering for that would
result in ooo packets, induced and fixed back in the 3.8-3.11(?)
timeframe, which might be relevant to an earlier comment on this
thread...

> This has had a serious unintended follow-on effect.  Since the consequences
> to TCP performance have been so bad, this has encouraged driver implementers
> on wireless (of all sorts) to put buffering in the receive path (needed
> anyway for aggregation on 802.11n, for example).  In these situations, the
> receiver may "freeze" forwarding already received packets hoping that
> damaged packets get repaired quickly to avoid reordering.  But this
> introduces delays before the packets get released.

You have several separate, interrelated problems here.

Some drivers will only release the entire aggregate of packets, in
order, and do a lot of retries until they get them all, come hell or
high water.

Others will deliver a later aggregate if it arrives unscathed while
retrying an earlier aggregate.

Few will deliver "good" packets from an aggregate while retrying, and
none I know of do anything other than give up after a long time out,
rather than doing something saner like looking at flows and trying to
ensure at least one packet is delivered from a flow, and dropping the
rest
when there are major problems.

> One of the "interesting"
> bufferbloat discoveries in the Linux WiFi stack, for example, was
> discovering that some drivers would try to repair the damaged packets
> effectively infinitely, causing spikes up to 1 second.  And, btw, this kind
> of problem is rampant in the current generation of home routers.

seen 36+ seconds. http://www.bufferbloat.net/issues/216

a year after we fixed this bug, broadcom found and fixed the same
thing in one of their chipsets.

Millions of devices in the field flooding the airwaves with pointless
retries, with missing firmware updates.

> single transmit-op)?  The receiver may decide to then forward the packets in
> the aggregate you have, but later (on a subsequent transmit opportunity) the
> missing packet(s) may be transmitted by the host, thereby causing out of
> order delivery.
>

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 8 May 2014 19:33:04 +0000

> timeframe, which might be relevant to an earlier comment on this

I think you refer to the comment I made. The anecdotal experience I quoted was with 3.14.

Lars

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 9 May 2014 10:41:51 +0000

> evolved considerably between linux 3.3 and linux 3.14.

I read netdev. I hope I know what’s going on ;-)

> sch_fq + pacing stuff that I think make re-ordering events less

Understood. But I speak here about the reordering detection, quantification
and reaction mechanism in Linux. I’m only aware of one to two recent patches
which fall in this category. This was patch from Yuchung which tries to
still open the cwnd in case of packet reordering.

> thread…

That’s interesting. I have to take a look into.

Alex

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 12 May 2014 09:35:15 -0700

> evolved considerably between linux 3.3 and linux 3.14.

It's in 3.12

http://patchwork.ozlabs.org/patch/268918/
http://patchwork.ozlabs.org/patch/272993/  (bug fix of the previous patch)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 May 2014 18:40:33 +0200 (CEST)

> evolved considerably between linux 3.3 and linux 3.14.

... still no interest in my proposal to keep track of when these events 
are happening? I only saw discussion on how to improve handling of when it 
happens, not to actually count and present these events?

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Mon, 12 May 2014 16:45:36 +0000

Am 12.05.2014 um 18:40 schrieb Mikael Abrahamsson <[email-masked]>:

> ... still no interest in my proposal to keep track of when these events are happening? I only saw discussion on how to improve handling of when it happens, not to actually count and present these events?

netstat -s?

<snip>

UdpLite:
TcpExt:
    54 TCP sockets finished time wait in fast timer
    447 delayed acks sent
    Quick ack mode was activated 2 times
    3651238 packets directly queued to recvmsg prequeue.
    3385392 bytes directly in process context from backlog
    3735300416 bytes directly received in process context from prequeue
    5935 packet headers predicted
    6097108 packets header predicted and directly queued to user
    20251843 acknowledgments not containing data payload received
    11398833 predicted acknowledgments
    3562 times recovered from packet loss by selective acknowledgements
    Detected reordering 6 times using FACK
    Detected reordering 5 times using SACK
    Detected reordering 705 times using time stamp
    2159 congestion windows fully recovered without slow start
    208 congestion windows partially recovered using Hoe heuristic
    1167 congestion windows recovered without slow start by DSACK
    1 congestion windows recovered without slow start after partial ack
    7469 fast retransmits
    3 forward retransmits
    2 other TCP timeouts
    TCPLossProbes: 1
    TCPLossProbeRecovery: 1
    2 DSACKs sent for old packets
    3927 DSACKs received
    TCPDSACKIgnoredNoUndo: 183
    TCPSackShifted: 24503
    TCPSackMerged: 14139
    TCPSackShiftFallback: 32545
    TCPRcvCoalesce: 200
    TCPSpuriousRtxHostQueues: 2
    TCPAutoCorking: 2949971
    TCPSynRetrans: 1
    TCPOrigDataSent: 1031400383

<snap>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 May 2014 19:32:28 +0200 (CEST)

>> ... still no interest in my proposal to keep track of when these events are happening? I only saw discussion on how to improve handling of when it happens, not to actually count and present these…

Sure. How do we present this to the user in a way that they can find 
usable, or helpdesks can find usable? I would like this information per 
destination, per session or some other metric so it can say "oh, it seems 
your connection primarily behaves a certain way, you're seeing a lot of 
*foo*".

---

From: Dave Taht <[email-masked]>
Date: Mon, 12 May 2014 10:48:16 -0700

> I think you refer to the comment I made. The anecdotal experience I quoted was with 3.14.

This was the commit I was referring to, which was introduced and fixed
somewhere between 3.10 and 3.12.

So perhaps you are dealing with a newer issue.

commit 50d1784ee4683f073c0362ee360bfae7a3333d6c
Author: Eric Dumazet
Date:   Sat Sep 7 12:02:57 2013 -0700

    net: fix multiqueue selection

    commit 416186fbf8c5b4e4465 ("net: Split core bits of netdev_pick_tx
    into __netdev_pick_tx") added a bug that disables caching of queue
    index in the socket.

    This is the source of packet reorders for TCP flows, and
    again this is happening more often when using FQ pacing.

    Old code was doing

    if (queue_index != old_index)
        sk_tx_queue_set(sk, queue_index);

    Alexander renamed the variables but forgot to change sk_tx_queue_set()
    2nd parameter.

    if (queue_index != new_index)
        sk_tx_queue_set(sk, queue_index);

    This means we store -1 over and over in sk->sk_tx_queue_mapping

-- 
Dave Täht