What is the use case for DATAGRAM as an immutable property?

[martinduke]

We are close to getting rid of original-publisher defined forwarding preferences.

The stream mapping of FETCH is derived from the fidelity requirements of the Subscriber, not the Original Publisher. Once we made it possible for the subscriber to express this, Track forwarding preference was obsolete.

Similarly, the use case for DATAGRAM (AFAICT, "my latency requirements are so low you shouldn't even try to retransmit") seems to be a subscriber requirement rather than an immutable property of the track. This tells me it should be something subscriber determined (or sender calculated based on timeouts) rather than a track property.

[ianswett]

I still view the use of streams or datagrams as a hop-by-hop data transmission question. But as you said, if there's a property of the track that one is trying to express by saying it only goes over datagrams, we should make that clear.

[fluffy]

@martinduke , let me remind you that pretty much everything a subscriber specifies is unlikely to go beyond the first proxy in most cases. What happens is subscriber A wants datagrams and subscriber B does not. I think what we have is fine and the chairs should stop trying to kill stuff that implemenatation experience show is working fine.

[martinduke]

@martinduke , let me remind you that pretty much everything a subscriber specifies is unlikely to go beyond the first proxy in most cases. What happens is subscriber A wants datagrams and subscriber B does not. I think what we have is fine and the chairs should stop trying to kill stuff that implemenatation experience show is working fine.

1. Why does any subscriber care if it gets Datagrams or not? It cares about the delivery timeout. Datagrams are just a sender optimization when the timeout is so short that the objects can't be usefully retransmitted.

2. Even if we added the ability for subscribers to request datagram, under my proposal it's trivial for a relay in your example to send the object in each of the requested modes. In the current spec, this is impossible because Datagram is an immutable track property.

[suhasHere]

I see preference was Datagram as publisher requirement and not the subscriber requirement, where retransmissions is useless , stream overhead is unnecessary and provides and end to end delivery property.

Also it is publisher who is also deciding subgroup mapping and not the subscribers. Publisher is aware of what is needs from the underlying transport and a subscriber can influence it based in priorities or group order.

[afrind]

Individual Comment:

Cullen's point about multiple subscribers to the same track with different delivery timeout properties is valid. The subscriber with the longest delivery timeout will determine the relay -> upstream timeout, so subscribers joining/leaving at the relay could impact what is seen by other subscribers.

if there's a property of the track that one is trying to express by saying it only goes over datagrams, we should make that clear.

Datagrams have 3 properties

1. Shorter than 1 MTU
2. Not retransmitted
3. Not flow controlled

We don't need forwarding preference to convey 1, but having an end-to-end publisher signal to convey 2 and 3 seems right to me.