On 2/4/2015 2:55 PM, Marie-Jose Montpetit wrote:
Well one reason I started being interested in TAPS was because of the
video and of course the multisource version (video for example combining
streaming, download, multimedia and social networking). For these use
cases you need to be able to specify delay, loss (to avoid or minimize
buffering events)
For a streaming source, delay can be described (time offset, time offset
variation). That is simple only for real-time streaming live,
bidirectional content.
When you start including the size of the message - whether as a single
bulk transfer, or the ability to buffer large amounts of it (for
recorded content), then the size of the message is inherent in the
notion of latency. You can't ask the network how long something will
take if you don't tell it how big it is.
I could think in extreme cases even path (or
multipath).
I've said this before in MPTCP, but please don't confuse endpoint with
path here. Same endpoints can mean different path, and using multiple
endpoints is no guarantee of independent paths.
> So a way to abstract the services that could be summarized
into “give me the best video now” would be very useful for all new
video-based apps out there.
What would "give me the best video now" mean to the transport layer?
Completely different things for Netflix, Vine, and Skype.
In summary, we need a better way to describe the services we want before
we'll ever be able to expect the transport to handle them properly.
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
