Subject: [rtcweb] DSCP marking for STUN packets

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 7 Mar 2014 04:35:11 +0000

ICE says that an endpoint SHOULD apply the same DSCP marking as media packets to connectivity checks. This looks insufficient for RTCWEB, since it doesn't cover (at least) the following:
- connectivity checks performed for a stream using different drop pecedences (draft-dhesikan-tsvwg-rtcweb-qos).
- connectivity checks performed for non-media/data-channel traffic.
- DSCP markings for consent checks.

Comments on where we need to specify them? The last one can probably go into draft-ietf-rtcweb-stun-consent-freshness?

Muthu

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Mar 2014 05:16:23 +0000

I think that the existing guidance should be sufficient in non-multiplexing
cases (i.e. BUNDLE). For consent checks, I think the same DSCP markings as
any other ICE connectivity checks should be used; for ICE-for-SCTP checks,
the same DSCP markings as media packets (i.e. the SCTP traffic) should be
used.

If multiplexing is being performed, the connectivity checks probably should
use the highest DSCP value being used by the multiplexed media.

On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

>  ICE says that an endpoint SHOULD apply the same DSCP marking as media
> packets to connectivity checks. This looks insufficient for RTCWEB, since
> it doesn't cover (at least) the following:
>
> - connectivity checks performed for a stream using different drop
> pecedences (draft-dhesikan-tsvwg-rtcweb-qos).
>
> Comments on where we need to specify them? The last one can probably go
> into draft-ietf-rtcweb-stun-consent-freshness?
>
>
>
> Muthu
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 10 Mar 2014 08:36:22 +0000

|I think that the existing guidance should be sufficient in non-multiplexing
|cases (i.e. BUNDLE).

I don't think so. Even for non-multiplexing cases, a same stream could use different drop precedence for different packets, as described in draft-dhesikan-tsvwg-rtcweb-qos

   The combination of priority input and multiple precedence levels
   within a data class provides flexibility for an implementation in
   deciding the importance of the stream and packets within a stream.
   For example, if I frames are more important than the P frames then
   the I frames can be marked with a DSCP with the lower drop
   precedence.

My take is that STUN connectivity/consent checks SHOULD use the lowest drop precedence within a given data type and priority.

|For consent checks, I think the same DSCP markings as any other ICE connectivity
|checks should be used.

Agree.

|If multiplexing is being performed, the connectivity checks probably should
|use the highest DSCP value being used by the multiplexed media.

For multiplexed media, I guess there is no WG consensus on how to mark the stream, yet (draft-ietf-mmusic-sdp-mux-attributes lists two possible options). But, I agree with your proposal in general, since these STUN packets are a kind of (media path) signaling packets and signaling packets are generally given higher priority..

Muthu

From: Justin Uberti [mailto:[email-masked]]
Sent: Monday, March 10, 2014 10:46 AM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [rtcweb] DSCP marking for STUN packets

I think that the existing guidance should be sufficient in non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the same DSCP markings as any other ICE connectivity checks should be used; for ICE-for-SCTP checks, the same DSCP markings as media packets (i.e. the SCTP traffic) should be used.

If multiplexing is being performed, the connectivity checks probably should use the highest DSCP value being used by the multiplexed media.

On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]<mailto:[email-masked]>> wrote:

Muthu

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Dave Taht <[email-masked]>
Date: Mon, 10 Mar 2014 08:51:36 +0000

In all this talk about drop precedence and so on I'd like to point people
at some details of some currently deployed packet scheduling and aqm
systems.

http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html
On Mar 10, 2014 1:36 AM, "Muthu Arul Mozhi Perumal (mperumal)" <
[email-masked]> wrote:

> I don't think so. Even for non-multiplexing cases, a same stream could use
> different drop precedence for different packets, as described in
> draft-dhesikan-tsvwg-rtcweb-qos
>
>
>
> My take is that STUN connectivity/consent checks SHOULD use the lowest
> drop precedence within a given data type and priority.
>
>
>
> For multiplexed media, I guess there is no WG consensus on how to mark the
> stream, yet (draft-ietf-mmusic-sdp-mux-attributes lists two possible
> options). But, I agree with your proposal in general, since these STUN
> packets are a kind of (media path) signaling packets and signaling packets
> are generally given higher priority..
>
>
>
> Muthu
>
>
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Monday, March 10, 2014 10:46 AM
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] DSCP marking for STUN packets
>
>
>
> I think that the existing guidance should be sufficient in
> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the same
> DSCP markings as any other ICE connectivity checks should be used; for
> ICE-for-SCTP checks, the same DSCP markings as media packets (i.e. the SCTP
> traffic) should be used.
>
>
>
> If multiplexing is being performed, the connectivity checks probably
> should use the highest DSCP value being used by the multiplexed media.
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 15:24:39 +0100

