Inclusion of network transport related information
Closed this issue · 5 comments
The current CMSD spec contains an estimated throughput (etp) entry. This information, and other related metrics (e.g. RTT, MSS, etc), could be obtained directly from the edge proxy transport layer as we detailed in our "Transport-Info header" Internet draft:
https://datatracker.ietf.org/doc/html/draft-ohanlon-transport-info-header
Such transport metrics are readily available at a proxy/edge node from the transport layer stack - in the case of TCP these are available from the tcp_info data structure which is accessible from a number of web servers/proxies (e.g. Nginx tcpinfo_rtt, VCL's tcp-info). For other transport protocols (e.g. QUIC) similar information can also be obtained (e.g. Facebook's mvfst TransportInfo, VCL's quic.rtt)
The draft also suggests structured header formatting of the information with inclusion of an id and timestamping of entries so their origin and timeliness can be ascertained which may be of use in the CMSD spec.
Specific suggestions:
- The 'etp' entry could be calculated using the transport-info metrics on the edge server.
- Qualify the source of the estimate to where the information originated e.g. transport-info or some other source.
- Provide a confidence measure of the estimate
- Adding a timestamp to the estimate
- Such entries may be best provided by a proxy/edge node replacing any existing estimate since the final(edge) estimate is likely to be the most relevant to the client
- Consideration of including additional metrics e.g. RTT, MSS
Could confidence be expressed as buckets - low, medium, high?
RTT would be useful for many web clients.
Timestamp could apply to all dynamic entries. Time window of validity is a separate question.
With respect to representation of any additional parameters we can just use the existing sf-list type we're using the spec (I added a clarification there) - as is used in the Transport-Info draft; So each list-member can consist of one or more key/value pairs separated by ;, with the list-members being separated by a , e.g.
CMSD-Dynamic: etp=1000;src=ti;ts="2019-08-30T14:56:08.069Z", mb=3000
We should have a conversation about whether the Transport-Info data should be incorporated into CMSD or whether it really does just make sense as it's own header.
A related draft on the "Delivery Rate Estimation" - which is generic algorithm for a transport protocol sender to estimate the current delivery rate of its data: https://datatracker.ietf.org/doc/html/draft-cheng-iccrg-delivery-rate-estimation
We shall incorporate two keys directly from Transport-Info - ETP and RTT - as these are directly understandable and actionable by most players. Distributors can add Transport-Info headers in addition to the CMSD headers for cases in which more detailed transport data is known and in which clients understand how to use this data. Servers have several different options for estimating ETP depending on protocol, mobile-network collaboration etc.