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.
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
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
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.
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
Thanks for the
correction. It should be "AP MLD" indeed.
I will fix the
text and upload r6.
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
Can you add SP3 /
DCN11-20-408r5 to the MAC meeting agenda? It's latency related, and we deferred
last time.
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
|