Hi,
(as individual)

I think we need to start with what the goals are with the STUN packets.

In the initial connectivity establishment of ICE the purpose is to find
paths that works. To make that determination at all, I would argue to
maximize success one should use best effort markings as the network is
least likely to do something strange with such packets, including
dropping them for violating policy (even if they should just be
downgraded).

If one like to use STUN to determine the possibility to get DSCP != BE
packets through the network from a peer to peer perspective, then I
think one should consider specifying something like the STUN ECN check
options that are documented in Section 7.2.2 in RFC 6679.

To summarize, this sends an additional round of STUN packets after a
working path has been found to check ECN compliance in this path. It
includes and option indicating the ECT value entered, and the receiver
echoes the received value back. Thus enabling a sender to determine that
the path is ECT.

Something similar could be specified if desired to determine that at
least the network doesn't drop packets with DSCP != BE.

For consent freshness I don't think we need to do that on a per traffic
marking type level. Thus, the important is that it reaches the peer. And
the packet reaching the just needs to be statistically high enough
probability over a sequence of checks. Thus, I would say that the only
important factor here is to not mark it so that it has significant
higher drop probability. It also don't need to be minimal delay, thus EF
appears overkill and although AFx could be used, that should rather be
based on a traffic mix with a lot of AFx traffic.

In the end, it might be easier to not use other DSCP marking that BE for
the STUN, simple because it gives the most robust behavior and not
subject to network issues due to policing or DSCP remarking.

I think it will be important to take the considerations for using
multiple DSCP on the same 5-tuple that DART will document into account
here.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: James Polk <[email-masked]>
Date: Mon, 10 Mar 2014 15:57:09 -0500

At 12:16 AM 3/10/2014, Justin Uberti wrote:
>non-multiplexing cases (i.e. BUNDLE). For consent checks, I think 
>the same DSCP markings as any other ICE connectivity checks should 
>be used; for ICE-for-SCTP checks, the same DSCP markings as media 
>packets (i.e. the SCTP traffic) should be used.
>

why is (seemingly) everyone's default position "use the highest DSCP 
available" for signaling packets?

You just need to make sure the packets aren't starved or dropped 
by/at congestion points.

James

>On Fri, Mar 7, 2014 at 4:35 AM, Muthu Arul Mozhi Perumal (mperumal) 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>ICE says that an endpoint SHOULD apply the same DSCP marking as 
>media packets to connectivity checks. This looks insufficient for 
>RTCWEB, since it doesn't cover (at least) the following:
>
>Comments on where we need to specify them? The last one can probably 
>go into draft-ietf-rtcweb-stun-consent-freshness?
>
>
>
>Muthu
>
><mailto:[email-masked]>[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Mar 2014 10:02:20 -0400

Le 2014-03-10 16:57, James Polk a écrit :
>> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the
>> same DSCP markings as any other ICE connectivity checks should be
>> used; for ICE-for-SCTP checks, the same DSCP markings as media packets
>> (i.e. the SCTP traffic) should be used.
>>
> You just need to make sure the packets aren't starved or dropped by/at
> congestion points.

The underlying principle is that connectivity checks need to *check
connectivity* (duh!). That's why you use the same DSCP as the media.
Connectivity is affected by the DSCP. For example some DSCPs could be
filtered, or could be placed in a low-priority queue and get dropped
such that connectivity fails.

>From this principle follows this conclusion: on a given 5-tuple, if your
media uses different DSCPs, you need to check connectivity for all those
DSCPs. That is, you would send multiple connectivity checks, one for
each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might
need an alternative heuristic: try the lowest-priority DSCP, and assume
that if that one works, the higher-priority ones should work as well.
(Note that Justin suggested the contrary.)

What you want to avoid is STUN packets getting through but not the
corresponding media. That is an unworkable situation. The reverse is not
ideal either (you think you have no connectivity when in fact you do),
but at least ICE can work around it (by picking a different candidate).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Mar 2014 15:43:54 +0100

> but at least ICE can work around it (by picking a different candidate).

This explanation makes sense for (ICE) connectivity checks.

For other control information, especially information about delay, you 
want to have it delivered as fast as possible, and with as little loss 
as possible, because jitter in the return path will make the delay 
signal more noisy, and lost packets may cause drastic actions like those 
the circuit-breakers draft recommends.

Whether that always translates to "the highest DSCP code point" is .... 
a good question.

---

From: Dave Taht <[email-masked]>
Date: Tue, 11 Mar 2014 17:17:51 +0000

> For other control information, especially information about delay, you
want to have it delivered as fast as possible, and with as little loss as
possible, because jitter in the return path will make the delay signal more
noisy, and lost packets may cause drastic actions like those the
circuit-breakers draft recommends.
>
> Whether that always translates to "the highest DSCP code point" is .... a
good question.

It doesn't.  Keith added af42 support to mosh last year and had several
reports of packets being dropped with that marking. Worse the drops
happened after 10 seconds of connectivity.

Ecn markings on the other hand have thus far survived (if occasionally
stomped on) across the open internet in that protocol.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 20:53:11 -0700

> but at least ICE can work around it (by picking a different candidate).

We also need to consider the scenario of STUN consent checks, which will
need to get through reliably even when media marked with DSCP is already
flowing. In this case I think that using the highest DSCP value for STUN is
unavoidable.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 20:55:20 -0700

> stomped on) across the open internet in that protocol.

