Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE]

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

On Sun, Jun 28, 2020 at 8:10 PM Dick Roy <dickroy@xxxxxxxxxxxx> wrote:

Just to be clear … links are NOT latency sensitive, some of the applications that use those links are. Saying a link is latency sensitive makes no sense.

RR

From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Sent: Sunday, June 28, 2020 2:10 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] SP-3 408r5

Hi, RR, Jay:

Thanks for your comments.

The latency sensitive link here is meant to differentiate the service that the AP intends to provide over such links versus others; rather than classifying the traffic run over the links or characterizing the traffic load.

In order to provide the service, the channel access mechanism, for one, can be different from other links. Also, some additional supporting mechanisms e.g. traffic stream classification, might be needed as well. These jointly define a set of policies exercised over such links.

Hope this answers your questions. Welcome for further comments.

Thanks.

Chunyu

On Sun, Jun 28, 2020 at 7:09 AM Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:

Hi Chunyu,

I have a similar question on the concept of “Latency Sensitive Link”, How to measure and decide whether a link is a latency sensitive or not?

I think it comes down to two things: Channel load and OBSS congestion. As you can see, both of them are dynamic factors. That’s to say, low latency link may become non-low latency link in some scenarios, and vice versa. For instance, if put more low latency streams on the “Latency Sensitive Link”, it may can’t meet the criteria of “Latency Sensitive” at the moment.

Thanks

Best Regards

Jay Yang

From: Dick Roy <dickroy@xxxxxxxxxxxx>
Sent: 2020年6月28日 8:16
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] SP-3 408r5

802.11 links are NOT latency sensitive. Links “have” properties such as “low latency”, however they are never sensitive to that property. Try to imagine what sensitivity to latency would mean below layer 3!

That said, the properties of such links ARE sensitive to (aka “are a function of”) external environmental factors such as load on the channel (aka congestion). That’s why there are “priorities” … so that when necessary and appropriate, some links can “move to the head of the queue” and thereby the system can offer some form of QoS. What it appears is going on is the use of multiple links to add more capabilities to offer QOS at some level. Instead of just using EDCA (DCF) and 4 queues of different priority, more links presumably with different EDCA parameters for each queue are added to the mix, and the AP STA has more resources to attempt to provide a level of QoS to its STAs. It doesn’t do this over “latency sensitive links” however. It does it using multiple resources (links and queues on those links) and “intelligent” resource allocation. Naturally, if this is NOT the intent, please ignore this email :^))))

If the plan is to establish something other than a “traditional” 802.11 link (repleat w/ DCF, etc.), then give it a name that contains some identifying characteristis of that “new link type”. Otherwise, Dmitry is probably right in suggesting that you really do not need a new name.

My two cents …

RR

From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Sent: Saturday, June 27, 2020 4:47 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] SP-3 408r5

Hi, Dmitry:

Good question. Yes or No.

As explained in the contribution, we think it's necessary to exercise some set of management/policies and channel access rules that are different from regular traffic (versus latency sensitive traffic). Hence the differentiation among links.

If we don't have such a definition, we may eventually come up with something like "a link where certain operations and configurations are conducted to optimize for latency sensitive applications" every time we need to mention such a link.

The intention of the SP is to provide such a term.

Please let me know if you or anyone has further questions.

Thanks.

Chunyu

On Mon, Jun 22, 2020 at 3:17 PM Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:

Hi Chunyu,

I have a general question – what changes in your contribution if you don’t have a definition of “Latency Sensitive link”?

You slide 9 says:

Define an operating mode in MLO, where

AP MLD, based on association and traffic dynamics, can steer latency sensitive traffic over a subset of links using a suitable configuration (details TBD)

If AP see TSN traffic(s) it , in first place, have to have a tool/mechanism to either steer/group such traffic(s) in one link or steer non-TSN traffic to another link.

Example#1 on slide 26 seems to confirm that. Even more, in this example links at the beginning

It won’t matter at the end if such link named as “Just link” or “Latency Sensitive Link”, right?

Dmitry

From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Monday, June 22, 2020 2:47 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] SP-3 408r5

Hi, Dibakar,

Thanks for the correction. It should be "AP MLD" indeed.

I will fix the text and upload r6.

Thanks.

Chunyu

On Mon, Jun 22, 2020 at 2:31 PM Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:

Hi Chunyu,

I had a question on the SP text. The SP says:

“A definition of Latency Sensitive Link in Multi-Link Operation as a link over which the AP defines TBD QoS mechanisms to provide the latency sensitive traffic streams improved latency and reliability performance”

Do you mean an “AP” or an “AP MLD” ?

Regards,

Dibakar

From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Monday, June 22, 2020 10:54 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconference [06/22/2020: Agendas Posted

Hi, Alfred:

Can you add SP3 / DCN11-20-408r5 to the MAC meeting agenda? It's latency related, and we deferred last time.

Thanks.

Chunyu

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1