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

Waqar Zia <wzia@qti.qualcomm.com> Fri, 02 July 2021 08:50 UTC

Return-Path: <wzia@qti.qualcomm.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95D53A15EB; Fri, 2 Jul 2021 01:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSO5394CawL3; Fri, 2 Jul 2021 01:50:53 -0700 (PDT)
Received: from esa.hc3962-90.iphmx.com (esa.hc3962-90.iphmx.com [216.71.142.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243A93A15F0; Fri, 2 Jul 2021 01:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qccesdkim1; t=1625215853; x=1625820653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p6g0/iKyIff0DFJ06ZbWQ1OgRiZrd2D7GSv1nc+t15o=; b=GLqBQ4gRJUx5h29+N087+jNPLt6xfDU6k4wg1zoikpHtkj/BSGWeNAxX T2NYsjiYuGpYH0jhfKBTNA4xFdTagbEArzorm/e/cEd9/wQYivEJhaNuG +62bRe73hn/d8BoawZ2+iz67pln7aQSHX7/iSyx0/O8IMFaYJmGeClppE k=;
IronPort-SDR: Fdp+Cj7eIZ07SUWACXhqCmqWXl6qTldI2yzSWkL7/WfzejRBLd87PLfyLbkWe20CMIdqz+uCh4 RAi5TZ3Ab5x/762TlwTvPLLGGGTNQh3MX2TTkz7Bc/niYRNIoLO5ZPEwTbiv1tufivZH1gSxOr c0RfmhNtfWW7wt/Q5wv7nWJln2c/YeGVFs5n8FXSQh3JiwHChLZR8lSty76E2rubcfsKojdN8P ZVWeMu7Zv/3ubj7oqxeX6ALr0/JYSqL4QPV3+WGZTXa906gq4m6P9aJQC2OuTzQTqMR0Xn8TX7 TBk=
Received: from mail-dm6nam08lp2047.outbound.protection.outlook.com (HELO NAM04-DM6-obe.outbound.protection.outlook.com) ([104.47.73.47]) by ob1.hc3962-90.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2021 08:50:48 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dVlP6BFtPJiMNR/hN5e1/d4qZmnPWLQ0SKpXqsnAsMQgaFI+8G5dcjwqfqPPk9Ew0X3Ug9d20JFzPlB6tMTY9O1bKSAGljVmTd3Jc7l0XT2wqB3OUVEITxsSFb8nQliYPqcTQ8a75UwiN8zWQ4d6gEhEVYESdlulLQgkgafXv/AHcPAlaq+9Q8jcY8fDpElY39k2AF8xk3SXUJwl9RrzdO401cXfwCdBEZaqAjM4CPrj5vFPxUXr1wJItHaLVWkUGUDZAEnxqnPlXmzjsf/Uvh8seX3PTWOIGLG8UIZub60LXROKG1EwZXkAAKeAMaS7R7JMQr6/n9Qzb4jdxuKx5Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q6HzGHcexQZBjkSFwlYuma/sRfVbbwNgUAnhIG7Fgek=; b=MaN7phnzVHto66doJms5zBWoqWiiXhDqZxplMCVqKNb/fkInsYCw6/K2WoDZgUbRs5Xq14OxXsiM1cUj3TvhXqYLFDywWeZ4sX6t6Qpqk9wIyXS6elAlILe0J2B67E9jNYZovJB3VGsvGgFk5Fj4ZEOYN33zufrYy3MPcQr+JR0eMBz64glH87Li0nIaiCWkiqKB8RlkmRIkVHBGdxM1zgJ5oW0ZZETg8AxV2UC5ioOp2LmVefoiizh09MyKgKOqJHYGq5w1X+t8pQ57UAQuLNobhYV19iIU0oMaJaGMMfZq7SL+iszdyFUQ8GUnTmH4rCwcNYgT/uIUrStII57OdQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qti.qualcomm.com; dmarc=pass action=none header.from=qti.qualcomm.com; dkim=pass header.d=qti.qualcomm.com; arc=none
Received: from DM8PR02MB8122.namprd02.prod.outlook.com (2603:10b6:8:1b::20) by DM5PR02MB2633.namprd02.prod.outlook.com (2603:10b6:3:41::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22; Fri, 2 Jul 2021 08:50:44 +0000
Received: from DM8PR02MB8122.namprd02.prod.outlook.com ([fe80::c84e:8002:d141:ee24]) by DM8PR02MB8122.namprd02.prod.outlook.com ([fe80::c84e:8002:d141:ee24%7]) with mapi id 15.20.4264.026; Fri, 2 Jul 2021 08:50:44 +0000
From: Waqar Zia <wzia@qti.qualcomm.com>
To: "rfc-ise@rfc-editor.org" <rfc-ise@rfc-editor.org>, Joerg Ott <jo@acm.org>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-zia-route.all@ietf.org" <draft-zia-route.all@ietf.org>
Thread-Topic: Tsvart early review of draft-zia-route-02
Thread-Index: AQHXbqBArfAsSJWTD0q60g89Hv5/IKsvX9GAgAABP4A=
Date: Fri, 02 Jul 2021 08:50:43 +0000
Message-ID: <DM8PR02MB812294CD7E4089A9FFE43450F71F9@DM8PR02MB8122.namprd02.prod.outlook.com>
References: <162516124423.22722.7196903963576142899@ietfa.amsl.com> <4afac07eb8cf1f721307b0287d56a2fb.squirrel@www.rfc-editor.org>
In-Reply-To: <4afac07eb8cf1f721307b0287d56a2fb.squirrel@www.rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: rfc-editor.org; dkim=none (message not signed) header.d=none;rfc-editor.org; dmarc=none action=none header.from=qti.qualcomm.com;
x-originating-ip: [163.116.178.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b3c2cb60-c318-42a8-dd33-08d93d367a6b
x-ms-traffictypediagnostic: DM5PR02MB2633:
x-microsoft-antispam-prvs: <DM5PR02MB26330115B0BDF6ACED67682BF71F9@DM5PR02MB2633.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dz2FpluDlTgjWxaX/sH0okD+ER7FdbcpzgzTPatEaKc0VM/B7Ky5S99cNlJAOtJm3P4U+z0wtoQd5FabdalwmIK9SHbF4PQZTrhX+bpUgEp7jLXEDHbQktptDzoyNKV5Q8KlvXyVfcVH1nMSXVQ+jFdHuh8IOa6VhxYVnD7pLKJDUdX03BbIJDTISi0JLzUKHE7Xf5GurnnBm3/i1cu0X9gDdSzAv72dqXqsRNjv0437yI5cnyCiV+zXlU/In/4mA9pMamRa1paREeXF6a41yCYyTtkYGIcS/wUJWJAZt/CVhc8fi1FrDGT4MASOTgQJux91gFWrn0HwiWw+DqapAgp8YMQ379I+fUI/n0oF236jKKkSezkDGqlIwsLfKAPoMcsCjxgqSFJbfziRm2XGZir2NzIGQPEvEHqB8J8AXTvGa7hydHQefcoRWjHryXwHNGuxCNoL7tLF6FzGBvvWwjk7FCdUQL+KfWrD5u9iefs5ojHtgE7c6s1PkQ7vN9LFMBUo4FOp2P8+8N/LRyyaW+4huQNL5XkhXgOqd5vrysFlm+ZJ0WDtZFC6X7DPs7Re6lU4o9/WTqEbreUUstdvtqhc7QA25EIr1P8jAO3bSbmUY6oAnyt0hRZqCfAdxJVmCc3/5MXDHkPlkIQ2TsGjKw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR02MB8122.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(186003)(26005)(8676002)(86362001)(66556008)(53546011)(83380400001)(64756008)(66946007)(52536014)(6506007)(66446008)(54906003)(76116006)(110136005)(66476007)(8936002)(38100700002)(478600001)(316002)(55016002)(7696005)(4326008)(9686003)(122000001)(33656002)(5660300002)(66574015)(71200400001)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: NNXuNLhMcz5c8Wrr5W9GjUu5cIqc97q45ws8d5vW3Jd9e5VcXYeFV/CMEETUgjsfKP4VACuH/0CptWUR+RoqFe2yWxDpc6uPJ90ackmlF8qJcCPf2BQUTladecvFASckiRGLGtLq72I6V1Skt2vH2j/OmoXCC6eGRcdo9nhsPtdXzGnIQy30nDYtkkDk9Qb1y+xROFwP0IFb8/7Xky2T2M6WsihBtjzyM+HtrMmu++/jO/V0fqoI6U3EDOBIDwoWy1m+M+C9zPX20O2sk5T6cUyRgcj5O5r/rXosmfpB7noLCXerSlVSGjeMs9Q32b9b43RASsOVPy2cgsjNY9pzLxDudkc/TJrrduTAxwm9XStyAqbdZ+YKSSocn5DDBQM3+qFsF7nVe1GNEHtuZjT7v8OTemq3drT4CRFxWf7uwBe+K5mghcS7RqGDoQs+6xnEWvEL6w49E3cFcuoSvCC8aSl2WjRvH9Gvr8KzAWo0n8+OC7f3j46XeI6N77HelCgNv95aZTv2Clz204ma9kxNqPUDLbDMr0YZC39qK+ofBbkvaePLDxTFOBV/F8zn6+QHJ09O7IN5sSDoli5uJFUwdJSpflxvW6nED6vgMSJWANSuNSJpZwCG6OJmqwgKNxs3lIkpFDVGXi1dW94SIEHZ4tXw23s7gv1+fuZGBDal+EmsvDDBZ22K9BJDAradoiyQwXduBcCFjrf28DKPGE8J5rdnnAaiW5MX/n6GuynObbhxF5IkwvJbCR0NMDTAV+AI3UVhpDXSRt2vJRjRd1SOsjte+R1It9dNbGZMKcC1dpY25oIw1E0GmgoApV5mk/+AsbgzyfzJIJxTQ8iYCxUN5rWRu97g8+iEvnVoZMjIp4hO52tfqkj5KY8kkNuvhMVzwDEx5C/BTh33//E+4/UltVgM8/Ou3MOLaKs1SAqgBn+m0ixaRFUe/o5j+giM7EehSmFJhe0rGkKMpGXw6emmorzft6cb+cDSUhHY7WkJucnTrHtT2JspJzLMiQNl24tKBfRyC40TPzrcV/CfMeM3U/EHCIXlTPSAMEg3OhUI9uvC/dhz4Bgoi69fyX3Hlf81WZCKfZa4jB0nFU440aWmQjtghdmZrzX7W8VScf2QTb4abSOyJinpNiUmGCBlDKT7eEk1HCt4p+9jLybow+61N4eQWPvLUmGu69x1MmXlmvV8NcjCagpac244wGSR1IEbSWAVv3O/zk5Z1PN6KWtqJCoDWjCRirKGRB12jJKRw5EBjvj9hZNLEkSCeNLzMTYKl0cgBKzwH+zYJaTWMHOINDg/5GIbnqqFE6JVFZGmYMqPPK8U4PhdvL2tB5J9zLmC
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: qti.qualcomm.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM8PR02MB8122.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b3c2cb60-c318-42a8-dd33-08d93d367a6b
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2021 08:50:43.9938 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98e9ba89-e1a1-4e38-9007-8bdabc25de1d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7NY4wDzgrbYbSnw7AFuvQquTFFOdH6WMT5bzf32uzTWe0KDAi/CvKmVRWq1EJhhbVejbrI8rBlMTHiU21HHxEQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2633
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/w6rJ7udzenSh8GkwHXiMRhwsprI>
X-Mailman-Approved-At: Wed, 07 Jul 2021 08:51:42 -0700
Subject: Re: [Tsv-art] Tsvart early review of draft-zia-route-02
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jul 2021 08:50:58 -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) <rfc-ise@rfc-editor.org>
> Sent: 02 July 2021 10:45
> To: Joerg Ott <jo@acm.org>
> Cc: tsv-art@ietf.org; draft-zia-route.all@ietf.org
> Subject: Re: Tsvart early review of draft-zia-route-02
> 
> -------------------------------------------------------------------------
> CAUTION: This email originated from outside of the organization.
> -------------------------------------------------------------------------
> 
> 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),
> rfc-ise@rfc-editor.org
> 
> 
> 
> 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.
> >
> > 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?
> 
>