Closed mjoras closed 4 months ago
Yes, protocol is not excluding any access technology. We can clarify it.
Usage of SCONE is not restricted to any specific access technology. At present we see the relevance of SCONE, more in the mobile n/ws (any generation of cellular n/w which supports internet flows as packet switched service) due to following main reasons ; (1) Cellular spectrum (which is mostly licensed) is limited and premium resource. (2) Significant CAPEX & OPEX investment for CSPs to install and operate additional base-stations to add more capacity (freq -reuse through cell split) to serve more video bandwidth. In different generation of cellular networks , SCONE can be used by implementing SCONE in packet core n/w device(for e.g. in PGW for 4G , UPF for 5G , GGSN for 3G/2G-PS).However if needed, SCONE can be used in Fixed Broadband networks as well , by implementing SCONE protocol in the Fixed Broadband network devices - BNGs(Broadband Network Gateways) for Fiber based fixed n/w or CMTS (Cable Modem Termination System) for DOCSIS based fixed networks.
@anooptomar29,
However if needed, SCONE can be used in Fixed Broadband networks as well , by implementing SCONE protocol in the Fixed Broadband network devices - BNGs(Broadband Network Gateways) for Fiber based fixed n/w or CMTS (Cable Modem Termination System) for DOCSIS based fixed networks.
Yes, exactly. This is a good opportunity to think about/solicit opinions about the usefulness of SCONEPRO in non-cellular networks.
One question that ought to be asked during a WG-forming BOF is "is the IETF the right place to solve this problem?"
If SCONEPRO was targeting cellular networks, the follow-up question would be "why not do this in 3GPP?"
@SpencerDawkins Yes IETF is right place to standardized SCONEPRO to specify and standardize the requirement for transport/QUIC protocol and any other protocol related to IP networking. 3GPP standards do not specify requirements for networking protocol and they refer to relevant IETF docs/RFCs while specifying requirements for mobile packet core elements or RAN elements. In case of SCONEPRO after standardizing requirement for transport/QUIC protocol and any other protocol related to IP networking, 3GPP specs would refer to this specific IETF doc to specify support required in mobile packet core elements.
@SpencerDawkins Yes IETF is right place to standardized SCONEPRO to specify and standardize the requirement for transport/QUIC protocol and any other protocol related to IP networking. 3GPP standards do not specify requirements for networking protocol and they refer to relevant IETF docs/RFCs while specifying requirements for mobile packet core elements or RAN elements. In case of SCONEPRO after standardizing requirement for transport/QUIC protocol and any other protocol related to IP networking, 3GPP specs would refer to this specific IETF doc to specify support required in mobile packet core elements.
Right - and I didn't clearly say "the question that ought to be asked, and answered, during a WG-forming BOF". Your understanding matches mine - we just need to make sure that the IETF community also shares that understanding.
Just for the record, I cornered @mjoras, @ihlar, and @atiwariphd on a call a few minutes ago, and re-asked the question in person. This is what I heard as the answer:
Spencer asks about video shaping in wireline networks. Matt says some wireline operators DO video shaping, although they aren't as constrained as wireline operators - wireline operators who do shape may limit shaping to high-bandwidth transfers. Cable operators can use DOCSIS mechanisms for traffic shaping. And all satellite operators do video shaping, because they are even more constrained than cellular operators. This is why we are doing this in the IETF, and not in 3GPP.
So, yeah. That needs to be clear in the charter.
This issue seems totally agreed ... Who has action to submit a change or PR for the charter text? I am happy to do so if nobody is already on it.
Closed by #91
The motivating usecase is mobile (i.e. 5G) specific, but there is no reason the protocol needs to specifically only work for such networks, rather it must be feasible for the equipment used by such networks to utilize the protocol.