This is a concern of mine as well, which is why we haven't yet flipped the
switch to turn DSCP on by default in Chrome. I think we'll need to do some
experimentation to see how often DSCP makes things worse.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Mar 2014 09:03:20 +0100

On 2014-03-12 04:53, Justin Uberti wrote:
> 
> 
> 
> On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> flowing. In this case I think that using the highest DSCP value for STUN
> is unavoidable.
> 

(as individual)

Sorry, I don't understand your reasoning here. Is it to provide the
lowest possible drop probability, i.e. using the AFx class that has
least drop probability?

If there exist nodes that stomp on some DSCP markings, and not only
remark them to Best Effort (BE), and instead drop then. Then, it is not
obvious that that an AFx class is the most appropriate to use. In that
case using BE might be more suitable for the consent freshness.

I would also point out that highest DSCP value isn't clear. We are
talking about forwarding behavior and I don't see how Expedited
Forwarding (EF) can be compared with AF for example.

I think we have to consider what our goals are here. To determine if we
can get any packets through or determine if a particular 6-tuple (Source
Address, Destination Address, Source Port, Destination Port, Protocol,
and DSCP value) works? If it is the later then I think we need to have
checks running on all the 6-tuples in use. This clearly have overhead
concerns and helps worsening the ICE The Voice Hammer Attack (See
section 18.5.1. of RFC 5245).

If the goal is the first, isn't using BE a reasonable choice. Yes, it
might have higher drop probability than AF, but it is likely to be
robuster in general deployments and it determine if the peer is there or
not. Dealing with broken 6-tuples needs to be a separate issue.

Cheers

Magnus Westerlund

---

From: Dave Taht <[email-masked]>
Date: Wed, 12 Mar 2014 08:35:29 +0000

>> reports of packets being dropped with that marking. Worse the drops happened
>> after 10 seconds of connectivity.
>>

Well, while I'm at this, I note that how linux handles DSCP in WIFI 802.11e
is generally suboptimal. the CS6 and CS7 bit patterns map to the VO
queue which is not aggregatable in wireless-n, CS4 and CS5
map to the VI queue which has a lot of good properties for videoconference
and voice traffic (but limited aggregation), and CS1 and CS2, which map
to the background queue, which has good aggregation but limited txops.

I no longer have the bit patterns for AFxx memorized, but basically
all that was returned to the 802.11e classifier was dscp >> 5 up until very
recently. Lastly, there really is no interpretation whatsoever of the AF
classes equating to "drop probability" in wifi (at least in lnux), they merely
control queue selection and

it is generally better with wireless-n to aim for better aggregation in
one queue rather than using multiple queues as the cost of acquiring
the media dominates.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 12 Mar 2014 09:06:12 +0000

I think we are discussing two different problems:
1. Determining what DSCP actually works over the Internet, by using ICE.
2. For one or more DSCPs an endpoint uses for a traffic flow, what DSCP ICE needs to use.

