[Tsv-art] Tsvart early review of draft-zia-route-02

[Joerg Ott via Datatracker <[e-mail]>]

Reviewer: Joerg Ott
Review result: Not Ready

This Internet Draft describes how to carry transport objects in some notion of
"real time" (in this case: with transmission-side enforced time bounds) of a
UDP-based transport protocol via unicast or multicast to one or more receivers.
The underlying network may (but need not) be unidirectional in nature. The
protocol uses the layered coding transport (LCT) and, optionally, the FEC
building block (as well as FLUTE) defined earlier in the RMT WG. The draft
itself focuses on the exact usage along with parameterisation of these
underlying building blocks, which makes it partly very hard to read (and
validate). At this point, I have not carried out a detailed analysis if all the
usages of the underlying building blocks are correct and consistent, as there
are other issues to be addressed first.

The draft is an individual contribution that is linked to work in other
standards bodies and does not seem to have undergone any review process in the
IETF so far.  It is at least not linked to a working group, and also the
terminology used in some places suggests this.

This review is broader than just a transport area review as many issues come to
mind. But gen-art and secdir reviews are expected to provide more detail on the
points raised.

Overall, the draft could be seen as heading in the right direction to achieve
what the authors are after: transmitting video segments (of DASH-coded media
streams) or other files along with metadata across a packet channel a possibly
large and heterogeneous receiver group. But it has still a long way to go.

Terminology:
- "Transport" is understood by some standards organisation as the medium to
carry bits (referred to as L1/L2 in the IETF) but has a different meaning in
the IETF, namely end-to-end adaptation of a (best effort) service to the
application needs. Insofar, the title is already misleading as it uses the term
transport twice and in both meanings. Suggest to change one occurrence to
network (subsuming the lower layers). - define "transport buffer" (and possibly
other terms in a terminology section) - sect 5.2 states " beyond the scope of
this transport standard". The present target of the spec is "Informational", so
it won't be a standard. - the actual "standard" text pieces should use proper
RFC 2026 terminology

Structure:
- section 9 introduces ROUTE concepts; put this first. The reader should
understand what this is all about before worrying about individual parameters
and the like. - section 10 needs more context

Technical:
- The document needs a clear scope and applicability statement. The
technologies presented are not feasible for use in the open Internet. See
below. - Figure 1 seems incorrect. At best, you can carry a DASH segment on top
of ROUTE, but certainly not DASH as ROUTE does perform HTTP-req/rsp-style
operation with receiver side adaptation. - The document says almost *nothing*
about congestion control. It specifies how many bits of congestion information
to use, but this boils down to saying that a 32 bit number (if I am not
mistaken) shall be used. No further guidance is given, let alone algorithms or
mechanisms mandated. - The use of the CCI field is unclear: how will the
earliest presentation time relevant be used? - sect. 5.1 states that
"Congestion control is thus sender-drive in ROUTE" but the entire document
doesn't seem to say anything more. - Identifying a connection by means of IP
address/port pairs alone many not guarantee uniqueness if the sender (the
entity choosing the id) is behind a NAT. - sect. 5.3 seems to suggest to
exclusively rely on application information for pacing packet transmission,
which seems at odds with congestion control. - sect. 5.4 doesn't seem to
account for the one-way delay from sender to receiver, but could still be ok -
sect. 6: what does graceful operation in case of reception of unrecognised
packet mean when the application is to be informed? Given stray packets,
possibly Internet background radiation, attacks, etc. this statement seems to
assume operation in a protected environment. - sect. 6.1 also seems to lack
failure handling - for carrying ROUTE over TCP, which is mentioned in the
security considerations, a framing would be needed (and possibly connection
setup and teardown procedures) - the security considerations, for UDP, point to
DTLS. But this won't work with multicasting and it won't work with
unidirectional networks either

Editorial:
- The code points for the CP should be explained, not just listed, or
referenced properly - for curiosity: do you need anything but ASCII so that a
reference to "alphanumeric data" would require character set considerations? -
explain the session metadata and their purposes, don't just list them - don't
describe math just in text but provide equations; this may also apply to values
in fields (such as overhead (o)) - improve text clarity and use shorter
sentences (e.g. maxExpiresDelta, but not just there) - the paper has minor
grammar issues (missing "the" or "a" in many places) - sect. 4.1.2: "The
content encoding defined in the presence RFC is gzip."  What does the "present
RFC" refer to? - sect 4.3 seems insufficient: MIME can be used in many
different ways - sect 5.5: what is a "protected repair flow"? - sect 6.3.1
should provide a formal definition

Interop:
- What are the implications of values being undefined? e.g. the minimum
transport buffer?  Handling? - what happens if maxTransportSize is missing? -
in general the draft doesn't say much about failure/error handling - sect. 8:
would a registration mechanism be needed for application profiles? Who would
manage this?