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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
