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? > >
- [Tsv-art] Tsvart early review of draft-zia-route-… Joerg Ott via Datatracker
- Re: [Tsv-art] Tsvart early review of draft-zia-ro… RFC ISE (Adrian Farrel)
- Re: [Tsv-art] Tsvart early review of draft-zia-ro… Gorry Fairhurst
- Re: [Tsv-art] Tsvart early review of draft-zia-ro… RFC ISE (Adrian Farrel)
- Re: [Tsv-art] Tsvart early review of draft-zia-ro… Waqar Zia
- Re: [Tsv-art] Tsvart early review of draft-zia-ro… Waqar Zia