[Raw] RtgDir Early review: draft-ietf-raw-technologies-06.txt
Victoria Pritchard <pritchardv0@gmail.com> Fri, 31 March 2023 21:50 UTC
Return-Path: <pritchardv0@gmail.com>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5DAC14CE31; Fri, 31 Mar 2023 14:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level:
X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIQcajec5WuR; Fri, 31 Mar 2023 14:50:05 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D95C15153C; Fri, 31 Mar 2023 14:50:02 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id g19so22987542qts.9; Fri, 31 Mar 2023 14:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680299402; x=1682891402; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=bA4MkOCu0yWB08wd4pwzGkwpN2zVG2w5aaN3cOXr8wk=; b=ZY7vEfFPRVZo6hKt4/3T5dfdj1vT3nvAGNeUEHxyzRlYma11H19PP6kD8wvuc1KS98 1xQPIcmZEGYbV4KodV/IcvPkwbEo1uL2uCWYxmKsG/LPc0HR/wF+d9kwbS70YWEd+0yR Xpr6x3UCAGqWDErifJRhmET6qU0QgUL3ETQ3tbxnXQ4xZNxJqT35uucg/OZI2lKo73Nw N7brPvNvxX8t6yzAuvxiw+ZyoJQ8q6jzttZu+mWBJ02KaF6HpweImPn90uZYSayI94Wl aRJ77r6+/3+bxUw/htIzJyG9vIYaIjZT9TyCb7O/YmsB34MHrb/y5E7aOhgIiMX/wOEy 7+dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680299402; x=1682891402; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bA4MkOCu0yWB08wd4pwzGkwpN2zVG2w5aaN3cOXr8wk=; b=cJ2FY3FUqotV1selG8274TBWZtz33sY4hruvh+MQY7VaHm/ueL145g+rb5+O3KBp9p i7HFa+IdnrcwYmDhGjAcS397wljfuEqTvc5jSGutkUqkAuZgMAxG0ZtQxO9rkf4kN5eN n6icqmAHN0L+XWfyW75FIJY3gMmRfaakyUYQf9L6rhe5fYq97GMWkEZwz0dYW+LrriDB GdvJ7+ap5Wl58qFadqxTKbXCjjjoVM2XfK7G4g8H/n+IuHosDVNlE4RdwkXgn80pS3gs LYAxvoD18PnRuitXoM6IQb5vdJNOK8opDEpa6dzSMYP6NGNs/UOOZRS4DS99wye+uSqd qyTg==
X-Gm-Message-State: AO0yUKWz5RwcOwcOSe1C15jfNVTAwxApAT43P1LRq0NV/WUor8wFe7fc cnJ/hKxwffakCH2ygu2ygalGZA9yC3cLAcLmUD0jWXSm550=
X-Google-Smtp-Source: AK7set/vuvcB1j5FJtgA7zxyDZHL0dZ5SDsIuwT/LL+uOadFzvL3hG2s9hv1ytH0nVsE4W5nUW4FI543DMeFvKqchJM=
X-Received: by 2002:a05:622a:451:b0:3bf:e265:9bf with SMTP id o17-20020a05622a045100b003bfe26509bfmr10988193qtx.5.1680299401334; Fri, 31 Mar 2023 14:50:01 -0700 (PDT)
MIME-Version: 1.0
From: Victoria Pritchard <pritchardv0@gmail.com>
Date: Fri, 31 Mar 2023 22:49:50 +0100
Message-ID: <CA+fLEhKzyTmo7GFkTyCDe4YEY6X83H7Gy1Y0P6LU10jn=TOLew@mail.gmail.com>
To: raw-chairs@ietf.org, draft-ietf-raw-technologies.all@ietf.org
Cc: rtg-dir@ietf.org, raw@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eed3b105f8393001"
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/FB5oCB09ZxvFcgcXT0YMYXbqS1w>
Subject: [Raw] RtgDir Early review: draft-ietf-raw-technologies-06.txt
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2023 21:50:09 -0000
Hello I have been selected to do a routing directorate “early” review of this draft: https://datatracker.ietf.org/doc/draft-ietf-raw-technologies/ This review was requested in advance of sending the document to the IESG. The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-raw-technologies-06.txt Reviewer: Victoria Pritchard Review Date: 20/03/2023-31/3/2023 Intended Status: Informational Summary: I have significant concerns about this document. It needs more work before being submitted to the IESG. Comments: First I'll admit I've not been following the discussion in the RAW working group, and maybe that's why I found this tough to read. Parts of it were really clear about the applicability of the different technologies highlighted, but I found a lot of it did not flow well, and contained a lot of information that either seemed too detailed or the relevance to deterministic flows wasn't made clear. I found myself doing extra research into the technologies and standards mentioned, especially for 802.11 and TSCH, and trying to work out why each detail was important, what it was aiming to highlight, and to fill in gaps where the explanation had assumed prior knowledge. What follows is a list of notes I made while reviewing, with some nits included, but also some suggestions and questions. I apologise in advance and understand if you disagree with any of my comments, as you may expect readers to be more familiar with the technologies presented. Kind regards, Victoria. ---- 1. Introduction I think a bit more about DetNet should be included here. DetNet gets mentioned a few times throughout the doc, might be good to describe very briefly what DetNet have covered, as well as the existing words about how additional methods are needed for wireless. The intro describes PAREO as a group of methods to do this, but the document is arranged by existing technologies rather than these types of methods - should probably list the technologies about to be discussed, and that the document will show how they use these methods to achieve reliability and availability. Nits: aspect -> aspects reach -> reaches must highly -> must be highly two . . at end of first bullet point a external -> external HARQ and P2MP - would be nice to see the acronym expanded here. Possibly a short description of HARQ to match the short description of P2MP overhearing. 2. Terminology Some items in this Terminology section are not really/clearly used within the doc: - Deterministic flow identifier (both L2 and L3) - Traffic type profile Nits: "that discussion takes place are in" - probalby dont need "are" "uncommon on protocols" - not sure this makes sense stochastics -> stochastic Deterministic Flow Identifier (L3) - extra "." in last sentence. Downlink only makes sense if you already read Uplink. Should these be in alphabetical order for easy reference? Under "traffic type profile" - should it say "has a one-to-one" instead of "as a one-to-one"? 3.1 Smartrid -> SmartGrid? Since timing is out of scope for RAW, could possibly condense some of this? e.g. "As an example, the Precision Time Protocol [IEEE 1588 and IEC 61588] is used by a number of protocols including Ethernet, industrial and Smartgrid protocols and Wi-Fi." 3.2 I would say that " (e.g., after 4 packets lost, within a period of 1 second)." isn't necessary. 3.3 Nits: "critical packets of diverse paths" - "critical packets on diverse paths" ? IOW - does this mean "in other words"? technoque -> technique "a nd" -> and 4.1 This section might benefit from a brief description of 802.1 TSN after introducing 802.11, before explaining where 802.11 has brought in support for TSN and referencing TSN standards. Naming Timing Measurement Protocol and Fine Timing Measurement doesnt seem necessary - it's not referred to later, and we were already told timing was out of scope for RAW. Could be simplified like this: "Support for TSN time synchronization was introduced in IEEE Std 802.11-2012 and enhanced in IEEE Std 802.11-2016. It uses 802.1AS. The IEEE Std 802.11-2016 also included the Stream Reservation Protocol (IEEE 802.1Qat)." I found the 4th paragraph to be an overwhelming list of different standards and protocols, I felt I needed to look these up individually to see how this was all relevant, but actually the way the different capabilities were linked to specifications/certifications later in this section was really useful and a nicer way to present the standards. If the history and evolution is important to highlight, I would keep this chronological - including skipping the first reference to 802.11ax and 802.11be in the 3rd paragraph. The bit that starts "As with any wireless media" should be in its own paragraph - I like how it highlights important considerations. Nits: retroffitted -> retrofitted Last sentence should say "remainder of this section" and mention 802.11ad and 802.11ay as section 4.4 discusses these too. Section 4.2.2 and 4.3.2 do a great job of focusing on relevant developments of 802.11. 4.2.2 need a space before "Nevertheless" 4.2.2.1 IEEE802.1Qcc first mentioned here - 802.1Qat was previously mentioned as Stream Reservation Protocol, and 802.1Qcc is an enhancement to this, it's worth clarifying. 4.2.2.2 first use of MCS but it is not expanded. "When the network in lightly loaded" -> "When the network is lightly loaded" 4.3.2.2 - the 3rd and 4th sentences in the first paragraph say the same thing. 4.3.2.3 "802.be Draft" - is this 802.11be? 4.4.1 - extra space at end of first paragraph, missing "." at end of second paragraph. Section 5 I found the hardest to read. I think some definitions could be presented earlier, and some detail could be removed. These are my notes from my first reading, tidied up after my second. 5.1 This section introduces term "Tracks" which is used a lot, before finally being explained in 5.2.2.2. Could probably leave out this sentence in the middle of the 3rd paragraph in 5.1 ("Yet the charter...")? But, considering Tracks are mentioned so much, would consider moving the definition from the start of 5.2.2.2 to somewhere around here. I also noticed 6top was mentioned later in the document, though only 6P is mentioned here. It may be useful for a brief overview, e.g. like the Terminology section of RFC9030 where it says 6TiSCH defines the 6top layer etc... and then says 6P operates at that layer enabling neighbour agreement. Then you could state how 6TiSCH focused on best effort traffic not quality of service requirements (currently mentioned in 3rd and 6th paragraphs). Maybe even mention how RPL fits in as RPL is mentioned a few times later without much introduction. I got lost in the detail of the 3rd paragraph. I'm not sure the info on scheduling functions is needed here as it's also mentioned in 5.2.1, could the detail be moved there? The 4th paragraph seems misplaced because the 5th paragraph then goes back to 6TiSCH. Could the paragraph about ISA100.11a and WirelessHART be placed before the 6TiSCH information? "Useful References" in this section - I think these would be better as paragraphs in the text rather than a list - the detail of the references should just be in the references section later. It would be good to include a sentence about why each is considered useful. 1. 802.15.4 is already referenced in the text so doesnt need repeating. 2. It is not explained why this is relevant. 3. Again doesn't explain why this is a useful reference. It's also not clear from the reference title itself that it is about 802.15.4, so I initially wondered if it's a more general reference about the benefits of packet replication, or particularly about packet replication in TSCH, i.e. whether it should be in this TSCH section or not. Could you add a statement like: " A study by ... looked at the benefits of packet replication in TSCH networks." I think it links with your sentence about what RAW can add, after the ISA100.11a and WirelessHART text. CoAP is not expanded. Overall thoughts on 5.1. I think 5.1 is trying to say "802.15.4 is for low-power low-cost radio. The 2015 update covers TSCH. Interesting standards addressing time sensitive networking over TSCH include ISA100.11a and WirelessHART, which both define a central controller computing redundant paths. ISA100.11a has limited IPv6 capabilities, and RAW could help with optimised P2P routing, PAREO functions and end to end IPv6/CoAP. Also the 6TiSCH group already looked at IPv6 over TSCH, and defined an architecture which includes a distributed scheduling mechanism. But 6TiSCH focused on best effort traffic not time sensitive networking. RAW needs to build on this." I dont think it flows very well as-is. 5.2.1 Figure 1 - a quick note to expand EB would be nice. For the statement "managed by a scheduling function such as" MSF - That scheduling function was defined by 6TiSCH, so it made me wonder how 802.15.4 TSCH defines scheduling functions, since this section is TSCH general characteristics, not 6TiSCH specifically? Not sure all the detail is needed here, especially: "A cell's timeslot offset indicates its position in time, relative to the beginning of the slotframe. A cell's channel offset is an index which maps to a frequency at each iteration of the slotframe. " " An Absolute Slot Number (ASN) indicates the number of slots elapsed since the network started. It increments at every slot. This is a 5 byte counter that can support networks running for more than 300 years without wrapping (assuming a 10 ms timeslot)." Is the channel hopping (mentioned at the end of the paragraph below Figure 1) different to the scheduling function (eg MSF) mentioned earlier? Parts of the final paragraph of 5.2.1 would fit better in 5.2.2 as its more about the RAW context and further work, rather than the general characteristics of TSCH. 5.2.2 Nits: "This enables to build" -> "This enables building" ensure -> ensures "scheduling is a key" -> "scheduling is key" Again mentions Tracks but they havent really been explained yet. overprovisionned, overprovisionning -> single n measu reth excursion -> measure the excursion ? not sure what this means. 5.2.2.1 Nits: iprovides -> provides I didnt understand the sentence with "(to be)" in brackets: For that case, the expectation is that a protocol that flows along a Track (to be), in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. I feel 5.2.2.1 is lacking a bit of intro... Maybe something like: "When looking at end-to-end communication over TSCH....." or "The nodes can be provided with their schedules ..." then discuss the Operational Control System, the PCE computing the tracks and provisioning every hop. I also feel like this bit of the architecture could have been clearer earlier in 5.1 when introducing 6TiSCH. So in a hybrid mode, to update Tracks, it wouldnt be driven from the same control system involving the PCE? I understood from this paragraph that a potential need has been identified, but there is no design for this flow yet, and in any case, DetNet is expected to cover this, and the 6TiSCH neighbour negotiation might be useful in the solution. The bit "for, say, Packet Delivery Ratio (PDR)" is an extra detail that could be removed to help keep this concise, maybe the neighbour negotiation part too. Should Figure 2 have a caption? 5.2.2.1.1 - Does the information in the following sections cover the most relevant parts of that section of RFC9030 then? 5.2.2.1.1.1 RPLInstanceID - not explained until 5.2.2.1.3. Trying to work out if this is just extra detail or has relevance to RAW. Would it be enough to simplify to: "Packets that are routed by a PCE along a Track, are tagged to uniquely identify the Track and associated transmit bundle of timeSlots."...? LLN also not expanded. Should 6lo be also? Figure 4 - what are DP and AP in the caption? p23. "a'OR'relations" -> "an 'OR' relation" ... or "'OR' relations" ? a'AND'relation -> "an 'AND' relation" In general put spaces around 'OR' and 'AND'. I found it hard to understand this part with 'OR' and 'AND'. Looks like some of this has come directly from RFC9030 - can it be summarised a little, or an example given? Can it be related back to Figure 4? The second paragraph is very similar in content but a bit clearer to read. Thoughts on simplifying this explanation - maybe something like: "6TiSCH architecture defines packet replication where timeslots can be grouped such that if any one of those timeslots results in successful transmission, the other timeslots (which may be on the same path, or on other paths) are not needed (the 'OR' relation), or where multiple transmissions on different paths are required (the 'AND' relation between groups)." 5.2.2.1.3 Some of this might fit well in the first paragraphs about 6TiSCH in 5.1, especially mention of RPL as RPLInstanceID is used in a few places without being explained. If the route is associated with a track, where is the Instance ID from? 5.2.2.1.4 Nits: fond -> found No "." at end of 1st paragraph. This starts with 'elaboration can be found' but then elaborates here too, with sentences duplicated from RFC9030. Can it be condensed a bit to pull out the most relevant parts? "SlotFrames and Priorities" isn't the name of the heading in 9030 anymore, it's "Slotframes and CDU Matrix". Things that weren't clear from this explanation: - Does the matrix show scheduled transmissions, i.e. the cells which are allocated? What's the difference between a CDU and a slotframe? Figure 1 earlier showed a slotframe, which was a matrix of channels and timeslots too. - Why/how are multiple CDU matrices used? - When the text moves on to talk about slotframes, it mentions precedence. Multiple slotframes of multiple precedence...relating to precedence of 6TiSCH topologies. I suppose this means the slotframe with highest precedence is honoured first, then perhaps if there are free timeslots, the slotframe with the next precedence is considered? At the end of this section, it tries to highlight where the gap is from the work done in 6TiSCH and what RAW needs to do, but I didnt really understand the explanation before it. It also uses the phrase "then again" which suggests the text before it may not be certain? I didnt understand: The PCE assigns cells to chunks, then appropriation is requested "by the PCE to any node", but then the PCE owns the chunk? Does it mean the node owns the chunk, and is this a reference to the part earlier about a hybrid mode? 5.2.2.2 6TiSCH tracks PDR - does it mean "packet delivery ratio" here? I found this section pretty clear but think it might have been useful earlier. 5.2.2.2.2 I found these very detailed, not sure if it's all needed. I kept trying to relate it back to what was relevant for RAW and struggled to keep focused. I tried to summarise my understanding. - Track forwarding - Because receive cells are paired to transmit cells, it doesnt need changes in MAC header, and the protocol contained in the frame doesnt matter. All cells that were reserved may not be needed, so can be reused for opportunistic traffic. On the other hand, unscheduled but necessary retransmissions can use cells which weren't reserved (subject to some details) and this would be referred to as off-Track. A frame may then be re-Tracked (ie forwarded in a cell intended for that track). - Transport and tunnel mode - for transport mode, the metadata already exists (added by higher layer) so its obvious which track is to be used. For transport mode, the data would come from a device without the metadata, but the PCE would specify how to identify that it should be transported over the track, and where to egress, and metadata would be added on ingress at the first 6TiSCH router. This bit seems like a lot of detail duplicated from RFC9030, and I can't really see why it's included. Note: transport mode seems to be called native mode in RFC9030. 5.2.2.2.2.3 Again seems like too much detail. 5.2.2.2.2.4 This bit on OAM seems relevant, to mention that more work is necessary and it highlights useful work in this area. 6.1 - 6.3 There's a lot of detail here about the timeline of different studies and releases. Would it be clearer to state the aims, its current release, and mention the existing features/enhancements, and maybe future plans where relevant? 6.1 says that Release 18 will support DetNet, but 6.5 and 6.4.5 mention DetNet with earlier releases. 6.4.1 Figure 10 - expanding some acronyms below the picture may be helpful. There's a lot of detail on handovers - I guess this is trying to highlight the elements that make handovers reliable, but could be more concise. 6.4.3 The first paragraph is clear but there's a lot of detail in the rest of this section, I think the point is to highlight use of retransmissions, scheduling, coding and modulation for reliability, reporting of link quality, efficiency, but I found it hard to follow. 6.4.5 Nits: ((TSC) -> (TSC) Time- Sensitive -> Time-Sensitive "the meet their QoS requirements" -> "they meet their QoS requirements" "reference time in not only" -> "reference time is not only" Figure 10 is mentioned but I think it means Figure 11, which is closer and shows 5G-TSN integration as described. Figure 10, 12, 13 - not sure what DN means. Figure 11 - DSTT, NWTT not defined (probably device side TSN translator and network side) Page 49 final paragraph mentions Figure 13 but describes Figure 12 at the top of page 50. "and the core network," -> "and the core network." Page 49 middle paragraph. "3GPP release 18 includes a study" ... then at the end of the paragraph "the standards are ready for such an approach, it is out of scope for the 3GPP Release 18 study item" - This confused me. What bit is out of scope? Could this change to: IETF Deterministic Networking (DetNet) is the technology to support time-sensitive communications at the IP layer. Note that TSN is the primary subnetwork technology for DetNet. Thus, the DetNet over TSN work, e.g., [RFC9023], can be leveraged via the TSN support built in 5G. Along the TSC framework introduced for Release 17, the 5GS acts as a DetNet node for the support of DetNet. 3GPP Release 18 includes a study item [TR2370046] on interworking between 5G and DetNet, showing the existing approach in Figure 7.1-1 of [TR2370046]. The study item provides details on how the 5GS is exposed by the Time Sensitive Communication and Time Synchronization Function (TSCTSF) to the DetNet controller as a router on a per UPF granularity (similarly to the per UPF Virtual TSN Bridge granularity shown in Figure 11). In particular, it is listed what parameters are provided by the TSCTSF to the DetNet controller. The study also includes how the TSCTSF maps DetNet flow parameters to 5G QoS parameters. 6.5 Summary I didn't find this very clear regarding DetNet. Perhaps because I'm not familiar enough in general with these technologies so I apologise if that's the case. This section says 5G can be used as subnet technology for DetNet. Then says "support for integration with TSN reliability was added to 5G by making DetNet reliability also applicable, thus making 5G DetNet ready". Was 5G "DetNet ready" before this, because the previous statement says 5G could be used as subnet technology for DetNet...? Then it also says adding direct support for DetNet is in scope for release 18... what does "direct support" mean? 7.2 - CNS not expanded. 7.4.2 Figure 14 - most of the acronyms are explained in the paragraph above but DCH, DCCH, CCCH, RACH, BCCH are not. It might be too critical of me but I'd like to see a small mention of them before they are covered in later paragraphs. Maybe expand them at the bottom of the diagram, or add something in the sentence introducing Figure 14 e.g. "Data passing between the Logical Link Control Layer and the Medium Access Layer is categorised into channels." Or simplify the diagram by taking them out and having clean lines between the blocks. 7.4.4 page 59 "Resources can either be requested" - there's no matching 'or', you could remove the "either" since the description of this first option fills the rest of the paragraph. I wonder how much of this detail is needed - 7.4 is about applicability to deterministic flows, so maybe this detail could be reduced to highlight that, with a reference to the detail?
- [Raw] RtgDir Early review: draft-ietf-raw-technol… Victoria Pritchard