search

SpencerDawkins / net-collab-rqmts

Other
1 stars 0 forks source link

Prioritizing flows from the same host #50

Closed tireddy2 closed 4 weeks ago

tireddy2 commented 4 weeks ago

Prioritizing flows from the same host is also error-prone because the network cannot distinguish between legitimate and malicious flows. For example, a poorly written application might request the highest priority for its flows, which could be unjustified. Additionally, it is challenging to identify whether the traffic belongs to a single user or multiple users, such as in tethering scenarios. Therefore, I propose focusing solely on "intra-flow" prioritization. Both WebRTC and QUIC, multiplex multiple streams on the same 5-tuple.

sridharangirish91 commented 4 weeks ago

Should we maybe add text to the inter flow section saying "Due to these challenges, inter flow is out of scope of this document."?

boucadair commented 4 weeks ago

@tireddy2, please see the discussion in https://github.com/SpencerDawkins/net-collab-rqmts/pull/33 for the reasoning to include this in the first version.

tireddy2 commented 4 weeks ago

@tireddy2, please see the discussion in #33 for the reasoning to include this in the first version.

Yes, I saw the discussion but I am not convinced how the network can distinguish between legitimate and malicious flows for prioritization ? Further, it is challenging to identify whether the traffic belongs to a single user or multiple users, such as in tethering scenarios.

boucadair commented 4 weeks ago

There might be methods to do that (more or less complex) but still this is possible. For example, legitimate flows can supply a token that is provided only to entitled ones. Also, the pref here is more about discard pref than taking higher prio.

tethering is still seen as a same subscriber/user.

There are challenges that we need to record, for sure. However, let's discuss this in the WG and see if the WG want to cover this or not. We need that discussion to happen publicly. Thanks.

tireddy2 commented 4 weeks ago

There might be methods to do that (more or less complex) but still this is possible. For example, legitimate flows can supply a token that is provided only to entitled ones.

Who will provide the token to the applications and how will the network validate the token (in a scenario where is no agreement between the ISP and content provider) ?

Also, the pref here is more about discard pref than taking higher prio.

Yes.

tethering is still seen as a same subscriber/user.

Okay.

There are challenges that we need to record, for sure. However, let's discuss this in the WG and see if the WG want to cover this or not. We need that discussion to happen publicly. Thanks.

Works for me but we may want to high-light the challenges in the draft for the WG to understand the complexities if this is to be supported.

boucadair commented 4 weeks ago

Also, the pref here is more about discard pref than taking higher prio.

Yes.

tethering is still seen as a same subscriber/user.

Okay.

There are challenges that we need to record, for sure. However, let's discuss this in the WG and see if the WG want to cover this or not. We need that discussion to happen publicly. Thanks.

Works for me but we may want to high-light the challenges in the draft for the WG to understand the complexities if this is to be supported.

Fully agree. Please update the text to list the challenges not already in the text.

sridharangirish91 commented 4 weeks ago

This discussion can drift into implementation suggestions very quickly like suggesting token exchange etc, the reason why we kept client signalling of encryption key out of the draft as well. Listing the challenges and keeping it open ended is a good way, I agree.

sridharangirish91 commented 4 weeks ago

Reading Med's comment again on this being applicable only to lowering the priority of flows, will any app do that in practice? I mean, what would an app vendor get from saying "Hey I have a lower priority". Assuming it is a perfectly fair world, apps can signal this when they are not being used but I wasn't sure if they'd ever signal this themselves. Letting the platform/OS do the bidding for them is a dangerous thing...

I was also wondering, will any OS companies like MSFT or Apple get into a deal with the big content giants like netflix and signal lowering flow priority for other apps themselves without anyone else noticing? Google could do the same with android to promote YouTube performance too... Will this be a concern? Especially if this signal is encrypted and the platform companies have tie ups with ISPs as well as a protocol between them to decrypt the signal, the platform companies could silently kill performance of other small-scale apps... Just wondering if this is a possibility or if I am flying into the crazy world, if we even choose to propose enabling control of inter-flow mechanism.

boucadair commented 4 weeks ago

Reading Med's comment again on this being applicable only to lowering the priority of flows, will any app do that in practice?

It isn't intuitive to do so. However, with all the marketing hype and "commitments" for fair use of resources, some forms of this case may not be unrealistic.