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

[Joerg Ott <[e-mail]>]

Dear Carlos,

thanks much for the update, see inline.
(removing the done bits)

> Thanks a lot for your review. Please see inline below how we are 
> addressing your comments in rev -08.
> 

>     The document discussed quite a diverse set of use cases but does so at
>     very different depth and level of detail.  In one case, concrete
>     requirements
>     are hinted at in terms of milliseconds of latency but no others
>     mention these.
>     I understand that this is not a requirements document but if
>     something is a
>     specific use case for RAW, maybe we can be more specific than saying
>     data
>     needs to be carried within some time bound across a wireless link? 
>     I believe
>     being more concrete may help the group decide which types of
>     mechanisms are
>     to be applied for which use cases.
> 
> 
> [Carlos] This is a good point but not that simple to tackle. We have 
> incorporated the input that has been made available by the WG 
> participants. It's true that it is not at the same level across all the 
> use cases. This sometimes has to do with the fact that some use cases 
> actually group several possible applications with different quantitative 
> requirements. Since the document is not a pure requirements document, we 
> believe the level of detail is sufficient to help future developments in 
> the RAW/DETNET WGs regarding what the solutions have to provide.

I see the point, thanks for elaborating.  This is indeed more a nice-to-
have, and if the WG believes the level of detail is sufficient (well,
details may change and application may evolve anyway), then we are good.

>     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?

>     When discussing especially the non-latency critical considerations
>     (e.g., in section 5.4.1), keep in mind that the IETF offers many
>     protocols
>     that could quite easily cope with packet losses, add redundancy,
>     also across
>     multiple paths.  These protocols operate above the link and IP layer,
>     typically at the transport layer or, e.g., with Application Layer
>     Framing,
>     even at the application layer.  I would thus urge the authors to not
>     have the
>     document suggest that certain mechanisms need to be addressed with
>     the scope
>     of RAW or the layers below.  This would appear beyond scope of a use
>     case
>     draft and also too limiting.
> 
> 
> [Carlos] I agree on the comments about the mechanisms above the link and 
> IP layer. This document does not neglect nor prevent those to be in 
> place. But in the context of the heterogeneous and/or multi-hop wireless 
> networks that RAW considers, there might be additional actions that can 
> also be taken to improve non-latency critical aspects, in the same way 
> that DETNET does for multi-hop wired environments. I think it is useful 
> to highlight that in the document. This was added in the document after 
> some discussion in the WG requesting it.

ok

Thanks much.

Best,
Jörg