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

[Waqar Zia <[e-mail]>]

Dear Joerg,

Thanks again for your detailed review comments. This updated draft https://datatracker.ietf.org/doc/html/draft-zia-route-03 addresses several issues including your comments below, details as follows inline tagged with [WZ] 

> -----Original Message-----
> From: Joerg Ott via Datatracker <[e-mail]>
> Sent: 01 July 2021 19:41
> To: [e-mail]
> Cc: [e-mail]
> Subject: Tsvart early review of draft-zia-route-02
> 
> -------------------------------------------------------------------------
> CAUTION: This email originated from outside of the organization.
> -------------------------------------------------------------------------
> 
> 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).

[WZ] The two terms in question are "Transport Object" and "Unidirectional Transport": "Transport Object" implies an Application object to be transported over the transport network, and in this context cannot be understood separately.

ROUTE, as noted in the document, is very closely aligned to FLUTE, an existing IETF specification. It is not just aligned, its mostly an extension of it. So all principles (the layer where this protocol works, its underlying network assumptions) are hence identical to FLUTE. FLUTE also uses the term transport identically which this document reuses. Added reference in introduction "Unidirectional transport in this document has identical meaning as in RFC 6726 [RFC6726]"
Also, the target of this document is to publish already existing specifications in ATSC and DVB; it is unfeasible to publish these specifications with a different name.

> - define "transport buffer" (and
> possibly other terms in a terminology section) 

[WZ] Addressed: the functioning of source flow transport buffer added.

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

[WZ] Addressed.

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

[WZ] Addressed.

> - section 10 needs more context

[WZ] Addressed.

> 
> Technical:
> - The document needs a clear scope and applicability statement.

[WZ] Addressed.

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

[WZ] Addressed.

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

[WZ] Addressed.

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

[WZ] Addressed.

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

[WZ] Added clarification: the connection ID is the 4-tuple: source IP address/source port number, destination IP address/destination port number.

> - sect. 5.3 seems to suggest to
> exclusively rely on application information for pacing packet transmission,
> which seems at odds with congestion control. 

[WZ] Addressed.

> - sect. 5.4 doesn't seem to
> account for the one-way delay from sender to receiver, but could still be ok

[WZ] This is approximate and EXT TIME may be used.

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

[WZ] Security considerations in cl 11 against attacks do apply. Assume "stray packet" is some malicious packet.

> - sect. 6.1 also seems to lack
> failure handling 

[WZ] Addressed.

> - for carrying ROUTE over TCP, which is mentioned in the
> security considerations, a framing would be needed (and possibly
> connection setup and teardown procedures) 

[WZ] Addressed. It has not been the intention to cover this topic, hence removed.

> - the security considerations,
> for UDP, point to DTLS. But this won't work with multicasting and it won't
> work with unidirectional networks either

[WZ] Addressed.

> 
> Editorial:
> - The code points for the CP should be explained, not just listed, or
> referenced properly 

[WZ] Addressed.

> - for curiosity: do you need anything but ASCII so that a
> reference to "alphanumeric data" would require character set
> considerations?

[WZ] Addressed.

> - explain the session metadata and their purposes, don't
> just list them 

[WZ] The purpose of individual session metadata is in Clauses 4 – 7.

> - don't describe math just in text but provide equations; this
> may also apply to values in fields (such as overhead (o)) 

[WZ] Overhead for example is removed.

> - improve text clarity
> and use shorter sentences (e.g. maxExpiresDelta, but not just there)

[WZ] Addressed.

> - the
> paper has minor grammar issues (missing "the" or "a" in many places)

[WZ] Revised and improved.

> - sect.
> 4.1.2: "The content encoding defined in the presence RFC is gzip." 

[WZ] Addressed.

> What
> does the "present RFC" refer to?

[WZ] Addressed.

> - sect 4.3 seems insufficient: MIME can be
> used in many different ways 

[WZ] Addressed.

> - sect 5.5: what is a "protected repair flow"?

[WZ] Addressed.

> - sect 6.3.1 should provide a formal definition

[WZ] Updated and added more clarity.

> 
> Interop:
> - What are the implications of values being undefined? e.g. the minimum
> transport buffer?  Handling? - what happens if maxTransportSize is missing?

[WZ] Updated and addressed.

> - in general the draft doesn't say much about failure/error handling 

[WZ] Addressed.

- sect. 8:
> would a registration mechanism be needed for application profiles? Who
> would manage this?
> 

[WZ] Addressed.

Best regards,
Waqar.