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

From: Joerg Ott via Datatracker <[email-masked]>
Date: Thu, 01 Jul 2021 10:40:44 -0700

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?

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Fri, 2 Jul 2021 01:44:57 -0700

Hi Joerg,

Thank you very much for your time and careful review.

The authors and I will take your comments into serious consideration as we
advance the document.

You are right that, as an Independent Submission, this work has not
received review within the IETF. Of course, all input and review will be
welcomed, and if the IETF were to decide that this work falls into the
scope of an IETF working group, we would be happy for it to be taken up
and developed there as an IETF document. However, our understanding is
that there is currently no enthusiasm for that, so we proceed on the
Independent Stream.

I'm sure that the authors will be in touch if they have any questions
about your comments.

Many thanks,
Adrian

-- 
Adrian Farrel (ISE),
[email-masked]

Joerg Ott via Datatracker wrote:
> 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.
>
> 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:
>   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:
>   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:
>   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?

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 6 Jul 2021 11:12:57 +0100

> I'm sure that the authors will be in touch if they have any questions
These comments are meant to supplement the TSV-ART review, and help 
provide more detail.

Related WG: I think maintaining the RMT and FECFRAME specs is a core 
transport area topic, and this could fall within the work of TSVWG. This 
WG recently completed work on new FEC Schemes. This doesn't imply 
whether there is interest, or not, in standardising such new methods for 
RMT. The proposed spec does have associated IPR, and that might 
influence the interest to develop an IETF spec, or might not.

I do also understand that this is the basis of a proposal/spec in DVB 
and ATSC.

TSVWG Concern: I think it is important the congestion control building 
block aspects are clear in any transport RFC, or the method specified 
only for a constrained deployment. To me, this needs more clarity.

Gorry

(TSVWG Co-Chair)

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 6 Jul 2021 14:43:15 -0700

Thanks Gorry,

I would certainly be happy to hear that the TSVWG is interested in
progressing this work.

What do you think is the best way of making a decision on that? Should the
authors have a slot on the TSVWG agenda at IETF-111? Or is this something
that can be decided on the list?

Cheers,
Adrian

Gorry Fairhurst wrote:
>> received review within the IETF. Of course, all input and review will
>> be welcomed, and if the IETF were to decide that this work falls into
>> the scope of an IETF working group, we would be happy for it to be
>> taken up and developed there as an IETF document. However, our
>> understanding is that there is currently no enthusiasm for that, so
>> we proceed on the Independent Stream.
>
> transport area topic, and this could fall within the work of TSVWG.
> This WG recently completed work on new FEC Schemes. This doesn't imply
> whether there is interest, or not, in standardising such new methods
> for RMT. The proposed spec does have associated IPR, and that might

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Waqar Zia <[email-masked]>
Date: Fri, 2 Jul 2021 08:50:43 +0000

Thanks Joerg Also on behalf of authors of the draft. I will incorporate your valuable feedback in an upcoming review and send an update to you as well.

Thanks and best regards,
Waqar.

> -----Original Message-----
> From: RFC ISE (Adrian Farrel) <[email-masked]>
> Sent: 02 July 2021 10:45
> To: Joerg Ott <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Tsvart early review of draft-zia-route-02
> 
> -------------------------------------------------------------------------
> CAUTION: This email originated from outside of the organization.
> -------------------------------------------------------------------------
> 
> Hi Joerg,
> 
> You are right that, as an Independent Submission, this work has not received
> review within the IETF. Of course, all input and review will be welcomed, and if
> the IETF were to decide that this work falls into the scope of an IETF working
> group, we would be happy for it to be taken up and developed there as an IETF
> document. However, our understanding is that there is currently no enthusiasm
> for that, so we proceed on the Independent Stream.
> 
> I'm sure that the authors will be in touch if they have any questions about your
> comments.
> 
> Many thanks,
> Adrian
> 
> --
> Adrian Farrel (ISE),
> [email-masked]
> 
> 
>