Re: [Raw] Montréal and Chartering

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Dave

From: Cavalcanti, Dave <[e-mail]>
Sent: mardi 7 mai 2019 20:44
To: Pascal Thubert (pthubert) <[e-mail]>; Grossman, Ethan A. <[e-mail]>; Xavi Vilajosana Guillen <[e-mail]>
Cc: [e-mail]; Lou Berger ([e-mail]) <[e-mail]>
Subject: RE: [Raw] Montréal and Chartering

Hi Pascal,

Thanks for the clarifications and please see my responses in line.


Best,
Dave

From: Raw [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, May 07, 2019 8:37 AM
To: Cavalcanti, Dave <[e-mail]<mailto:[e-mail]>>; Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>; Xavi Vilajosana Guillen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Lou Berger ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Raw] Montréal and Chartering

Hello Dave:

Please see below:


According to the current scope, the RAW layer is to enable establishment and management of time-sensitive flows (data flows with certain QoS needs) over wireless networks. This process may include several steps:

  1.  The RAW layer will provide the QoS requirements of a RAW flow (e.g. in some form of time constraints metrics, reliability/redundancy metrics, etc …) to the radio layer, which will be used as input to some form of admission control.


Ø   I’m not sure it is a layer per se. More of a management interface. A RAW-capable controller manages an end-to-end flow that traverses a particular wireless hop.

Ø   The controller must talk to the intelligence that drives the abstract AP to allocate  a periodic resource for the flow. Compared to DetNet/CCAMP, RAW would provide additional control parameters like “up to 5 retries, max latency all retries included is blah, please provide frequency diversity for the retries”.

[DC] One option is for the RAW controller to configure some of the radio parameters that will impact QoS (e.g. retries, max latency, etc). It would be good to have a way to describe diversity/reliability requirements from the RAW side that is independent of the radio layer implementation. The RAW controller may not have enough information to decide that frequency diversity is the best option to be used. The AP has better knowledge of the network and it can decide what type of diversity it can provide to a certain flow in order to meet the target requirement. If the AP can provide the required reliability with link adaptation or time diversity, for instance, it should be able to make the best choice.  There are different ways to get diversity (frequency, time, space), and it would be good to abstract that at the RAW
layer, and let the radio decide what option to use.

PT >> Agreed. The controller owns DetNet-service level diversity (e.g. path redundancy and coding at the source), could control some time diversity, and may only abstractly suggests other forms that are in the Layer-2 domain. It may or may not know which diversity the radio can do and what works best for it (this could be offloaded from the AP or not). If it does not know we need an abstraction of the results that are expected (e.g., loss ratio and deadline).




Ø   It gets more hairy when doing replication. The controller might say “send a replicated frame to STA 1 and STA 2”. Might turn out that STA 1 and STA 2 are on the same or different APs – hopefully they do not roam, when that happens is next problem. How do we model that? Should there be a DetNet between AP1 and AP2 and AP1 does replication? Or should the previous switch called SW replicate? In which case APs do not do any DetNet service layer?

[DC] I assume that packet replication will be done at a layer above the radio (MAC/PHY). Is it part of RAW or another higher layer? With this assumption, the radio layer (AP) would get two packets from the higher layer addressed to two STAs (STA 1 and STA 2) and it would just try to deliver the packets while meeting the RAW diversity requirements.

PT >> It is RAW service sub-layer, and it may be a waste of resources if both STAs could capture the same transmission by one AP. The other way around, a single transmission of a packet by a STA may be received by 2 APs, one acting as a shadow of the other in order to combat effects of location such as interferers near the AP or multipath fading. Even if Wi-Fi does not have that model, other standards such as ISA100.11a already do. And maybe all this is a potential topic for EHT to work on.






Ø   Well RAW may know how a particular technology schedules its resources in details, that was the discussion in this Thread. i.e., RAW may not control the allocation of resource blocks / subchannels. But maybe it can still ask for something more specific than a meaningless QoS of 5. The abstraction might be half specific like 5 tries or more abstract like 99.99 reliability, either way with a deadline in time. We have to define that based on what APIs the technologies are willing to  open. We need you in the room for that!

[DC] It is not very clear what you mean by knowing how a particular technology schedules its resources in details. For instance, RAW may know that an 802.11ax network operates with a certain channel bandwidth, OFDMA mode, available RU sizes, etc. Similar information for a 5G network, e.g. URLLC mode is enabled. But the resource allocation strategies will be a black box (implementation specific). We can look into opening additional information, such as bounded latency, packet error rates, etc.


PT >> This is what I meant. In TSCH those functions could be offloaded to the controller. We want to start working on the former but in a way that can be extended for the latter.?


All the best,

Pascal