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

Re: [STDS-802-11-TGBI] : Do you think that the change of OTA parameters values shall occur at the same time on each link of a given MLD non-AP STA ?



Thank you Antonio!

I think you raise a great point. If we are working hard to hide the otaMAC, the AID etc., shouldn't we also protect the ML IE? This sounds like an obvious piece that exposes too much data about the STA MLD...
Then, this would bring Stephane's question back to the front burner, if the ML IE is protected somehow, should the STA MLD change all its links at the same time?

Jerome



---- On Mon, 22 Apr 2024 02:27:32 -0400 ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx> wrote ---

Hi Stephane, thanks for initiating this, 
regarding question 1, I fear the multi-link element is sent in all frames and it includes the MLD MAC address, so we need to change simultaneously both links (imho).
Also, (please MLD experts correct me), I think a frame can be retx in any link of the MLD (I would assume that you need to redo the header of it), therefore we also need to make sure that the epoch durations are the same in both links, so we go in the direction of changing simultaneously all links in an MLD. 
Another thought is, if we have different bands, maybe one band is way slower than the other, and this may affect the time we need to wait for frames in a buffer to be sent. So we need to be careful in the epoch time selection, so all buffered frames in all links have enough time to be transmitted.

Br
Antonio

El lun, 22 abr 2024 a las 8:19, BARON Stephane (<Stephane.BARON@xxxxxxxxxxxx>) escribió:

Hi Carol,

 

Thank you for sharing your thought.

 

I think we have two questions now:

 

  1. Shall all the MLDs of a given group initiate a change their OTA values on all links at the same time ? I think yes.

This is the original purpose of the SP I would like to run, since I think this is an important point to solve.

On one hand, this indicates correlation between links (revealing the MLD structure, but this info is also available in clear in the ML IE in beacons).

On the other hand, this avoid correlation between Old and new OTA values across links, and contribute to the mass effect to hide a STA in the crowd.  

 

  1. What happens to the buffered traffic when Epoch start occurs (on both AP and non-AP side)?

I think this question is related to the handling of transition period, but of course transition period and Epoch start are linked.

I my mind, as written in the D0.3, each Epoch starts with a transition period.

Assuming all the non-AP MLD of a given group starts a new Epoch at the same time (TSF counter based), all the non-AP STA, associated to a non-AP MLD registered to a given EDP Epoch group, starts a new Epoch at the same time.

This new Epoch starts with a transition period that allow transmission of buffered frames using Old OTA values (currently only retransmissions in D0.3, but we can discuss that ), and New OTA values without mixing them in a same TxOP (to avoid correlation).

At the end of the transition, a non-AP STA is not allowed to used old OTA values for transmission of any frames, nor decode received frames using old OTA values. So if the STA still has some retransmission using OLD OTA values waiting for transmission, those frames should be flushed.

 

For transition period I think we can discuss using 11-23/1148r0 (slide 7 and 8) as support. I can (re)present it next session if needed.

 

Stéphane.

  

 

From: Carol Ansley <carol@xxxxxxxxxx>
Sent: vendredi 19 avril 2024 23:02
To: STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBI] : Do you think that the change of OTA parameters values shall occur at the same time on each link of a given MLD non-AP STA ?

 


BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment.

 

Hello Jerome and Stephane and everyone,

 

While I agree that to avoid an observer being able to use the changeover to glean more information about the MLDs, at the same time, we need to consider how to word the text for clarity.

 

For example, If an MLD has a full queue of packets waiting to go out on its 5GHz link as the current epoch ends, do the other links in the MLD wait to start using the new information until the 5GHz link finishes sending the old information?  What about the other MLDs in the Epoch group?  To say it another way, do all of the buffers on all of the links need to be purged before the new headers and numbers start being used?

 

What happens on the AP side?  Does the AP MLD need to discard any packets that are still in a queue at the end of an epoch or rework them once the new epoch time is reached? Or does it just finish blasting them all out with the old information until it gets to the next epoch’s packets?

 

Thinking about what can be seen on the air – the SN/PN sequences shared across the link of an MLD unfortunately can be used to connect those links to a single MLD.  As long as one of the affiliated STAs is still using the old parameters, an observer knows that MLD is still there.

 

Is this straw poll intended to ask about what a single MLD does across its affiliated STAs, or what all of the MLDS in that Epoch group will do?

 

Regards,

Carol

 

From: Jerome Henry <jhenry@xxxxxxxx>
Date: Wednesday, April 17, 2024 at 1:23 PM
To: STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBI] : Do you think that the change of OTA parameters values shall occur at the same time on each link of a given MLD non-AP STA ?

Hi Stephane,

 

Thanks a lot for starting this exchange. I think that if elements about the MLD are visible on both links, then we have no choice but change at the same time. If the common elements (e.g. MLD address) are hidden, then there is only a weaker need to change all links at the same time. Quite obviously, the simultaneity of these changes can be used to spot a STA (2 MACs change on 2 links at the same time -> it's the same STA device). If we go that direction, I would recommend implementing your +/- rand interval method with different values for each link, to avoid this simultaneity.

 

My 2 cents!

 

Jerome

 

 

 

---- On Fri, 12 Apr 2024 10:21:36 -0400 BARON Stephane <stephane.baron@xxxxxxxxxxxx> wrote ---

 

Hi everybody,

 

During the last TGbi teleconference, one question was raised and some members expressed the need to discuss this question on the reflector, so here is the starting point of this thread.

 

The question is : “Do you think that the change of OTA parameters values (like MAC address, AID, SN, PN, etc.) shall occur at the same time on each link of a given MLD non-AP STA ?”

 

The plan is to be able to run this SP or a similar one during next TGbi session on April 17th, and to collect opinion on this subject in the meantime.

 

 

My personal opinion is that, yes, we need to do this to avoid easy correlation between old and new OTA values if some old and new OTA values are used for the same parameter on different links (for instance, MLD level parameters like the AID).

 

The discussion is now open.

 

Best regards.

 

Stéphane.

 

 



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

 

 



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



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


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



--
Antonio de la Oliva
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax:   +34 91 624 8749



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




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