How to bind a connection-specific value to the connection?

[wilaw]

Can it be stamped with the IP of the client?

[wilaw]

To give more context to this issue, there are certain key values which only make sense for the current connection - for example, estimated throughput. Since delivery of an asset involves a chained series of transfers, if these values are preserved they can provide misleading information to subsequent recipients. Some suggestions for how this might be addressed:

1. Have each layer which is CMSD-aware overwrite the values. This works until there is a delivery component which is non-CMSD-aware, such as dual CDN's, where the initial CDN adss CMSD headers but second CDN does not.
2. Be able to identify the final edge machine talking to the player. This is the connection where we care about the throughput for example. The trouble is many machines do not understand their location, or it may change, or the final machine talking to the client may not be CMSD-aware.
3. Have each CMSD-aware machine overwrite the value and add a timestamp when it does so. The client can compare the time stamp to the current time and try to infer if that estimate applies to the current connection. (the timestamp should be approximately now()-RTT/2 )
4. Omit these values from the spec, since the danger of transmitting false information outweighs the utility of the data in the first place.
5. Add in a connection specific identifier which is readable by the client?

[wilaw]

Over several meetings, we have a solution utilizing the list capability Structured Field Values for HTTP. Keys which relate to each other are separated by semi-colons ';' , while groups are separated by commas ','.

Per https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19 , a proxy MUST NOT change the order of the field lines with the same header name. A proxy server may add CMSD-Dynamic keys in one of two ways:

• It may add a new CMSD-Dynamic header. If doing this, it MUST NOT change the order of the existing CMSD-Dynamic headers and the new CMSD-Dynamic header MUST be added as the final field with that name.
• It may append the key/value pairs to the existing CMSD-Dynamic value, separating them from the prior data with a comma Unicode 0x2C.

Example 1: CMSD-Dynamic: n=“CDNB-3ak1”;etp=96;rtt=8 CMSD-Dynamic: n=“CDNB-w35k”;etp=96;rtt=32 CMSD-Dynamic: etp=48;rtt=30;n=“CDNA-987.343” CMSD-Dynamic: etp=115;rtt=16;n=“CDNA-312.663”;mb=5000 CMSD-Static:ot=v;sf=h;st=v;ht=437;d=500;br=2000;n=“OriginProviderA”

Example 2: CMSD-Dynamic: n=“CDNB-3ak1”;etp=96;rtt=8,n=“CDNB-3ak1”;etp=96;rtt=32,etp=48;rtt=30;n=“CDNA-987.343”,etp=115;rtt=16;n=“CDNA-312.663”;mb=5000 CMSD-Static:ot=v;sf=h;st=v;ht=437;d=500;br=2000;n=“OriginProviderA”

A client, in receiving this data, can interpret the last added group to be the freshest. However it is still not guaranteed that this relates to the prior connection. Our only guideline we can issue in this regard is that a distributor, who controls the edge CDN and the player, can orchestrate collaboration between the two such that the player can trust that the last CMSD-Dynamic data added does in fact refer to the last-mile connection.