search

mjoras / SCONE-PROTOCL

Repository for files related to the topic formerly known as SADCDN.
Other
9 stars 10 forks source link

Information shared by network device with the client - What #25

Closed anooptomar29 closed 2 weeks ago

anooptomar29 commented 7 months ago

To assist "client app" to adapt video flow's attributes, n/w device is expected to share some information with the client. These information elements should comply with following requirements ;

  1. The attributes of video data traffic specified in the information elements - shall be measurable by both CSPs and CAPs.
  2. For a given video session the specification - shall ensure that CSP and CAP, albeit measuring independently, compute consistent attributes of the video data traffic.
  3. The attributes of video data profile - shall include an average or median video bit rate and a maximum video bitrate
  4. The information element - shall specify a methodology for computing median, maximum and average video bitrates including how to determine the time window for measuring these statistics
anooptomar29 commented 7 months ago

@atiwariphd As discussed we may need to loop in Ali Begen for his inputs on this topic.

atiwariphd commented 7 months ago

Yes I will bring in Ali Begen and the folks from AT&T on this topic.

SpencerDawkins commented 6 months ago

Hi, @acbegen, I'm not sure whether @atiwariphd and you have touched base, so I thought I'd tag you in this issue. I don't think we need to converge on an answer before the BOF, or even before chartering, but it's an important point that I'd like to get correctly in a document.

acbegen commented 6 months ago

Hi, @acbegen, I'm not sure whether @atiwariphd and you have touched base, so I thought I'd tag you in this issue. I don't think we need to converge on an answer before the BOF, or even before chartering, but it's an important point that I'd like to get correctly in a document.

Yes, we did already and I gave some pointers (existing specs and related work) in this space to @atiwariphd and @anooptomar29. Will be attending the bof session remotely.

SpencerDawkins commented 3 months ago

Hi, @acbegen, I'm not sure whether @atiwariphd and you have touched base, so I thought I'd tag you in this issue. I don't think we need to converge on an answer before the BOF, or even before chartering, but it's an important point that I'd like to get correctly in a document.

Yes, we did already and I gave some pointers (existing specs and related work) in this space to @atiwariphd and @anooptomar29. Will be attending the bof session remotely.

Hi, all, I'm looking at the current charter, and it says

The working group will initially focus on a solution that communicates the maximum achievable bandwidth for a video delivered from a server to a client, using QUIC connections carrying the application signaling traffic.

and

Network properties sent from the network. The network provides the properties to the client. The client might communicate with the network, but won't be providing network properties.

So my questions are

atiwariphd commented 1 month ago

if the initial solution communicates maximum achievable bandwidth, do we need to know more about the information shared by the network device with the client?

As an initial solution this is fine but based on my experience working with some CSPs, just maximum achievable bandwidth may not be sufficient. For example a network element may want to state maximum allowed burst rates and an average rate. Since the initial use case of SCONEPRO is to allow self adaptation by content providers in lieu of CSP led throttling, the SCONEPRO signal will need to specify the traffic characteristics that the Throttler was trying to achieve. Should I suggest a PR that makes the charter text less rigid on what needs to be communicated?

mjoras commented 2 weeks ago

This was closed by the charter rewrite.