In the case of #2, the endpoint uses those DSCPs because the network is provisioned that way by the network admin or the service provider. This could possibly be achieved through a combination of some browser configuration and JS input. For this case, using the highest DSCP value among those that are used for a given media or data-channel flow for ICE connectivity/consent checks makes sense to me.

On this other hand, #1 looks a bigger problem. In the absence of any information, starting with BE or not setting anything in the packet looks a good option to me.

Muthu

|-----Original Message-----
|From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus Westerlund
|Sent: Wednesday, March 12, 2014 1:33 PM
|To: Justin Uberti; Simon Perreault
|Cc: [email-masked]
|Subject: Re: [rtcweb] DSCP marking for STUN packets
|
|On 2014-03-12 04:53, Justin Uberti wrote:
|>
|>
|>
|> On Tue, Mar 11, 2014 at 7:02 AM, Simon Perreault
|> <[email-masked] <mailto:[email-masked]>> wrote:
|>
|>     Le 2014-03-10 16:57, James Polk a écrit :
|>     > At 12:16 AM 3/10/2014, Justin Uberti wrote:
|>     >> I think that the existing guidance should be sufficient in
|>     >> non-multiplexing cases (i.e. BUNDLE). For consent checks, I think the
|>     >> same DSCP markings as any other ICE connectivity checks should be
|>     >> used; for ICE-for-SCTP checks, the same DSCP markings as media
|>     packets
|>     >> (i.e. the SCTP traffic) should be used.
|>     >>
|>     >> If multiplexing is being performed, the connectivity checks probably
|>     >> should use the highest DSCP value being used by the multiplexed
|>     media.
|>     >
|>     > why is (seemingly) everyone's default position "use the highest DSCP
|>     > available" for signaling packets?
|>     >
|>     > You just need to make sure the packets aren't starved or dropped by/at
|>     > congestion points.
|>
|>     The underlying principle is that connectivity checks need to *check
|>     connectivity* (duh!). That's why you use the same DSCP as the media.
|>     Connectivity is affected by the DSCP. For example some DSCPs could be
|>     filtered, or could be placed in a low-priority queue and get dropped
|>     such that connectivity fails.
|>
|>     >From this principle follows this conclusion: on a given 5-tuple, if
|>     your
|>     media uses different DSCPs, you need to check connectivity for all those
|>     DSCPs. That is, you would send multiple connectivity checks, one for
|>     each DSCPs in the set used on this 5-tuple. Yeah, it sucks, so we might
|>     need an alternative heuristic: try the lowest-priority DSCP, and assume
|>     that if that one works, the higher-priority ones should work as well.
|>     (Note that Justin suggested the contrary.)
|>
|>     What you want to avoid is STUN packets getting through but not the
|>     corresponding media. That is an unworkable situation. The reverse is not
|>     ideal either (you think you have no connectivity when in fact you do),
|>     but at least ICE can work around it (by picking a different candidate).
|>
|>
|> We also need to consider the scenario of STUN consent checks, which will
|> need to get through reliably even when media marked with DSCP is already
|> flowing. In this case I think that using the highest DSCP value for STUN
|> is unavoidable.
|>
|
|(as individual)
|
|Sorry, I don't understand your reasoning here. Is it to provide the
|lowest possible drop probability, i.e. using the AFx class that has
|least drop probability?
|
|If there exist nodes that stomp on some DSCP markings, and not only
|remark them to Best Effort (BE), and instead drop then. Then, it is not
|obvious that that an AFx class is the most appropriate to use. In that
|case using BE might be more suitable for the consent freshness.
|
|I would also point out that highest DSCP value isn't clear. We are
|talking about forwarding behavior and I don't see how Expedited
|Forwarding (EF) can be compared with AF for example.
|
|I think we have to consider what our goals are here. To determine if we
|can get any packets through or determine if a particular 6-tuple (Source
|Address, Destination Address, Source Port, Destination Port, Protocol,
|and DSCP value) works? If it is the later then I think we need to have
|checks running on all the 6-tuples in use. This clearly have overhead
|concerns and helps worsening the ICE The Voice Hammer Attack (See
|section 18.5.1. of RFC 5245).
|
|If the goal is the first, isn't using BE a reasonable choice. Yes, it
|might have higher drop probability than AF, but it is likely to be
|robuster in general deployments and it determine if the peer is there or
|not. Dealing with broken 6-tuples needs to be a separate issue.
|
|Cheers
|
|Magnus Westerlund
|
|----------------------------------------------------------------------
|Services, Media and Network features, Ericsson Research EAB/TXM
|----------------------------------------------------------------------
|Ericsson AB                 | Phone  +46 10 7148287
|Färögatan 6                 | Mobile +46 73 0949079
|SE-164 80 Stockholm, Sweden | mailto: [email-masked]
|----------------------------------------------------------------------
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 09:05:08 -0700

