SCONEPRO Need for Defining A New On-Path Signaling Mechanism
draft-tomar-sconepro-ecn-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Anoop Tomar , Marcus Ihlar , Wesley Eddy , Ian Swett , Abhishek Tiwari , Matt Joras | ||
| Last updated | 2024-11-24 (Latest revision 2024-05-23) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document discusses the need for defining a new on-path signaling mechanism and addresses the question “why can't we use Explicit Congestion Notification (ECN)” for the SCONEPRO use-case. The SCONEPRO objective is to optimize user QoE for streaming media/ video services through network assisted application-level self- adaptation. This requires a Communication Service Provider’s (CSP’s) network device to send streaming media/video traffic profile characteristics (e.g. for allowed average media/video bit-rate, burst rate etc.) with the client application endpoint to enable content self adaptation implementations by content application providers (CAPs).
Authors
Anoop Tomar
Marcus Ihlar
Wesley Eddy
Ian Swett
Abhishek Tiwari
Matt Joras
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)