Re: [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-raw-use-cases-07

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Thanks Magnus and Jörg! I will update the text in the next revision to
capture this discussion.

Thanks!

Carlos

On Wed, Nov 2, 2022 at 9:11 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
>
>
> Just to provide a reference to the multi-sink synchronization Jörg talked
> about below. This was defined for RTP in RFC 7272:
> https://datatracker.ietf.org/doc/rfc7272/ and relies on signalled clock
> sources https://datatracker.ietf.org/doc/rfc7273/
>
>
>
> *Cheers*
>
>
>
> *Magnus*
>
>
> >     Section 5.2.2: With audiovisual communication having a long history
> >     in the
> >     IETF, there is clearly an awareness of what it takes to do smooth
> >     playback
> >     and synchronized playback: playout buffers. These, of course, would
> add
> >     latency, so the point made here is well taken but it should be put
> >     into the
> >     context of A/V over packet networks.
> >
> >
> > [Carlos] Not sure if you suggest adding here some text to clarify that
> > this is in the context of packet networks. I've added something but I'm
> > not sure if this addresses your point completely.
>
> Ideally, this would reflect what A/V over packet networks has done since
> RFC 1889/1890 (and even before that in research), playout buffers for
> smooth playback and wallclock time sync (relative to a single sender)
> for cross-media synchronization and possibly to a common reference clock
> for multisource sync.  There was work on multi-sink sync in research but
> I am not sure this made it to the IETF.
>
> In 5.2.1 you currently only cover lost packets but not delay variation
> which might also occur, even in detnet-style networks (just miss your
> TSN slot, for example). The latter would need minimal buffering which
> may give your RAW design some room to maneuver.
>
> Overall, the assumptions assume that the max latency bounds are so tight
> to make rtx impossible.  Isn't this a function of the current path RTT?
> If this is very low, rtx might be permissble.  Maybe phrasing this in
> less absolute terms, e.g., "such an approach is not viable" -> "so an
> approach may not be viable" would do the trick?
>
>
>