On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund <
[email-masked]> wrote:

> the
> by/at

The idea is to have the same drop probability as the most critical media
that is flowing (e.g. voice), so that we don't end up in a situation where
media flows fine, but the media crowds out STUN consent check packets,
leading to call failure.

> case using BE might be more suitable for the consent freshness.

If nodes stomp on certain AF-marked packets, and this is widespread, this
essentially dooms use of DSCP at all, unless we want to build some
sophisticated detection and fallback mechanism. IOW, it's not clear to me
that marking packets as BE confers any value over not marking at all.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Mar 2014 13:40:59 +0100

On 2014-03-12 17:05, Justin Uberti wrote:
>
> On Wed, Mar 12, 2014 at 1:03 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 

> that is flowing (e.g. voice), so that we don't end up in a situation
> where media flows fine, but the media crowds out STUN consent check
> packets, leading to call failure. 

Okay, that makes a certain sense. First of all this is not likely to
have the "highest" DSCP value. In fact it might not have the lowest drop
probability either. But, yes it might be prioritized over BE. This is
assuming that this DSCP marking do work and doesn't prevent the 6-tuple
to work. But lets take this as a separate issue.

> If nodes stomp on certain AF-marked packets, and this is widespread,
> this essentially dooms use of DSCP at all, unless we want to build some
> sophisticated detection and fallback mechanism. IOW, it's not clear to
> me that marking packets as BE confers any value over not marking at all.

BE is no marking at all, i.e. DSCP = 0. But, I wanted to be clear that I
really meant best effort.

But, the question is what we do about nodes that not simple down mark
DSCP code points !=0. I see some potential solutions.

1) We recommend that one track the loss rates the different DSCP
markings individually and in cases when loss rates for some markings
doesn't match the expected relative behavior between different markings,
then one stops using DSCP markings and send everything as BE.

2) One expands the initial STUN exchange to a second round after
nomination to verify the DSCP code points that one intended to use is
not being blocked.

The alternative to do something is to ignore the issue. It might be
small enough that it isn't significant. I don't have data on this. If
someone has any data source it would be appreciated if they share.

Cheers

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Thu, 13 Mar 2014 09:15:15 -0700

> someone has any data source it would be appreciated if they share.
We could perform an experiment to determine how often this occurs in real
life. I was thinking about having clients send STUN requests with different
DSCP markings to a STUN server, and then analyzing the success rate. Open
to other ideas though.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Mar 2014 22:25:52 +0100

> to the background queue, which has good aggregation but limited txops.
That sounds like a Linux bug.... I would expect this translation to be 
done via lookup tables, not copying one field into another with 
different semantics (with or without bit-shift).

---

From: Dave Taht <[email-masked]>
Date: Fri, 14 Mar 2014 05:32:34 -0700

On Thu, Mar 13, 2014 at 2:25 PM, Harald Alvestrand <[email-masked]> wrote:
> That sounds like a Linux bug.... I would expect this translation to be done

That has existed since 802.11e was standardized in 2005.

> via lookup tables, not copying one field into another with different
> semantics (with or without bit-shift).

The diffserv codepoint IS preserved however it is classified into an 802.11e
queue based on the top 3 bits up until recently.

In linux 3.14 and later there is an optional classifier that does a diffserv
lookup to 802.11e queue translation.

These queues determine txop scheduling and bandwidth characteristics,
not drop probability.

http://en.wikipedia.org/wiki/IEEE_802.11e-2005#802.11e_MAC_protocol_operation

In some versions of cerowrt I have obsoleted the VO queue entirely,
pushed several AFxx markings into the VI queue, and respected
background markings to push them into the BK queue, and am working
on something that will try to maximize txops and aggregation by
"pushing" traffic into better queues when needed.

>> control queue selection and

I am not aware of any OS that translates AFxx markings into drop
probability directly on wifi.

-- 
Dave Täht