From nobody Tue May 1 00:31:33 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D70B126BF7 for ; Tue, 1 May 2018 00:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 j3V8_kVg9EU7 for ; Tue, 1 May 2018 00:31:21 -0700 (PDT) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA9C120047 for ; Tue, 1 May 2018 00:31:20 -0700 (PDT) Received: from supmail (supmail.isae.fr [10.132.1.9]) by smtpextng.isae.fr (Postfix) with ESMTP id 306AE7127C; Tue, 1 May 2018 09:31:19 +0200 (CEST) Received: from smtp-secung (smtp-secung.isae.fr [192.93.254.79]) by supmail (Postfix) with ESMTP id 1B4E7C88614; Tue, 1 May 2018 09:31:19 +0200 (CEST) Received: from [192.168.1.59] (c2s31-2-83-152-88-205.fbx.proxad.net [83.152.88.205]) by smtp-secung (Postfix) with ESMTPSA id E966B70CBA; Tue, 1 May 2018 09:31:18 +0200 (CEST) To: "tsvwg@ietf.org" Cc: nwcrg@irtf.org References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> From: Emmanuel Lochin Message-ID: <4def2897-d0f1-c864-1664-f1b2ffb3ebd5@isae-supaero.fr> Date: Tue, 1 May 2018 09:31:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> Content-Type: multipart/alternative; boundary="------------C49F13D385E9E9A9090C32C4" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 07:31:25 -0000 This is a multi-part message in MIME format. --------------C49F13D385E9E9A9090C32C4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document quite clear, well-written and self-contained. I just have the following suggestions: The authors argue that "/FECFRAME provides FEC protection for arbitrary packet flows over unreliable transports such as UDP/". RFC5348 proposes TFRC, an unreliable rate-based protocol which does not send data packets in a continuous manner at the same peak rate mimicking TCP average sending rate behavior or RFC4341 proposes DCCP CCID#2 congestion control which is an equivalent TCP window-based algorithm without retransmission. I reckon it is a good idea to dissociate transport layers operations from sliding encoding operations. But keeping in mind these both protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the sentence "The data packets of continuous media flow(s) can be sent immediately, without delay." : "sent" is understood as "sent over the network" while this is not true depending on which unreliable transport protocol is used, so it should be "passed to the transport layer" as "sent over the network" only apply to UDP which does not schedule, pace or stop the sending. Actually some parts of this draft seem to consider that when source data or redundancy packets are built, they are simply sent over the network without delay. This is not always the case, so to be accurate I would suggest to correct by "passed to the transport layer" as correctly illustrated Fig. 1. Same applies for : "since repair symbols can be generated and sent on-the-fly," "In practice FEC Source Packets can be sent as soon as available, without having to wait for FEC encoding to take place". This sounds like a priority scheduling between source data packets against repair packets. May be "Encoding operations should not influence data packets processing: FEC Source Packets should never be delayed and should always remain available to be passed to the transport layer." "Protection amount" is defined but not used in this document. The definition suggests a kind of cross-layer with the transport protocol or a kind of application flow control. Should be either discussed nay suppressed. EL On 17/04/2018 06:30, Wesley Eddy wrote: > (on behalf of all three TSVWG chairs) > > This email is to start a TSVWG working group last call on the sliding > window FECFRAME extensions, and random linear code FEC scheme drafts: > > (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ > > (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ > > We would like to collect any comments within 3 weeks (until around May > 8).  We believe all of the comments raised in the past have been > addressed, and that these are ready to go for Proposed Standard. > > I'm cross-posting this to the Network Coding RG, since there are some > experts that may not be on TSVWG, but we'd like any comments to go to > the TSVWG list please. > > Thanks in advance. > > > _______________________________________________ > nwcrg mailing list > nwcrg@irtf.org > https://www.irtf.org/mailman/listinfo/nwcrg -- Emmanuel LOCHIN Professeur ISAE ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30 --------------C49F13D385E9E9A9090C32C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear all,

Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document quite clear, well-written and self-contained. I just have the following suggestions:

The authors argue that "FECFRAME provides FEC protection for arbitrary packet flows over unreliable transports such as UDP". RFC5348 proposes TFRC, an unreliable rate-based protocol which does not send data packets in a continuous manner at the same peak rate mimicking TCP average sending rate behavior or RFC4341 proposes DCCP CCID#2 congestion control which is an equivalent TCP window-based algorithm without retransmission.

I reckon it is a good idea to dissociate transport layers operations from sliding encoding operations. But keeping in mind these both protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the sentence "The data packets of continuous media flow(s) can be sent immediately, without delay." : "sent" is understood as "sent over the network" while this is not true depending on which unreliable transport protocol is used, so it should be "passed to the transport layer" as "sent over the network" only apply to UDP which does not schedule, pace or stop the sending. Actually some parts of this draft seem to consider that when source data or redundancy packets are built, they are simply sent over the network without delay. This is not always the case, so to be accurate I would suggest to correct by "passed to the transport layer" as correctly illustrated Fig. 1.

Same applies for : "since repair symbols can be generated and sent on-the-fly,"

"In practice FEC Source Packets can be sent as soon as available, without having to wait for FEC encoding to take place". This sounds like a priority scheduling between source data packets against repair packets. May be "Encoding operations should not influence data packets processing: FEC Source Packets should never be delayed and should always remain available to be passed to the transport layer."

"Protection amount" is defined but not used in this document. The definition suggests a kind of cross-layer with the transport protocol or a kind of application flow control. Should be either discussed nay suppressed.

EL



On 17/04/2018 06:30, Wesley Eddy wrote:
(on behalf of all three TSVWG chairs)

This email is to start a TSVWG working group last call on the sliding window FECFRAME extensions, and random linear code FEC scheme drafts:

(1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/

(2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/

We would like to collect any comments within 3 weeks (until around May 8).  We believe all of the comments raised in the past have been addressed, and that these are ready to go for Proposed Standard.

I'm cross-posting this to the Network Coding RG, since there are some experts that may not be on TSVWG, but we'd like any comments to go to the TSVWG list please.

Thanks in advance.


_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg

-- 
Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30
--------------C49F13D385E9E9A9090C32C4-- From nobody Tue May 1 11:15:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1DF12E8E4 for ; Tue, 1 May 2018 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 2mlICiqCFIKj for ; Tue, 1 May 2018 11:15:21 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 75EDF12E8DD for ; Tue, 1 May 2018 11:15:21 -0700 (PDT) Received: from dhcp-207-156.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:55db:d709:da15:80c2]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9B1D21B000FD; Tue, 1 May 2018 19:15:19 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk To: Wesley Eddy , tsvwg WG References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <2c6d2c0b-202a-b061-de3b-c5d5b5f62550@erg.abdn.ac.uk> Date: Tue, 1 May 2018 19:15:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] WGLC on FECFRAME sliding window extensions X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:15:25 -0000 I have the read draft-ietf-tsvwg-fecframe-ext-01 during WGLC and have a few comments (as an individual), Gorry ---- The following is stated: /. (e.g., because of a congested router, of a poor signal-to-noise ratio in a wireless network, or because the number of bit errors exceeds the correction capabilities of a low-layer error correcting code)./ - while this is true, it is probably wise to assert that most links supporting IP employ a CRC or other integrity check to verify this correctness, and that this is assumed. RFC3819 may be a suitable reference. --- The terms RTP and DCCP are mentioned, but the base spec RFCs in each case are not cited. --- / This section discusses the protocol elements for the FEC Framework./ This section uses requirements language, and therefore the intro para needs to say how this applies. - It seems to me that this section does more than discuss, and some of it is actually to specify? From nobody Tue May 1 11:16:00 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F312E8E4 for ; Tue, 1 May 2018 11:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 IdcqaddJeT-M for ; Tue, 1 May 2018 11:15:56 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 3447C12E8DD for ; Tue, 1 May 2018 11:15:56 -0700 (PDT) Received: from dhcp-207-156.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:55db:d709:da15:80c2]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 515191B000FD; Tue, 1 May 2018 19:15:55 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk To: Wesley Eddy , "tsvwg@ietf.org" Cc: nwcrg@irtf.org References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Tue, 1 May 2018 19:15:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] WGLC on FECFRAME RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:15:59 -0000 I have the read draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and have the following comments (as an individual). These comments are all on the text and the standards requirements being stated, they do not request changes to the method. Gorry --- / They are meant to protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes./ - I think the word /meant/ reads a little weird. Rather as if they maybe do not do this. I suggest something like /They can provide protection to/ may be better? --- Just to be sure, I would add /packet/ or something to /erasure recovery capabilities/ to be clear that this is not a bit-level FEC. Perhaps the first use of /FEC/ could also be better as /Application-Lyer FEC/ for the same purpose? --- /in case of reliable file transfers/ could be clearer as: /when used for reliable file transfers/ --- /Defining this block size requires to find an/ could be easier as: /To define the block size, it is required to find an/ --- In 1.2 it states: /This choice will impact all receivers./ - Maybe I misunderstand, but does it impact a receiver that sees no loss, because that could (in theory) act on the data as it arrives? --- /are extremely efficient/ - This seems like a value judgment. I'd be content with saying /efficient/, but to say more I feel really needs a strong evidence that has consensus. RFCs must not be used to market techniques. ---- /latency close to zero/ - same comment, but perhaps this could be stated as /of the order of the time to transmit a packet/ our similar? --- /waiting the end of the block for the first repair packet to arrive./ - perhaps clearer as: /waiting for the first repair packet to arrive at the end of the block./ --- /sliding window codes achieve more easily a target/ - perhaps clearer as: /sliding window codes can more achieve more efficiently achieve a target/ --- /The Sliding Window RLC FEC Scheme is designed so as to reduce the transmission overhead/ - perhaps clearer as: /The Sliding Window RLC FEC Scheme is designed to reduce transmission overhead/ -> however I note the next phrases talk about /minimize packet overhead/, which could be seen as header bytes, is the distinction intended, then please explain - if not please use the same term. ---- /receiver to easily reconstruct/ - remove /easily/, or say they are /sufficient to allow a receiver to reconstruct/ or whatever, but avoid the value statement. --- This strikes me as a little odd: /In all situations, we MUST have:/ - If this is an actual RFC2119 requirement, then you need to state it terms of what the message contains. Although here I am unsure this is a protocol requirement, and if that is the case, it could be better to state the /method needs to ensure:/? --- This seems an off phrase in a specification: / In practice they will usually be fixed, especially with multicast/broadcast transmissions. / - could it instead be true to say something like /An implementation at a sender and receiver can fix these values/... or something like. --- /Let us assume that the/ and /Let us also assume/ - seems rather like a paper, than a specification. Could this be reworded as /In the case when the code rate is .../etc.? --- /It means that the source flow bitrate needs to be/ May be easier as: /This requires the source flow bitrate to be/ --- Similarly: /It means that the transmission bitrate/ as /This requires the transmission bitrate/ -> but I have a question. of whether the /flow bitrate/ or /the transmission bitrate/ are actually different, and if not=, then why use two terms? Do we need either term as a /rate/ since this appears to be about volume of data and not rate? --- /Finding the optimal value/ - I am unsure how you would define /optimal/ here, is it possible to say suitable/acceptable tradeoff or something like that without implying a need for optimal? /and should be determined after simulations or field trials. This is of course out of scope of this document. / - and finished like it is a report, rather than a specification. Is it therefore possible to simply say something like /An appropriate tradeoff needs to be determined depending on the use case..../ --- In section 3.2 /An ADU, coming from the application/ - is this at the sender? - just to be sure? --- / Indeed, a lost ADU recovered at a receiver must contain enough information to be assigned to the right application flow (UDP port numbers and IP addresses cannot be used to that purpose as they are not protected by FEC encoding). / - I could not parse this. Are the UDP port numbers and IP addresses not protected by the link integrity check and IP/transport checksum? - If they were corrupted they would cause the packet to be delivered to another endpoint??? what is this about? --- There seems to be no requirements language at all in section 3.1. Is this intended? --- Section 3.2 speaks of /UDP/ datagrams. I am not sure this is correct, surely this applied to any type of datagram - DCCP, UDP, or anything else that could in the future carry FECFRAME. --- / Yet, any other implementation of the PRNG algorithm that matches the above validation criteria, like the ones detailed in [PM88], is appropriate. / - is that actually saying an implementation MAY use any PRNG algorithm that matches .../ --- / The FEC Framework Configuration Information (or FFCI) includes information that MUST be communicated between the sender and receiver(s)./ - This confuses me about what are the specific requirements, can you please ensure that all the fields in this subsection carry an appropriate RFC2119 keyword (in upper case), to say which are OPTIONAL, REQUIRED, etc and what they MUST/MAY etc specify. --- /A FEC Repair Packet can contain one or more repair symbols./ - is that a statement, or a permission? e.g., /A FEC Repair Packet MAY contain one or more repair symbols./ --- /integer carried the Density Threshold/ - is this /carries/ --- Is this discussion OK, or do you think we need to define the protocol actions using RFC2119 keywords: / The only constraint is to increment by 1 the repair key for each of them, keeping the same ew_size source symbols, since only the first repair key will be carried in the Repair FEC Payload ID. The FEC Repair Packet can then be sent./ - /sent/ probably should be /passed to the transport layer for transmission./ --- / containing an ADU, can be passed to the application either immediately or after some time to guaranty an ordered delivery to the application. / - This reads like it could be /MAY be passed/ --- / received after this delay should not be passed to the application./ - I am unsure whether this needs to be read as /ought/ or /SHOULD/ could you use one of these instead of /should/? --- In addition some standard transport comments that ought to be fine tuned: / Repair packets (symbols) are generated and sent on-the-fly/ - seems to perhaps be possibly to read as avoids CC, which it should not. Please be careful to indicate that packets are /passed to the transport layer for transmission/, if you think that these may be sent with higher priority than other messages, then please explicitly say this. --- /where packets are sent with a fixed period/ - I think a word of caution here is needed with respect to CC. So this probably needs to be carefully worded, or at least say /are passed to the transport layer each fixed period/. --- /The FEC Repair Packet can then be sent./ ... maybe: /passed to the transport layer for transmission/ --- From nobody Wed May 2 02:04:00 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F099C12D94B; Wed, 2 May 2018 02:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152525183693.11419.2525545895238341109@ietfa.amsl.com> Date: Wed, 02 May 2018 02:03:56 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 09:03:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Forward Error Correction (FEC) Framework Extension to Sliding Window Codes Authors : Vincent Roca Ali Begen Filename : draft-ietf-tsvwg-fecframe-ext-02.txt Pages : 20 Date : 2018-05-02 Abstract: RFC 6363 describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However FECFRAME as per RFC 6363 is restricted to block FEC codes. The present document extends FECFRAME to support FEC Codes based on a sliding encoding window, in addition to Block FEC Codes, in a backward compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-fecframe-ext-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 2 02:24:53 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A0112D94B for ; Wed, 2 May 2018 02:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 jr98mOT4z5jl for ; Wed, 2 May 2018 02:24:49 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 359951270A7 for ; Wed, 2 May 2018 02:24:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,354,1520895600"; d="scan'208,217";a="264050963" Received: from unknown (HELO [192.168.16.115]) ([193.55.47.18]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 11:24:35 +0200 From: Vincent Roca Message-Id: <2FE4EB87-CEA7-44C3-B85D-6204D2853ACE@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF45C4A4-A0E2-4E3A-BBFC-390744EE6035" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 2 May 2018 11:24:34 +0200 In-Reply-To: <4def2897-d0f1-c864-1664-f1b2ffb3ebd5@isae-supaero.fr> Cc: Vincent Roca , "tsvwg@ietf.org" , nwcrg@irtf.org To: Emmanuel Lochin References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> <4def2897-d0f1-c864-1664-f1b2ffb3ebd5@isae-supaero.fr> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 09:24:52 -0000 --Apple-Mail=_FF45C4A4-A0E2-4E3A-BBFC-390744EE6035 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Emmanuel, Thanks a lot for your review. I=E2=80=99ve just posted version -02 that = takes your suggestions into account. More precisely: > Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document = quite clear, well-written and self-contained. I just have the following = suggestions: >=20 >=20 > The authors argue that "FECFRAME provides FEC protection for arbitrary = packet flows over unreliable transports such as UDP". RFC5348 proposes = TFRC, an unreliable rate-based protocol which does not send data packets = in a continuous manner at the same peak rate mimicking TCP average = sending rate behavior or RFC4341 proposes DCCP CCID#2 congestion control = which is an equivalent TCP window-based algorithm without = retransmission.=20 >=20 > I reckon it is a good idea to dissociate transport layers operations = from sliding encoding operations. But keeping in mind these both = protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the = sentence "The data packets of continuous media flow(s) can be sent = immediately, without delay." : "sent" is understood as "sent over the = network" while this is not true depending on which unreliable transport = protocol is used, so it should be "passed to the transport layer" as = "sent over the network" only apply to UDP which does not schedule, pace = or stop the sending. Actually some parts of this draft seem to consider = that when source data or redundancy packets are built, they are simply = sent over the network without delay. This is not always the case, so to = be accurate I would suggest to correct by "passed to the transport = layer" as correctly illustrated Fig. 1. VR: You=E2=80=99re right. In addition to congestion control, traffic = shaping may also delay packet transmissions (this is what we considered in our work where we considered a CBR link, = re-using 3GPP use-cases). NEW:=20 The data packets of continuous media flow(s) may be = passed to the transport layer immediately, without delay. > Same applies for : "since repair symbols can be generated and sent = on-the-fly, =C2=BB VR: Fixed. NEW: since repair symbols can be generated and passed to the transport layer on-the-fly, [=E2=80=A6] > "In practice FEC Source Packets can be sent as soon as available, = without having to wait for FEC encoding to take place". This sounds like = a priority scheduling between source data packets against repair = packets. May be "Encoding operations should not influence data packets = processing: FEC Source Packets should never be delayed and should always = remain available to be passed to the transport layer. =C2=BB VR: In fact there are several design options WRT to the question of = "when to send source and repair packets =C2=BB. See: = https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-63= -fecframe-drafts-00 = (slide 17). I don=E2=80=99t see good reasons to enter that type of detail in this = document, so I=E2=80=99ve opted to a more neutral sentence (using =C2=AB may =C2=BB) than what was there and what you propose = (where =C2=AB should =C2=BB is too strong). OLD: In practice FEC Source Packets can be sent as soon as available, without having to wait for FEC encoding to take = place. NEW: In practice FEC Source Packets may be passed to the transport layer as soon as available, without having to wait for = FEC encoding to take place. > "Protection amount" is defined but not used in this document. The = definition suggests a kind of cross-layer with the transport protocol or = a kind of application flow control. Should be either discussed nay = suppressed. VR: Removed. It was inherited from RFC6363 definitions, but there also, = it was not explicitly used in the text. > EL Cheers, Vincent= --Apple-Mail=_FF45C4A4-A0E2-4E3A-BBFC-390744EE6035 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Emmanuel,

Thanks a = lot for your review. I=E2=80=99ve just posted version -02 that takes = your suggestions into account.
More precisely:

Having = reviewing draft-ietf-tsvwg-fecframe-ext, I found this document quite clear, well-written and self-contained. I just have the following suggestions:


The authors argue that "FECFRAME provides FEC = protection for arbitrary packet flows over unreliable transports such as = UDP". RFC5348 proposes TFRC, an unreliable rate-based protocol which does not send data packets in a continuous manner at the same peak rate mimicking TCP average sending rate behavior or RFC4341 proposes DCCP CCID#2 congestion control which is an equivalent TCP window-based algorithm without retransmission.

I reckon it is a good idea to dissociate transport layers operations from sliding encoding operations. But keeping in mind these both protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the sentence "The data packets of continuous media flow(s) can be sent immediately, without delay." : "sent" is understood as "sent over the network" while this is not true depending on which unreliable transport protocol is used, so it should be "passed to the transport layer" as "sent over the network" only apply to UDP which does not schedule, pace or stop the sending. Actually some parts of this draft seem to consider that when source data or redundancy packets are built, they are simply sent over the network without delay. This is not always the case, so to be accurate I would suggest to correct by "passed to the transport layer" as correctly illustrated Fig. = 1.

VR: You=E2=80=99re right. In addition to = congestion control, traffic shaping may also delay packet transmissions = (this is what
we considered in our work where = we considered a CBR link, re-using 3GPP use-cases).

NEW: 
The data packets = of continuous media flow(s) may be passed to the = transport layer immediately, without delay.


=20 Same applies for : "since repair symbols can be generated and sent on-the-fly, =C2=BB

VR: Fixed.

NEW:
since repair symbols can be = generated and passed to = the
transport layer on-the-fly, [=E2=80=A6]
=

=20 "In practice FEC Source Packets can be sent as soon as available, without having to wait for FEC encoding to take place". This sounds like a priority scheduling between source data packets against repair packets. May be "Encoding operations should not influence data packets processing: FEC Source Packets should never be delayed and should always remain available to be passed to the transport layer. =C2=BB

VR: In fact there are several design options WRT = to the question of "when to send source and repair = packets =C2=BB.
I don=E2=80=99= t see good reasons to enter that type of detail in this document, so = I=E2=80=99ve opted to a more neutral sentence
(using = =C2=AB may =C2=BB) than what was there and what you propose = (where =C2=AB should =C2=BB is too strong).

OLD:
In practice FEC Source Packets = can be sent = as soon as
available, without having to wait = for FEC encoding to take place.

NEW:
In practice FEC Source Packets = may be passed to = the
transport = layer as soon as available, without having to wait for = FEC
encoding to take = place.


"Protection amount" is defined but not used in this document. The definition suggests a kind of cross-layer with the transport protocol or a kind of application flow control. Should be either discussed nay suppressed.

VR: = Removed. It was inherited from RFC6363 definitions, but there also, it = was not explicitly used in the text.


=20 EL

Cheers,

  = Vincent
= --Apple-Mail=_FF45C4A4-A0E2-4E3A-BBFC-390744EE6035-- From nobody Wed May 2 03:27:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08E412E046 for ; Wed, 2 May 2018 03:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 u2GYO5CbVDx5 for ; Wed, 2 May 2018 03:27:07 -0700 (PDT) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id DF8E812E048 for ; Wed, 2 May 2018 03:27:06 -0700 (PDT) Received: from smtp-secu-int (smtp-secu-int.isae.fr [10.132.1.48]) by smtpextng.isae.fr (Postfix) with ESMTP id 4AA8D71289; Wed, 2 May 2018 12:27:05 +0200 (CEST) Received: from [10.161.3.211] (pc-lochin.isae.fr [10.161.3.211]) by smtp-secu-int (Postfix) with ESMTPSA id 44FAD781E9; Wed, 2 May 2018 12:27:05 +0200 (CEST) To: Vincent Roca Cc: "tsvwg@ietf.org" , nwcrg@irtf.org References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> <4def2897-d0f1-c864-1664-f1b2ffb3ebd5@isae-supaero.fr> <2FE4EB87-CEA7-44C3-B85D-6204D2853ACE@inria.fr> From: Emmanuel Lochin Message-ID: Date: Wed, 2 May 2018 12:27:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2FE4EB87-CEA7-44C3-B85D-6204D2853ACE@inria.fr> Content-Type: multipart/alternative; boundary="------------7A7B898F4205233BDAC59B97" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 10:27:11 -0000 This is a multi-part message in MIME format. --------------7A7B898F4205233BDAC59B97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Vincent, I'm fine with all your answers/corrections. Cheers EL Le 02/05/2018 à 11:24, Vincent Roca a écrit : > Hello Emmanuel, > > Thanks a lot for your review. I’ve just posted version -02 that takes > your suggestions into account. > More precisely: >> >> Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document >> quite clear, well-written and self-contained. I just have the >> following suggestions: >> >> >> The authors argue that "/FECFRAME provides FEC protection for >> arbitrary packet flows over unreliable transports such as UDP/". >> RFC5348 proposes TFRC, an unreliable rate-based protocol which does >> not send data packets in a continuous manner at the same peak rate >> mimicking TCP average sending rate behavior or RFC4341 proposes DCCP >> CCID#2 congestion control which is an equivalent TCP window-based >> algorithm without retransmission. >> >> I reckon it is a good idea to dissociate transport layers operations >> from sliding encoding operations. But keeping in mind these both >> protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the >> sentence "The data packets of continuous media flow(s) can be sent >> immediately, without delay." : "sent" is understood as "sent over the >> network" while this is not true depending on which unreliable >> transport protocol is used, so it should be "passed to the transport >> layer" as "sent over the network" only apply to UDP which does not >> schedule, pace or stop the sending. Actually some parts of this draft >> seem to consider that when source data or redundancy packets are >> built, they are simply sent over the network without delay. This is >> not always the case, so to be accurate I would suggest to correct by >> "passed to the transport layer" as correctly illustrated Fig. 1. > > VR: You’re right. In addition to congestion control, traffic shaping > may also delay packet transmissions (this is what > we considered in our work where we considered a CBR link, re-using > 3GPP use-cases). > > NEW: > The datapackets of continuous media flow(s) may be passed to the > transport layer immediately, without delay. > > >> Same applies for : "since repair symbols can be generated and sent >> on-the-fly, » > > VR: Fixed. > > NEW: > since repair symbols can be generated and passed to the > transport layer on-the-fly, […] > > >> "In practice FEC Source Packets can be sent as soon as available, >> without having to wait for FEC encoding to take place". This sounds >> like a priority scheduling between source data packets against repair >> packets. May be "Encoding operations should not influence data >> packets processing: FEC Source Packets should never be delayed and >> should always remain available to be passed to the transport layer. » > > VR: In fact there are several design options WRT to the question of > "when to send source and repair packets ». > See: > https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-63-fecframe-drafts-00 (slide > 17). > I don’t see good reasons to enter that type of detail in this > document, so I’ve opted to a more neutral sentence > (using « may ») than what was there and what you propose (where > « should » is too strong). > > OLD: > In practice FEC Source Packets can be sent as soon as > available, without having to wait for FEC encoding to take place. > > NEW: > In practice FEC Source Packets may be passed to the > transport layer as soon as available, without having to wait for FEC > encoding to take place. > > >> "Protection amount" is defined but not used in this document. The >> definition suggests a kind of cross-layer with the transport protocol >> or a kind of application flow control. Should be either discussed nay >> suppressed. > > VR: Removed. It was inherited from RFC6363 definitions, but there > also, it was not explicitly used in the text. > > >> EL > > Cheers, > >   Vincent -- Emmanuel LOCHIN Professeur ISAE ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 Web : http://personnel.isae.fr/emmanuel-lochin/ --------------7A7B898F4205233BDAC59B97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Vincent,

I'm fine with all your answers/corrections.

Cheers

EL

Le 02/05/2018 à 11:24, Vincent Roca a écrit :
Hello Emmanuel,

Thanks a lot for your review. I’ve just posted version -02 that takes your suggestions into account.
More precisely:

Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document quite clear, well-written and self-contained. I just have the following suggestions:


The authors argue that "FECFRAME provides FEC protection for arbitrary packet flows over unreliable transports such as UDP". RFC5348 proposes TFRC, an unreliable rate-based protocol which does not send data packets in a continuous manner at the same peak rate mimicking TCP average sending rate behavior or RFC4341 proposes DCCP CCID#2 congestion control which is an equivalent TCP window-based algorithm without retransmission.

I reckon it is a good idea to dissociate transport layers operations from sliding encoding operations. But keeping in mind these both protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the sentence "The data packets of continuous media flow(s) can be sent immediately, without delay." : "sent" is understood as "sent over the network" while this is not true depending on which unreliable transport protocol is used, so it should be "passed to the transport layer" as "sent over the network" only apply to UDP which does not schedule, pace or stop the sending. Actually some parts of this draft seem to consider that when source data or redundancy packets are built, they are simply sent over the network without delay. This is not always the case, so to be accurate I would suggest to correct by "passed to the transport layer" as correctly illustrated Fig. 1.

VR: You’re right. In addition to congestion control, traffic shaping may also delay packet transmissions (this is what
we considered in our work where we considered a CBR link, re-using 3GPP use-cases).

NEW: 
The data packets of continuous media flow(s) may be passed to the transport layer immediately, without delay.


Same applies for : "since repair symbols can be generated and sent on-the-fly, »

VR: Fixed.

NEW:
since repair symbols can be generated and passed to the
transport layer on-the-fly, […]


"In practice FEC Source Packets can be sent as soon as available, without having to wait for FEC encoding to take place". This sounds like a priority scheduling between source data packets against repair packets. May be "Encoding operations should not influence data packets processing: FEC Source Packets should never be delayed and should always remain available to be passed to the transport layer. »

VR: In fact there are several design options WRT to the question of "when to send source and repair packets ».
I don’t see good reasons to enter that type of detail in this document, so I’ve opted to a more neutral sentence
(using « may ») than what was there and what you propose (where « should » is too strong).

OLD:
In practice FEC Source Packets can be sent as soon as
available, without having to wait for FEC encoding to take place.

NEW:
In practice FEC Source Packets may be passed to the
transport layer as soon as available, without having to wait for FEC
encoding to take place.


"Protection amount" is defined but not used in this document. The definition suggests a kind of cross-layer with the transport protocol or a kind of application flow control. Should be either discussed nay suppressed.

VR: Removed. It was inherited from RFC6363 definitions, but there also, it was not explicitly used in the text.


EL

Cheers,

  Vincent


-- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/
--------------7A7B898F4205233BDAC59B97-- From nobody Fri May 4 07:30:43 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53719120454 for ; Fri, 4 May 2018 07:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=unavailable autolearn_force=no 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 cVG34ir14WVY for ; Fri, 4 May 2018 07:30:32 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 82604126BFD for ; Fri, 4 May 2018 07:30:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,362,1520895600"; d="scan'208,217";a="325793993" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.125]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2018 16:30:27 +0200 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A060D945-C6D1-4971-A578-4472E17B3051" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 4 May 2018 16:30:27 +0200 In-Reply-To: Cc: Vincent Roca , Wesley Eddy , "tsvwg@ietf.org" , nwcrg@irtf.org To: Gorry References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] WGLC on FECFRAME RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 14:30:37 -0000 --Apple-Mail=_A060D945-C6D1-4971-A578-4472E17B3051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Gorry, > I have the read draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and = have the following comments (as an individual). > These comments are all on the text and the standards requirements = being stated, they do not request changes to the method. > Gorry >=20 Thanks a lot for this very detailed review. It=E2=80=99s sometimes = challenging and really helpful. Here are my answers. Basically I agree with everything and updated the = I-D accordingly. I'll send the updated version of the I-D next week since we have spotted = a few more things that need to be fixed. More to come soon... Cheers, Vincent and Belkacem > --- > / They are meant to > protect arbitrary media streams along the lines defined by FECFRAME > extended to sliding window FEC codes./ > - I think the word /meant/ reads a little weird. Rather as if they = maybe do not do this. I suggest something like /They can provide = protection to/ may be better? VR: Fixed.=20 NEW:=20 They can protect arbitrary media streams... > --- > Just to be sure, I would add /packet/ or something to /erasure = recovery capabilities/ to be clear that this is not a bit-level FEC. = Perhaps the first use of /FEC/ could also be better as /Application-Lyer = FEC/ for the same purpose? VR: Very good point. We now mention "packet erasure recovery = capabilities =C2=BB in the abstract to avoid mis-understanding. We also expend FEC acronym in the abstract (it was only the case in the = title and Introduction). > --- > /in case of reliable file transfers/ > could be clearer as: > /when used for reliable file transfers/ VR: Done. > --- > /Defining this block size requires to find an/ > could be easier as: > /To define the block size, it is required to find an/ VR: Done. > --- > In 1.2 it states: > /This choice will impact all receivers./ > - Maybe I misunderstand, but does it impact a receiver that sees no = loss, because that could (in theory) act on the data as it arrives? VR: A perfect receiver will receive source data first and should not be = impacted in any way. But that=E2=80=99s an exception. All the other = receivers, even those who experience a tiny (but not zero) loss rate, need to wait = the same time on average: the time needed to receive repair packets for that block, which directly depends on the block size chosen for the = worst receiver. I=E2=80=99ve clarified the sentence. OLD: This choice will impact all receivers. NEW: This choice then impacts the FEC-related latency of all receivers, even those experiencing a good communication quality, since no FEC encoding can happen untill all the source data of the block is available at the sender, which directly depends on the block size. > --- > /are extremely efficient/ > - This seems like a value judgment. I'd be content with saying = /efficient/, but to say more I feel really needs a strong evidence that = has consensus. RFCs must not be used to market techniques. VR: Sure, you=E2=80=99re right. I propose the following sentence:=20 OLD: These FEC Schemes are extremely efficient for instance with = media that feature real-time constraints sent within a multicast/broadcast = session. NEW: These FEC Schemes, and more generally sliding window FEC codes, = are recommended for instance with media that feature real-time constraints sent = within a multicast/broadcast session [Roca17]. > ---- > /latency close to zero/ > - same comment, but perhaps this could be stated as /of the order of = the time to transmit a packet/ our similar? VR: Similarly I have changed for something more objective: OLD: However the receivers experiencing a good to medium = communication quality will observe a FEC-related latency close to zero [Roca17] since... NEW: However the receivers experiencing a good to medium = communication quality will observe a reduced FEC-related latency compared to block codes [Roca17] = since... > --- > /waiting the end of the block for the first repair packet to arrive./ > - perhaps clearer as: > /waiting for the first repair packet to arrive at the end of the = block./ VR: Done. > --- > /sliding window codes achieve more easily a target/ > - perhaps clearer as: > /sliding window codes can more achieve more efficiently achieve a = target/ VR: Done. NEW:=20 =E2=80=A6 sliding window codes can more efficiently achieve a = target transmission quality... > --- > /The Sliding Window RLC FEC Scheme is designed so as to reduce the = transmission overhead/ > - perhaps clearer as: > /The Sliding Window RLC FEC Scheme is designed to reduce transmission = overhead/ > -> however I note the next phrases talk about /minimize packet = overhead/, which could be seen as header bytes, is the distinction = intended, then please explain - if not please use the same term. VR: Yes, the term =C2=AB overhead =C2=BB is misleading here.=20 NEW: The Sliding Window RLC FEC Scheme is designed to limit the = packet header overhead. > ---- > /receiver to easily reconstruct/ > - remove /easily/, or say they are /sufficient to allow a receiver to = reconstruct/ or whatever, but avoid the value statement. VR: Done. > --- > This strikes me as a little odd: > /In all situations, we MUST have:/ > - If this is an actual RFC2119 requirement, then you need to state it = terms of what the message contains. Although here I am unsure this is a = protocol requirement, and if that is the case, it could be better to = state the /method needs to ensure:/? VR: Since RFC2119 recommends to use these terms sparingly, I=E2=80=99ve = changed for: OLD: In all situations, we MUST have: ew_size <=3D ew_max_size NEW: At session start, the encoding window will probably be small and = then progressively increase until it reaches its maximum value.=20 At any time:=20 ew_size <=3D ew_max_size > --- > This seems an off phrase in a specification: > / In practice they > will usually be fixed, especially with multicast/broadcast > transmissions. / > - could it instead be true to say something like /An implementation at = a sender and receiver can fix these values/... or something like. VR: I have clarified this part. NEW: An implementation at a sender can fix the E parameter and communicate it as part of the FEC Scheme-Specific Information (Section 4.1.1.2). There is no need to communicate the cr parameter per see (it's not required to process a repair packet at a receiver). This cr parameter can be fixed, however, in specific use-cases and in particular with unicast transmissions in presence of a feedback mechanism that estimates the communication quality (out-of-scope of FECFRAME), the code rate may be adjusted dynamically. > --- > /Let us assume that the/ and /Let us also assume/ > - seems rather like a paper, than a specification. Could this be = reworded as /In the case when the code rate is .../etc.? VR: Reworded. > --- > /It means that the source flow bitrate needs to be/ > May be easier as: > /This requires the source flow bitrate to be/ VR: Reworded. > --- > Similarly: > /It means that the transmission bitrate/ as /This requires the = transmission bitrate/ > -> but I have a question. of whether the /flow bitrate/ or /the = transmission bitrate/ are actually different, and if not=3D, then why = use two terms? Do we need either term as a /rate/ since this appears to = be about volume of data and not rate? VR: We are dealing here with bitrates in bits/s, not volume. We use = source (resp. repair) flow bitrates and transmission bitrate to denote the bitrate at the FECFRAME sender output. There was a additional term, =C2=AB input bitrate =C2=BB, that I have = replaced with source flow bitrate. > --- > /Finding the optimal value/ > - I am unsure how you would define /optimal/ here, is it possible to = say suitable/acceptable tradeoff or something like that without implying = a need for optimal? > /and should be determined after simulations or field trials. This is = of course out of scope of this document. > / > - and finished like it is a report, rather than a specification. Is it = therefore possible to simply say something like /An appropriate tradeoff = needs to be determined depending on the use case=E2=80=A6./ VR: Removed =C2=AB optimal =C2=BB as suggested, and tried to have it = less like a report. > --- > In section 3.2 > /An ADU, coming from the application/ > - is this at the sender? - just to be sure? VR: Yes, added =C2=AB At a sender =C2=BB. > --- > / Indeed, a lost ADU recovered at a receiver must > contain enough information to be assigned to the right application > flow (UDP port numbers and IP addresses cannot be used to that > purpose as they are not protected by FEC encoding). > / > - I could not parse this. Are the UDP port numbers and IP addresses = not protected by the link integrity check and IP/transport checksum? > - If they were corrupted they would cause the packet to be delivered = to another endpoint??? what is this about? VR: I admit this is a complex paragraph (the technic is from FECFRAME, = it=E2=80=99s not something added here for the pleasure). It=E2=80=99s not a matter of corruption. I=E2=80=99ve tried to improve = the explanation. Here it is: NEW: At a sender, an ADU coming from the application cannot directly be mapped to source symbols. When multiple source flows (e.g., media streams) are mapped onto the same FECFRAME instance, each flow is assigned its own Flow ID value (see below). At a sender, this identifier is prepended to each ADU before FEC encoding. This way, FEC decoding at a receiver also recovers this Flow ID and a recovered ADU can be assigned to the right source flow (note that UDP port numbers and IP addresses cannot be used to that purpose as they are not recovered during FEC decoding). > --- > There seems to be no requirements language at all in section 3.1. Is = this intended? VR: I guess you mean 3.2. No, it=E2=80=99s not intentional. I=E2=80=99ve = added a MUST:=20 NEW: For each incoming ADU, an ADUI MUST created as follows. > --- > Section 3.2 speaks of /UDP/ datagrams. I am not sure this is correct, = surely this applied to any type of datagram - DCCP, UDP, or anything = else that could in the future carry FECFRAME. VR: Right! Fixed. > --- > / Yet, any other > implementation of the PRNG algorithm that matches the above > validation criteria, like the ones detailed in [PM88], is > appropriate. > / > - is that actually saying an implementation MAY use any PRNG algorithm = that matches =E2=80=A6/ VR: Any implementation of the multiplicative congruential algorithm with = the constants defined, that additionally matches the validation criteria could be used. Look at http://www.firstpr.com.au/dsp/rand31/ = to get an idea of how prolific = the topic is. It=E2=80=99s impressive. That being said, I=E2=80=99ve removed this sentence to avoid confusion = since I already explain that the PM88 algorithm MUST be used. No need to say more. > --- > / The FEC Framework Configuration Information (or FFCI) includes > information that MUST be communicated between the sender and > receiver(s)./ > - This confuses me about what are the specific requirements, can you = please ensure that all the fields in this subsection carry an = appropriate RFC2119 keyword (in upper case), to say which are OPTIONAL, = REQUIRED, etc and what they MUST/MAY etc specify. VR: You=E2=80=99re right, the current sentence can be confusing. We follow here FECFRAME requirements (RFC 6363 section 5.6) that = explains what MUST be detailed in a FEC Scheme specification in terms of signalling (which we = actually provide). I=E2=80=99ve changed text to avoid this confusion (no MUST any more). NEW: 4.1.1. FEC Framework Configuration Information Following the guidelines of [RFC6363], section 5.6, this section provides the FEC Framework Configuration Information (or FFCI). This FCCI needs to be shared (e.g., using SDP) between the FECFRAME sender and receiver instances in order to synchronize them. It includes a FEC Encoding ID, mandatory for any FEC Scheme specification, plus scheme-specific elements. 4.1.1.1. FEC Encoding ID [=E2=80=A6] And the same applies to section 5.1.1. (but without any explanatory = text). > --- > /A FEC Repair Packet can contain one or more repair symbols./ > - is that a statement, or a permission? e.g., > /A FEC Repair Packet MAY contain one or more repair symbols./ VR: Good catch. That=E2=80=99s a technical possibility. Changed for MAY = as suggested. > --- > /integer carried the Density Threshold/ > - is this /carries/ VR: Fixed. > --- > Is this discussion OK, or do you think we need to define the protocol = actions using RFC2119 keywords: > / The only constraint is to increment by > 1 the repair key for each of them, keeping the same ew_size source > symbols, since only the first repair key will be carried in the > Repair FEC Payload ID. The FEC Repair Packet can then be sent./ VR: You=E2=80=99re right. NEW: In that case the repair key for each of them MUST be incremented by 1, keeping=E2=80=A6 > - /sent/ probably should be /passed to the transport layer for = transmission./ VR: Yes, as in the FECFRAME I-D. Done. There=E2=80=99s also another = instance where =C2=AB sent =C2=BB has been replaced. > --- > / containing an ADU, can be passed to the application either > immediately or after some time to guaranty an ordered delivery to = the > application. / > - This reads like it could be /MAY be passed/ VR: Done. I=E2=80=99ll try to be more careful with RFC2119 keywords in = the future. =20 > --- > / received after this delay should not be passed to > the application./ > - I am unsure whether this needs to be read as /ought/ or /SHOULD/ = could you use one of these instead of /should/? VR: it=E2=80=99s a matter of deciding what component is responsible of = detecting late ADUs.=20 All things considered, I=E2=80=99d prefer to relax the requirement to do = that within FECFRAME. It=E2=80=99s an implementation decision, we just explain (section 3.1. Parameters Derivation) how to reduce the = risk to lead to late decodings. NEW: With real-time flows, a lost ADU that is decoded after the maximum latency or an ADU received after this delay has no value to the application. This raises the question of deciding whether or not an ADU is late. This decision MAY be taken within the FECFRAME receiver (e.g., using the decoding window, see Section 3.1) or within the application (e.g., using RTP timestamps within the ADU). Deciding which option to follow and whether or not to pass all ADUs, including those assumed late, to the application are operational decisions that depend on the application and are therefore out of scope of this document. > --- > In addition some standard transport comments that ought to be fine = tuned: > / Repair packets (symbols) are generated and sent on-the-fly/ > - seems to perhaps be possibly to read as avoids CC, which it should = not. Please be careful to indicate that packets are /passed to the = transport layer for transmission/, if you think that these may be sent = with higher priority than other messages, then please explicitly say = this. VR: Changed. NEW: Repair packets (symbols) are generated on-the-fly, computing a random = linear combination of the source symbols present in the current encoding = window, and passed to the transport layer. > --- > /where packets are sent with a fixed period/ > - I think a word of caution here is needed with respect to CC. So this = probably needs to be carefully worded, or at least say /are passed to = the transport layer each fixed period/. VR: the CBR assumption was needed to derive parameters, but I agree it = gives the impression CC is bypassed (in fact in our 3GPP use-case there=E2=80=99s = no CC). At the light of our discussions (and also with Belkacem) I=E2=80=99m not = satisfied with=20 section 3.1. Parameters Derivation and will come back with a brand new version. > --- > /The FEC Repair Packet can then be sent./ > .... maybe: > /passed to the transport layer for transmission/ VR: Done. --Apple-Mail=_A060D945-C6D1-4971-A578-4472E17B3051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Gorry,
I have the read = draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and have the following = comments (as an individual).
These = comments are all on the text and the standards requirements being = stated, they do not request changes to the method.
Gorry


Thanks a lot for this very detailed review. = It=E2=80=99s sometimes challenging and really helpful.
Here are my answers. Basically I agree with everything and = updated the I-D accordingly.

I'll send the updated version of the = I-D next week since we have spotted a few more things that = need
to be fixed. More to come = soon...


Cheers,

  Vincent and Belkacem

---
/  They are meant to
  protect = arbitrary media streams along the lines defined by FECFRAME
=   extended to sliding window FEC codes./
- I = think the word /meant/ reads a little weird. Rather as if they maybe do = not do this. I suggest something like /They can provide protection to/ = may be better?

VR: Fixed. 

NEW: 
They can protect arbitrary media = streams...


---
Just to be sure, I would = add /packet/ or something to /erasure recovery capabilities/ to be clear = that this is not a bit-level FEC. Perhaps the first use of /FEC/ could = also be better as /Application-Lyer FEC/ for the same purpose?

VR: = Very good point. We now mention "packet erasure recovery = capabilities =C2=BB in the abstract to avoid = mis-understanding.
We also expend FEC acronym in the abstract = (it was only the case in the title and Introduction).


---
/in case of reliable file = transfers/
could be clearer as:
/when used = for reliable file transfers/

VR: = Done.


---
/Defining this block size requires to find an/
could be easier as:
/To define the block size, = it is required to find an/
VR: Done.

---
In 1.2 it states:
/This choice will impact all = receivers./
- Maybe I misunderstand, but does it impact a = receiver that sees no loss, because that could (in theory) act on the = data as it arrives?

VR: A perfect receiver will receive source data = first and should not be impacted in any way. But that=E2=80=99s an = exception. All the other receivers,
even those who experience = a tiny (but not zero) loss rate, need to wait the same time on average: = the time needed to receive repair packets
for that block, = which directly depends on the block size chosen for the worst receiver. = I=E2=80=99ve clarified the sentence.

OLD:
This choice will impact all = receivers.

NEW:
This choice then impacts = the
FEC-related = latency of all receivers, even those experiencing a = good
communication = quality, since no FEC encoding can happen untill = all
the source = data of the block is available at the sender, = which
directly = depends on the block size.

---
/are extremely = efficient/
- This seems like a value judgment. I'd be = content with saying /efficient/, but to say more I feel really needs a = strong evidence that has consensus. RFCs must not be used to market = techniques.

VR: Sure, you=E2=80=99re right. I propose the = following sentence: 

OLD:
These FEC Schemes are extremely = efficient for instance with media that
feature = real-time constraints sent within a multicast/broadcast = session.

NEW:
These FEC Schemes, and more generally sliding window FEC codes, are = recommended
for instance with media that = feature real-time constraints sent within a multicast/broadcast
session = [Roca17].


----
/latency close to zero/
- same comment, but = perhaps this could be stated as /of the order of the time to transmit a = packet/ our similar?

VR: Similarly I have changed for something more = objective:

OLD:
However = the receivers experiencing a good to medium communication quality will = observe
a FEC-related latency close to = zero [Roca17] since...

NEW:
However the receivers = experiencing a good to medium communication quality will observe
a reduced = FEC-related latency compared to block codes [Roca17] since...


---
/waiting the end of the = block for the first repair packet to arrive./
- perhaps = clearer as:
/waiting for the first repair packet to arrive = at the end of the block./

VR: Done.


---
/sliding window codes achieve more easily a = target/
- perhaps clearer as:
/sliding = window codes can more achieve more efficiently achieve a target/

VR: = Done.

NEW: 
= =E2=80=A6 sliding window codes can more efficiently achieve = a target transmission quality...


---
/The Sliding Window RLC FEC Scheme is = designed so as to reduce the transmission overhead/
- = perhaps clearer as:
/The Sliding Window RLC FEC Scheme is = designed to reduce transmission overhead/
-> however I = note the next phrases talk about /minimize packet overhead/, which could = be seen as header bytes, is the distinction intended, then please = explain - if not please use the same term.

VR: = Yes, the term =C2=AB overhead =C2=BB is misleading = here. 

NEW:
The = Sliding Window RLC FEC Scheme is designed to limit the packet header = overhead.


----
/receiver to easily reconstruct/
- remove = /easily/, or say they are /sufficient to allow a receiver to = reconstruct/ or whatever, but avoid the value statement.

VR: = Done.


---
This strikes me as a little odd:
/In all = situations, we MUST have:/
- If this is an actual RFC2119 = requirement, then you need to state it terms of what the message = contains. Although here I am unsure this is a protocol requirement, and = if that is the case, it could be better to state the /method needs to = ensure:/?

VR: Since RFC2119 recommends to use these terms = sparingly, I=E2=80=99ve changed for:

OLD:
In all situations, we MUST = have:
        =  ew_size <=3D ew_max_size

NEW:
At session start, the encoding = window will probably be small and then progressively increase until it reaches its maximum value. 
At any = time: 
ew_size <=3D = ew_max_size


---
This seems an off phrase in a specification:
/ =     In practice they
=      will usually be fixed, especially with = multicast/broadcast
=      transmissions. /
- could it = instead be true to say something like /An implementation at a sender and = receiver can fix these values/... or something like.

VR: I = have clarified this part.

NEW:
      An = implementation
      at a sender can fix = the E parameter and communicate it as part of
  =     the FEC Scheme-Specific Information (Section 4.1.1.2). =  There is
      no need to communicate = the cr parameter per see (it's not required
    =   to process a repair packet at a receiver).  This cr = parameter can
      be fixed, however, in = specific use-cases and in particular with
    =   unicast transmissions in presence of a feedback mechanism that
      estimates the communication quality = (out-of-scope of FECFRAME),
      the code = rate may be adjusted dynamically.


---
/Let us assume that the/ and /Let us also = assume/
- seems rather like a paper, than a specification. = Could this be reworded as /In the case when the code rate is = .../etc.?

VR: Reworded.


---
/It means that the source flow bitrate = needs to be/
May be easier as:
/This = requires the source flow bitrate to be/

VR: Reworded.


---
Similarly: /It means that the transmission bitrate/ as /This requires = the transmission bitrate/
-> but I have a question. of = whether the /flow bitrate/ or /the transmission bitrate/ are actually = different, and if not=3D, then why use two terms? Do we need either term = as a /rate/ since this appears to be about volume of data and not = rate?

VR: We are dealing here with bitrates in bits/s, = not volume. We use source (resp. repair) flow bitrates and transmission = bitrate to denote
the bitrate at the FECFRAME sender = output.
There was a additional term, =C2=AB input = bitrate =C2=BB, that I have replaced with source flow = bitrate.


---
/Finding the optimal value/
- I am unsure how = you would define /optimal/ here, is it possible to say = suitable/acceptable tradeoff or something like that without implying a = need for optimal?
/and should be determined after = simulations or field trials.  This is of course out of scope of = this document.
/
- and finished like it is a = report, rather than a specification. Is it therefore possible to simply = say something like /An appropriate tradeoff needs to be determined = depending on the use case=E2=80=A6./

VR: = Removed =C2=AB optimal =C2=BB as suggested, and tried to have = it less like a report.


---
In section 3.2
/An ADU, = coming from the application/
- is this at the sender? - = just to be sure?

VR: Yes, added =C2=AB At a = sender =C2=BB.


---
/ Indeed, a lost ADU recovered at a = receiver must
  contain enough information to = be assigned to the right application
  flow = (UDP port numbers and IP addresses cannot be used to that
=   purpose as they are not protected by FEC encoding).
/
- I could not parse this. Are the UDP port = numbers and IP addresses not protected by the link integrity check and = IP/transport checksum?
- If they were corrupted they would = cause the packet to be delivered to another endpoint??? what is this = about?

VR: I admit this is a complex paragraph (the = technic is from FECFRAME, it=E2=80=99s not something added here for the = pleasure).
It=E2=80=99s not a matter of corruption. I=E2=80=99ve= tried to improve the explanation. Here it is:

NEW:
   At a sender, = an ADU coming from the application cannot directly be
  =  mapped to source symbols.  When multiple source flows (e.g., = media
   streams) are mapped onto the same FECFRAME = instance, each flow is
   assigned its own Flow ID = value (see below).  At a sender, this
  =  identifier is prepended to each ADU before FEC encoding. =  This way,
   FEC decoding at a receiver also = recovers this Flow ID and a recovered
   ADU can be = assigned to the right source flow (note that UDP port
  =  numbers and IP addresses cannot be used to that purpose as they = are
   not recovered during FEC = decoding).


---
There seems to be no requirements language = at all in section 3.1. Is this = intended?

VR: I = guess you mean 3.2. No, it=E2=80=99s not intentional. I=E2=80=99ve added = a MUST: 

NEW:
For each = incoming ADU, an ADUI MUST created as follows.


---
Section 3.2 speaks of /UDP/ = datagrams. I am not sure this is correct, surely this applied to any = type of datagram - DCCP, UDP, or anything else that could in the future = carry FECFRAME.

VR: Right! Fixed.

---
/ Yet, any other
=   implementation of the PRNG algorithm that matches the = above
  validation criteria, like the ones = detailed in [PM88], is
  appropriate.
/
- is that actually saying an implementation = MAY use any PRNG algorithm that matches =E2=80=A6/

VR: = Any implementation of the multiplicative congruential algorithm = with the constants defined, that
additionally matches the = validation criteria could be used.
Look at http://www.firstpr.com.au/dsp/rand31/ to get an idea = of how prolific the topic is. It=E2=80=99s impressive.

That being said, I=E2=80=99ve removed this = sentence to avoid confusion since I already explain that the = PM88
algorithm MUST be used. No need to say = more.


---
/  The FEC Framework Configuration Information (or FFCI) = includes
  information that MUST be = communicated between the sender and
=   receiver(s)./
- This confuses me about what = are the specific requirements, can you please ensure that all the fields = in this subsection carry an appropriate RFC2119 keyword (in upper case), = to say which are OPTIONAL, REQUIRED, etc and what they MUST/MAY etc = specify.

VR: You=E2=80=99re right, the current sentence can = be confusing.
We follow here FECFRAME requirements (RFC 6363 = section 5.6) that explains what MUST be
detailed in a FEC = Scheme specification in terms of signalling (which we actually = provide).
I=E2=80=99ve changed text to avoid this confusion = (no MUST any more).

NEW:
4.1.1.  FEC Framework Configuration = Information

   Following the = guidelines of [RFC6363], section 5.6, this section
  =  provides the FEC Framework Configuration Information (or FFCI). =  This
   FCCI needs to be shared (e.g., = using SDP) between the FECFRAME sender
   and = receiver instances in order to synchronize them.  It includes a
   FEC Encoding ID, mandatory for any FEC Scheme = specification, plus
   scheme-specific = elements.

4.1.1.1.  FEC Encoding ID
[=E2=80=A6]

And the same = applies to section 5.1.1. (but without any explanatory = text).


---
/A FEC Repair Packet can contain one or more repair = symbols./
- is that a statement, or a permission? e.g.,
/A FEC Repair Packet MAY contain one or more repair = symbols./

VR: Good catch. That=E2=80=99s a technical = possibility. Changed for MAY as suggested.


---
/integer carried the = Density Threshold/
- is this /carries/

VR: = Fixed.

---
Is this discussion OK, or = do you think we need to define the protocol actions using RFC2119 = keywords:
/ The only constraint is to increment by
  1 the repair key for each of them, keeping the = same ew_size source
  symbols, since only the = first repair key will be carried in the
=   Repair FEC Payload ID.  The FEC Repair Packet can then = be sent./

VR: You=E2=80=99re right.

NEW:
   In that case the = repair key for each of
   them MUST be incremented = by 1, keeping=E2=80=A6


- /sent/ probably should be = /passed to the transport layer for transmission./

VR: = Yes, as in the FECFRAME I-D. Done. There=E2=80=99s also another instance = where =C2=AB sent =C2=BB has been replaced.


---
/ containing an ADU, can be = passed to the application either
  immediately = or after some time to guaranty an ordered delivery to the
=   application. /
- This reads like it could be = /MAY be passed/

VR: Done. I=E2=80=99ll try to be more careful with = RFC2119 keywords in the future.
 

---
/  received after this delay should = not be passed to
  the application./
- I am unsure whether this needs to be read as /ought/ or = /SHOULD/ could you use one of these instead of /should/?

VR: = it=E2=80=99s a matter of deciding what component is responsible of = detecting late ADUs. 
All things considered, I=E2=80=99d = prefer to relax the requirement to do that within FECFRAME. It=E2=80=99s = an implementation decision,
we just explain (section 3.1. =  Parameters Derivation) how to reduce the risk to lead to late = decodings.

NEW:
  =  With real-time flows, a lost ADU that is decoded after the = maximum
   latency or an ADU received after this = delay has no value to the
   application.  This = raises the question of deciding whether or not an
  =  ADU is late.  This decision MAY be taken within the FECFRAME = receiver
   (e.g., using the decoding window, see = Section 3.1) or within the
   application (e.g., = using RTP timestamps within the ADU).  Deciding
  =  which option to follow and whether or not to pass all ADUs, = including
   those assumed late, to the application = are operational decisions that
   depend on the = application and are therefore out of scope of this
  =  document.

---
In addition = some standard transport comments that ought to be fine tuned:
/ Repair packets (symbols) are generated and sent = on-the-fly/
- seems to perhaps be possibly to read as = avoids CC, which it should not. Please be careful to indicate that = packets are /passed to the transport layer for transmission/, if you = think that these may be sent with higher priority than other messages, = then please explicitly say this.

VR: = Changed.

NEW:
   Repair = packets (symbols) are generated on-the-fly, computing a random = linear
   combination of the source symbols present = in the current encoding window, and
   passed to the = transport layer.


---
/where packets are sent with a fixed = period/
- I think a word of caution here is needed with = respect to CC. So this probably needs to be carefully worded, or at = least say /are passed to the transport layer each fixed period/.

VR: = the CBR assumption was needed to derive parameters, but I agree it gives = the
impression CC is bypassed (in fact in our 3GPP use-case = there=E2=80=99s no CC).
At the light of our discussions (and = also with Belkacem) I=E2=80=99m not satisfied with 
= section 3.1.  Parameters Derivation
and will = come back with a brand new version.


---
/The FEC = Repair Packet can then be sent./
.... maybe:
= /passed to the transport layer for transmission/

VR: = Done.


= --Apple-Mail=_A060D945-C6D1-4971-A578-4472E17B3051-- From nobody Fri May 4 08:05:16 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7327612D878 for ; Fri, 4 May 2018 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no 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 FeurjXbcveXe for ; Fri, 4 May 2018 08:05:07 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id A0EBD12D7F1 for ; Fri, 4 May 2018 08:05:07 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id C59D11B00151; Fri, 4 May 2018 16:05:00 +0100 (BST) Message-ID: <5AEC769C.50806@erg.abdn.ac.uk> Date: Fri, 04 May 2018 16:05:00 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Vincent Roca CC: Wesley Eddy , "tsvwg@ietf.org" , nwcrg@irtf.org References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] WGLC on FECFRAME RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 15:05:13 -0000 Thanks these corrections seem like what I expected, thanks for doing them. Maybe you chekc that youcheck that change /untill/until/. Best wishes, Gorry On 04/05/2018, 15:30, Vincent Roca wrote: > Hello Gorry, > >> I have the read draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and >> have the following comments (as an individual). >> These comments are all on the text and the standards requirements >> being stated, they do not request changes to the method. >> Gorry >> > > Thanks a lot for this very detailed review. It’s sometimes challenging > and really helpful. > Here are my answers. Basically I agree with everything and updated the > I-D accordingly. > > I'll send the updated version of the I-D next week since we have > spotted a few more things that need > to be fixed. More to come soon... > > > Cheers, > > Vincent and Belkacem > > >> --- >> / They are meant to >> protect arbitrary media streams along the lines defined by FECFRAME >> extended to sliding window FEC codes./ >> - I think the word /meant/ reads a little weird. Rather as if they >> maybe do not do this. I suggest something like /They can provide >> protection to/ may be better? > > VR: Fixed. > > NEW: > > They can protect arbitrary media streams... > > > >> --- >> Just to be sure, I would add /packet/ or something to /erasure >> recovery capabilities/ to be clear that this is not a bit-level FEC. >> Perhaps the first use of /FEC/ could also be better as >> /Application-Lyer FEC/ for the same purpose? > > VR: Very good point. We now mention "packet erasure recovery > capabilities » in the abstract to avoid mis-understanding. > We also expend FEC acronym in the abstract (it was only the case in > the title and Introduction). > > >> --- >> /in case of reliable file transfers/ >> could be clearer as: >> /when used for reliable file transfers/ > > VR: Done. > > >> --- >> /Defining this block size requires to find an/ >> could be easier as: >> /To define the block size, it is required to find an/ > > VR: Done. > >> --- >> In 1.2 it states: >> /This choice will impact all receivers./ >> - Maybe I misunderstand, but does it impact a receiver that sees no >> loss, because that could (in theory) act on the data as it arrives? > > VR: A perfect receiver will receive source data first and should not > be impacted in any way. But that’s an exception. All the other receivers, > even those who experience a tiny (but not zero) loss rate, need to > wait the same time on average: the time needed to receive repair packets > for that block, which directly depends on the block size chosen for > the worst receiver. I’ve clarified the sentence. > > OLD: > > This choice will impact all receivers. > > > NEW: > > This choice then impacts the > FEC-related latency of all receivers, even those experiencing a good > communication quality, since no FEC encoding can happen untill all > the source data of the block is available at the sender, which > directly depends on the block size. > > >> --- >> /are extremely efficient/ >> - This seems like a value judgment. I'd be content with saying >> /efficient/, but to say more I feel really needs a strong evidence >> that has consensus. RFCs must not be used to market techniques. > > VR: Sure, you’re right. I propose the following sentence: > > OLD: > These FEC Schemes are extremely efficient for instance with media that > feature real-time constraints sent within a multicast/broadcast session. > > NEW: > These FEC Schemes, and more generally sliding window FEC codes, are > recommended > for instance with media that feature real-time constraints sent within > a multicast/broadcast > session [Roca17]. > > >> ---- >> /latency close to zero/ >> - same comment, but perhaps this could be stated as /of the order of >> the time to transmit a packet/ our similar? > > VR: Similarly I have changed for something more objective: > > OLD: > However the receivers experiencing a good to medium communication > quality will observe > a FEC-related latency close to zero [Roca17] since... > > NEW: > However the receivers experiencing a good to medium communication > quality will observe > a reduced FEC-related latency compared to block codes [Roca17] since... > > >> --- >> /waiting the end of the block for the first repair packet to arrive./ >> - perhaps clearer as: >> /waiting for the first repair packet to arrive at the end of the block./ > > VR: Done. > > >> --- >> /sliding window codes achieve more easily a target/ >> - perhaps clearer as: >> /sliding window codes can more achieve more efficiently achieve a target/ > > VR: Done. > > NEW: > … sliding window codes can more efficiently achieve a target > transmission quality... > > >> --- >> /The Sliding Window RLC FEC Scheme is designed so as to reduce the >> transmission overhead/ >> - perhaps clearer as: >> /The Sliding Window RLC FEC Scheme is designed to reduce transmission >> overhead/ >> -> however I note the next phrases talk about /minimize packet >> overhead/, which could be seen as header bytes, is the distinction >> intended, then please explain - if not please use the same term. > > VR: Yes, the term « overhead » is misleading here. > > NEW: > The Sliding Window RLC FEC Scheme is designed to limit the packet > header overhead. > > >> ---- >> /receiver to easily reconstruct/ >> - remove /easily/, or say they are /sufficient to allow a receiver to >> reconstruct/ or whatever, but avoid the value statement. > > VR: Done. > > >> --- >> This strikes me as a little odd: >> /In all situations, we MUST have:/ >> - If this is an actual RFC2119 requirement, then you need to state it >> terms of what the message contains. Although here I am unsure this is >> a protocol requirement, and if that is the case, it could be better >> to state the /method needs to ensure:/? > > VR: Since RFC2119 recommends to use these terms sparingly, I’ve > changed for: > > OLD: > In all situations, we MUST have: > ew_size <= ew_max_size > > NEW: > At session start, the encoding window will probably be small and then > progressively increase until it reaches its maximum value. > At any time: > ew_size <= ew_max_size > > >> --- >> This seems an off phrase in a specification: >> / In practice they >> will usually be fixed, especially with multicast/broadcast >> transmissions. / >> - could it instead be true to say something like /An implementation >> at a sender and receiver can fix these values/... or something like. > > VR: I have clarified this part. > > NEW: > An implementation > at a sender can fix the E parameter and communicate it as part of > the FEC Scheme-Specific Information (Section 4.1.1.2). There is > no need to communicate the cr parameter per see (it's not required > to process a repair packet at a receiver). This cr parameter can > be fixed, however, in specific use-cases and in particular with > unicast transmissions in presence of a feedback mechanism that > estimates the communication quality (out-of-scope of FECFRAME), > the code rate may be adjusted dynamically. > > >> --- >> /Let us assume that the/ and /Let us also assume/ >> - seems rather like a paper, than a specification. Could this be >> reworded as /In the case when the code rate is .../etc.? > > VR: Reworded. > > >> --- >> /It means that the source flow bitrate needs to be/ >> May be easier as: >> /This requires the source flow bitrate to be/ > > VR: Reworded. > > >> --- >> Similarly: >> /It means that the transmission bitrate/ as /This requires the >> transmission bitrate/ >> -> but I have a question. of whether the /flow bitrate/ or /the >> transmission bitrate/ are actually different, and if not=, then why >> use two terms? Do we need either term as a /rate/ since this appears >> to be about volume of data and not rate? > > VR: We are dealing here with bitrates in bits/s, not volume. We use > source (resp. repair) flow bitrates and transmission bitrate to denote > the bitrate at the FECFRAME sender output. > There was a additional term, « input bitrate », that I have replaced > with source flow bitrate. > > >> --- >> /Finding the optimal value/ >> - I am unsure how you would define /optimal/ here, is it possible to >> say suitable/acceptable tradeoff or something like that without >> implying a need for optimal? >> /and should be determined after simulations or field trials. This is >> of course out of scope of this document. >> / >> - and finished like it is a report, rather than a specification. Is >> it therefore possible to simply say something like /An appropriate >> tradeoff needs to be determined depending on the use case…./ > > VR: Removed « optimal » as suggested, and tried to have it less like a > report. > > >> --- >> In section 3.2 >> /An ADU, coming from the application/ >> - is this at the sender? - just to be sure? > > VR: Yes, added « At a sender ». > > >> --- >> / Indeed, a lost ADU recovered at a receiver must >> contain enough information to be assigned to the right application >> flow (UDP port numbers and IP addresses cannot be used to that >> purpose as they are not protected by FEC encoding). >> / >> - I could not parse this. Are the UDP port numbers and IP addresses >> not protected by the link integrity check and IP/transport checksum? >> - If they were corrupted they would cause the packet to be delivered >> to another endpoint??? what is this about? > > VR: I admit this is a complex paragraph (the technic is from FECFRAME, > it’s not something added here for the pleasure). > It’s not a matter of corruption. I’ve tried to improve the > explanation. Here it is: > > NEW: > At a sender, an ADU coming from the application cannot directly be > mapped to source symbols. When multiple source flows (e.g., media > streams) are mapped onto the same FECFRAME instance, each flow is > assigned its own Flow ID value (see below). At a sender, this > identifier is prepended to each ADU before FEC encoding. This way, > FEC decoding at a receiver also recovers this Flow ID and a recovered > ADU can be assigned to the right source flow (note that UDP port > numbers and IP addresses cannot be used to that purpose as they are > not recovered during FEC decoding). > > >> --- >> There seems to be no requirements language at all in section 3.1. Is >> this intended? > > VR: I guess you mean 3.2. No, it’s not intentional. I’ve added a MUST: > > NEW: > For each incoming ADU, an ADUI MUST created as follows. > > >> --- >> Section 3.2 speaks of /UDP/ datagrams. I am not sure this is correct, >> surely this applied to any type of datagram - DCCP, UDP, or anything >> else that could in the future carry FECFRAME. > > VR: Right! Fixed. > > >> --- >> / Yet, any other >> implementation of the PRNG algorithm that matches the above >> validation criteria, like the ones detailed in [PM88], is >> appropriate. >> / >> - is that actually saying an implementation MAY use any PRNG >> algorithm that matches …/ > > VR: Any implementation of the multiplicative congruential algorithm > with the constants defined, that > additionally matches the validation criteria could be used. > Look at http://www.firstpr.com.au/dsp/rand31/ to get an idea of how > prolific the topic is. It’s impressive. > > That being said, I’ve removed this sentence to avoid confusion since I > already explain that the PM88 > algorithm MUST be used. No need to say more. > > >> --- >> / The FEC Framework Configuration Information (or FFCI) includes >> information that MUST be communicated between the sender and >> receiver(s)./ >> - This confuses me about what are the specific requirements, can you >> please ensure that all the fields in this subsection carry an >> appropriate RFC2119 keyword (in upper case), to say which are >> OPTIONAL, REQUIRED, etc and what they MUST/MAY etc specify. > > VR: You’re right, the current sentence can be confusing. > We follow here FECFRAME requirements (RFC 6363 section 5.6) that > explains what MUST be > detailed in a FEC Scheme specification in terms of signalling (which > we actually provide). > I’ve changed text to avoid this confusion (no MUST any more). > > NEW: > > 4.1.1. FEC Framework Configuration Information > > Following the guidelines of [RFC6363], section 5.6, this section > provides the FEC Framework Configuration Information (or FFCI). This > FCCI needs to be shared (e.g., using SDP) between the FECFRAME sender > and receiver instances in order to synchronize them. It includes a > FEC Encoding ID, mandatory for any FEC Scheme specification, plus > scheme-specific elements. > > 4.1.1.1. FEC Encoding ID > […] > > And the same applies to section 5.1.1. (but without any explanatory text). > > >> --- >> /A FEC Repair Packet can contain one or more repair symbols./ >> - is that a statement, or a permission? e.g., >> /A FEC Repair Packet MAY contain one or more repair symbols./ > > VR: Good catch. That’s a technical possibility. Changed for MAY as > suggested. > > >> --- >> /integer carried the Density Threshold/ >> - is this /carries/ > > VR: Fixed. > >> --- >> Is this discussion OK, or do you think we need to define the protocol >> actions using RFC2119 keywords: >> / The only constraint is to increment by >> 1 the repair key for each of them, keeping the same ew_size source >> symbols, since only the first repair key will be carried in the >> Repair FEC Payload ID. The FEC Repair Packet can then be sent./ > > VR: You’re right. > > NEW: > In that case the repair key for each of > them MUST be incremented by 1, keeping… > > >> - /sent/ probably should be /passed to the transport layer for >> transmission./ > > VR: Yes, as in the FECFRAME I-D. Done. There’s also another instance > where « sent » has been replaced. > > >> --- >> / containing an ADU, can be passed to the application either >> immediately or after some time to guaranty an ordered delivery to the >> application. / >> - This reads like it could be /MAY be passed/ > > VR: Done. I’ll try to be more careful with RFC2119 keywords in the future. > >> --- >> / received after this delay should not be passed to >> the application./ >> - I am unsure whether this needs to be read as /ought/ or /SHOULD/ >> could you use one of these instead of /should/? > > VR: it’s a matter of deciding what component is responsible of > detecting late ADUs. > All things considered, I’d prefer to relax the requirement to do that > within FECFRAME. It’s an implementation decision, > we just explain (section 3.1. Parameters Derivation) how to reduce > the risk to lead to late decodings. > > NEW: > With real-time flows, a lost ADU that is decoded after the maximum > latency or an ADU received after this delay has no value to the > application. This raises the question of deciding whether or not an > ADU is late. This decision MAY be taken within the FECFRAME receiver > (e.g., using the decoding window, see Section 3.1) or within the > application (e.g., using RTP timestamps within the ADU). Deciding > which option to follow and whether or not to pass all ADUs, including > those assumed late, to the application are operational decisions that > depend on the application and are therefore out of scope of this > document. > >> --- >> In addition some standard transport comments that ought to be fine tuned: >> / Repair packets (symbols) are generated and sent on-the-fly/ >> - seems to perhaps be possibly to read as avoids CC, which it should >> not. Please be careful to indicate that packets are /passed to the >> transport layer for transmission/, if you think that these may be >> sent with higher priority than other messages, then please explicitly >> say this. > > VR: Changed. > > NEW: > Repair packets (symbols) are generated on-the-fly, computing a > random linear > combination of the source symbols present in the current encoding > window, and > passed to the transport layer. > > >> --- >> /where packets are sent with a fixed period/ >> - I think a word of caution here is needed with respect to CC. So >> this probably needs to be carefully worded, or at least say /are >> passed to the transport layer each fixed period/. > > VR: the CBR assumption was needed to derive parameters, but I agree it > gives the > impression CC is bypassed (in fact in our 3GPP use-case there’s no CC). > At the light of our discussions (and also with Belkacem) I’m not > satisfied with > section 3.1. Parameters Derivation > and will come back with a brand new version. > > >> --- >> /The FEC Repair Packet can then be sent./ >> .... maybe: >> /passed to the transport layer for transmission/ > > VR: Done. > > From nobody Sun May 6 10:24:21 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BD4127909 for ; Sun, 6 May 2018 10:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 MOqCjdY5Xdhy for ; Sun, 6 May 2018 10:24:18 -0700 (PDT) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70125127876 for ; Sun, 6 May 2018 10:24:18 -0700 (PDT) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 62B3CD5859 for ; Sun, 6 May 2018 13:24:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=fvK atnriahaf6xOOTkXXE6NIUnE=; b=ihHyWJ4AUQGF9SZUZytkfGghXTCuYgVqFyl urT1ynqgs8gKXMu3m9eCF0ppwgpCXj1MohW5p0B2ORuE4ISoDclOV64CJrAOxW0P Li/oiOjvDjaakWLSeTkKjUStvgXrXF1Y96oaY0pEzN5lm4KuEKjhXl7j5y1oPadv Q4bqT+OI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= u4H5/97YvgMyMJgExoaddu835vpbZb/DePQWwLradYpmdIE+cdW85vj1Q5++p1Q8 K736cdUhgE0Uqh1G/h1wXGr76P9gkdwgaXa1dtzg4oITGxwnQZ70ofJ+1q+MCfmg xopRXJDsCRA+T2f8HT60O6lVa/y6vSoJFJEnnlGXxSM= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5A5E7D5858 for ; Sun, 6 May 2018 13:24:16 -0400 (EDT) Received: from mail-ot0-f182.google.com (unknown [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D2FF3D5857 for ; Sun, 6 May 2018 13:24:15 -0400 (EDT) Received: by mail-ot0-f182.google.com with SMTP id g7-v6so29573872otj.11 for ; Sun, 06 May 2018 10:24:15 -0700 (PDT) X-Gm-Message-State: ALQs6tCZgZ4G8WrQV4MWtapo1+9zTgXQ0MpyXvzHOIkLKparmSZae9Ub OuQ3cMH3QPlVrATpEUfx8lHaEjnkXkFLa+wJAkA= X-Google-Smtp-Source: AB8JxZqcG44OnHCDj2EHxvUMNEJeO1MMl5/u2lSuXCnd6yFN0XYUQDIM0WGr5MEXI77SifQ1UyRZZL1tN2k09jpAaNM= X-Received: by 2002:a9d:66f:: with SMTP id 102-v6mr12715879otn.106.1525627455224; Sun, 06 May 2018 10:24:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.136.198 with HTTP; Sun, 6 May 2018 10:23:54 -0700 (PDT) From: "C. M. Heard" Date: Sun, 6 May 2018 10:23:54 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="000000000000873f4f056b8cd2b9" X-Pobox-Relay-ID: 4D2E731A-5152-11E8-B2F3-67830C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 17:24:20 -0000 --000000000000873f4f056b8cd2b9 Content-Type: text/plain; charset="UTF-8" Greetings, Some issues came to my attention during a recent off-list discussion with someone from the DNS community. Section 5.4, Alternate Checksum (ACS): since the option area is not included in the ACS, the following text seems out of place: When ACS is computed, its checksum (CRC) area is zeroed. No other options are zeroed before computing ACS. All that is needed is to stuff the remainder of the standard polynomial long division in the ACS checksum area. There are also some issues that need to nailed down for clarity. the usual way that the specified polynomial is used is to invert the first 16 bits of data and transmit the complement of the resulting polynomial division. If that is not done here, it would probably be good to say so. Also, it is necessary to specify whether the data polynomial is constructed as if the bytes are transmitted most significant bit first or least significant bit first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be 0x11021, but that fact is not needed, and I recommend omitting it). Section 5.5, LITE option: the following instruction 3. Swap all four bytes of the LITE option with the first 4 bytes of the LITE data area (Figure 11). works only if the LITE data area is at least four bytes long. However, the option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one simply moves the option to the start of the LITE data area and moves the displaced LITE bytes just past the end of the relocated LITE option. This operation is then reversed on the receive side. In effect, one is swapping the locations of the LITE option and the initial segment of the LITE data area of length min(4, LITE offset). Note that being able to use the LITE option with a length of zero is important for option negotiation. Section 5,8, FRAG option: it appears to me that the length of the the terminal FRAG option is 10 bytes, not 12. This isn't stated, but the inference I make is that the the checksum is the standard UDP checksum, computed as if the datagram were sent unfragmented, but not including the pseudo-header (to avoid issues created by NAT). If this isn't what was intended, then the intent needs to be clearly spelled out. I note that if the alternate checksum as defined in Section 5.4 does not admit the use of the value zero to indicate that it is not present. Section 5.8.1, Coupling FRAG with LITE: if the comments above about the checksum field in the terminal FRAG option are correct, some text should be added here that the final checksum in the reconstituted UDP header is not taken directly from the terminal fragment, but is adjusted to include the UDP pseudo-header. Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over from a previous incarnation of the draft? UDP options support a similar service to UDP-Lite by terminating the UDP options with an EOL option. The additional data not covered by the UDP checksum follows that EOL option, and is passed to the user separately. The difference is that UDP-Lite provides the un- checksummed user data to the application by default, whereas UDP options can provide the same capability only for endpoints that are negotiated in advance (i.e., by default, UDP options would silently discard this non-checksummed data). Additionally, in UDP-Lite the checksummed and non-checksummed payload components are adjacent, whereas in UDP options they are separated by the option area - which, minimally, must consist of at least one EOL option. It seems to me that this should be rewritten, because the service in question is now provided by the LITE option. I'm hoping that there is still enough interest in this draft to push it to completion. Thanks and regards, Mike Heard --000000000000873f4f056b8cd2b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

Some issues came to my atten= tion during a recent off-list discussion with someone from the DNS communit= y.

Section 5.4, Alternate Checksum (ACS): since th= e option area is not included in the ACS, the following text seems out of p= lace:

   When ACS is computed, its checksum (CRC) area is zeroed. =
No other
   options are zeroed before computing ACS.

All that is needed is to stuff the remainde= r of the standard polynomial long division in the ACS checksum area.
<= div>
There are also some issues that need to nailed down for = clarity. the usual way that the specified polynomial is used is to invert t= he first 16 bits of data and transmit the complement of the resulting polyn= omial division. If that is not done here, it would probably be good to say = so. Also, it is necessary to specify whether the data polynomial is constru= cted as if the bytes are transmitted most significant bit first or least si= gnificant bit first. Finally, the polynomial is=C2=A0x^16 + x^12 + x^5 + 1 (which would be 0x1102= 1, but that fact is not needed, and I recommend omitting it).
<= div>
Section 5.5, LITE option: the following instruction

   3. Swap all four bytes of the LITE option with the first 4 bytes of
      the LITE data area (Figure 11).

works only if the LITE data area is at leas= t four bytes long. However, the option will work just fine with 0, 1, 2, or= 3 bytes of LITE data if one simply moves the option to the start of the LI= TE data area and moves the displaced LITE bytes just past the end of the re= located LITE option. This operation is then reversed on the receive side. I= n effect, one is swapping the locations of the LITE option and the initial = segment of the LITE data area of length min(4, LITE offset).

=
Note that being able to use the LITE option with a length of zer= o is important for option negotiation.

Section 5,8= , FRAG option: it appears to me that the length of the the terminal FRAG op= tion is 10 bytes, not 12. This isn't stated, but the inference I make i= s that the the checksum is the standard UDP checksum, computed as if the da= tagram were sent unfragmented, but not including the pseudo-header (to avoi= d issues created by NAT). If this isn't what was intended, then the int= ent needs to be clearly spelled out. I note that if the alternate checksum = as defined in Section 5.4 does not admit the use of the value zero to indic= ate that it is not present.

Section 5.8.1, Coupling FRA= G with LITE: if the comments above about the checksum field in the terminal= FRAG option are correct, some text should be added here that the final che= cksum in the reconstituted UDP header is not taken directly from the termin= al fragment, but is adjusted to include the UDP pseudo-header.

Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over= from a previous incarnation of the draft?

   UDP options support a simi=
lar service to UDP-Lite by terminating the
   UDP options with an EOL option. The additional data not covered by
   the UDP checksum follows that EOL option, and is passed to the user
   separately. The difference is that UDP-Lite provides the un-
   checksummed user data to the application by default, whereas UDP
   options can provide the same capability only for endpoints that are
   negotiated in advance (i.e., by default, UDP options would silently
   discard this non-checksummed data). Additionally, in UDP-Lite the
   checksummed and non-checksummed payload components are adjacent,
   whereas in UDP options they are separated by the option area -
   which, minimally, must consist of at least one EOL option.

It seems to me that this should be rewritte= n, because the service in question is now provided by the LITE option.

I'm hoping that there is still enough interest in = this draft to push it to completion.

Thanks and re= gards,

Mike Heard
--000000000000873f4f056b8cd2b9-- From nobody Mon May 7 10:28:29 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC79120724; Mon, 7 May 2018 10:28:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152571410692.1419.9310859363419279556@ietfa.amsl.com> Date: Mon, 07 May 2018 10:28:26 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 17:28:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME Authors : Vincent Roca Belkacem Teibi Filename : draft-ietf-tsvwg-rlc-fec-scheme-03.txt Pages : 30 Date : 2018-05-07 Abstract: This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over GF(2) (binary case), a second one for RLC over GF(2^^8), both of them with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real-time flows in terms of reduced FEC- related latency while often providing improved packet erasure recovery capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 7 10:46:02 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8712E049; Mon, 7 May 2018 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 i-nmKPrwMPxy; Mon, 7 May 2018 10:45:53 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 ACC9112E051; Mon, 7 May 2018 10:45:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,375,1520895600"; d="scan'208,217";a="264592911" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.103]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2018 19:45:45 +0200 From: Vincent Roca Message-Id: <4B48081F-E34B-4B3A-BADF-CF51D2A95971@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_90EC9E67-74AB-4830-B6DB-F6BDAB1F56D6" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 7 May 2018 19:45:44 +0200 In-Reply-To: <152571410692.1419.9310859363419279556@ietfa.amsl.com> Cc: tsvwg@ietf.org, nwcrg@irtf.org To: internet-drafts@ietf.org References: <152571410692.1419.9310859363419279556@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 17:46:01 -0000 --Apple-Mail=_90EC9E67-74AB-4830-B6DB-F6BDAB1F56D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Here is a new version of our RLC FEC Scheme I-D. This is a major = revision. This version: - includes the updates following Gorry's detailed review; - changes the way the coding coefficients are generated in a non = backward compatible manner (at this stage, this is not an issue). In fact after = initializing the PRNG with a seed, we add a first call to rand whose return value = is ignored. "Indeed, the PRNG sequences produced by two seeds in sequence have a high probability of starting with the same value since I1 =3D A * = seed (modulo M) which is further scaled to a small range (either {0, ... 15} or {0, ... 255}). Producing several times the same first coding coefficient could reduce the protection of the first source symbol if multiple repair symbols are produced with the same coding window's left edge. The extra call avoids such side effects. =C2=BB This is something we only discovered recently! Fixing this issue like = that avoids to recommend not to use seeds in sequence in the application = which I think will be a common way of managing those seeds. No matter what = the developer chooses, the sequence should be appropriate. - includes a new version of section 3.1. "Possible Parameter Derivation" There is I think a much better structure, that better explains what = could be done depending on the situtation, what is sender specific or receiver = specific, and how a receiver can evaluate the maximum encoding window size whereas = this parameter is never transmitted explicitly. - includes a brand new section 3.6. "Linear Combination of Source = Symbols Computation =C2=BB. We realised this was not necessarily clear how to do that. There is = also a link to a well known reference that further explains how to perform such = computation efficiently [PBM13]. - and various clarifications here and there. Cheers, Vincent and Belkacem > Le 7 mai 2018 =C3=A0 19:28, internet-drafts@ietf.org a =C3=A9crit : >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group WG of = the IETF. >=20 > Title : Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Schemes for FECFRAME > Authors : Vincent Roca > Belkacem Teibi > Filename : draft-ietf-tsvwg-rlc-fec-scheme-03.txt > Pages : 30 > Date : 2018-05-07 >=20 > Abstract: > This document describes two fully-specified Forward Erasure > Correction (FEC) Schemes for Sliding Window Random Linear Codes > (RLC), one for RLC over GF(2) (binary case), a second one for RLC > over GF(2^^8), both of them with the possibility of controlling the > code density. They can protect arbitrary media streams along the > lines defined by FECFRAME extended to sliding window FEC codes. > These sliding window FEC codes rely on an encoding window that = slides > over the source symbols, generating new repair symbols whenever > needed. Compared to block FEC codes, these sliding window FEC codes > offer key advantages with real-time flows in terms of reduced FEC- > related latency while often providing improved packet erasure > recovery capabilities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rlc-fec-scheme-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_90EC9E67-74AB-4830-B6DB-F6BDAB1F56D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all,

Here is a new = version of our RLC FEC Scheme I-D. This is a major = revision.
This version:

- includes the updates following Gorry's detailed review;

- changes the way the = coding coefficients are generated in a non backward
  compatible manner (at this stage, this is not an = issue). In fact after initializing
  the PRNG = with a seed, we add a first call to rand whose return value is = ignored.

  "Indeed, the PRNG sequences produced by two seeds in = sequence have a
   high probability of = starting with the same value since I1 =3D A * seed
   (modulo M) which is further scaled to a small = range (either {0, ...
   15} or {0, ... = 255}).  Producing several times the same first coding
   coefficient could reduce the protection of the = first source symbol if
   multiple repair = symbols are produced with the same coding window's
   left edge.  The extra call avoids such side = effects. =C2=BB

  This is something we only discovered recently! Fixing = this issue like that
  avoids to recommend not = to use seeds in sequence in the application which
  I think will be a common way of managing those seeds. = No matter what the
  developer chooses, the = sequence should be appropriate.

- includes a new = version of section 3.1. "Possible Parameter = Derivation"
  There is I think a much = better structure, that better explains what could be done
  depending on the situtation, what is sender specific = or receiver specific, and
  how a receiver can = evaluate the maximum encoding window size whereas this
  parameter is never transmitted explicitly.

- includes a brand new section 3.6. "Linear = Combination of Source Symbols
  Computation =C2=BB.
 = We realised this was not necessarily clear how to do that. There is = also a link to a
  well known reference that = further explains how to perform such computation
  efficiently [PBM13].

- and various clarifications here and = there.

Cheers,

   Vincent and Belkacem


Le 7 mai 2018 =C3=A0 19:28, internet-drafts@ietf.org a =C3=A9crit :


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Transport Area Working Group WG of the IETF.

       Title =           : Sliding = Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes = for FECFRAME
=        Authors =         : Vincent Roca
=             &n= bsp;           &nbs= p;Belkacem Teibi
Filename =        : = draft-ietf-tsvwg-rlc-fec-scheme-03.txt
Pages =           : 30
= Date =            : = 2018-05-07

Abstract:
=   This document describes two fully-specified Forward = Erasure
  Correction (FEC) Schemes for Sliding = Window Random Linear Codes
  (RLC), one for RLC = over GF(2) (binary case), a second one for RLC
=   over GF(2^^8), both of them with the possibility of = controlling the
  code density.  They can = protect arbitrary media streams along the
=   lines defined by FECFRAME extended to sliding window FEC = codes.
  These sliding window FEC codes rely on = an encoding window that slides
  over the = source symbols, generating new repair symbols whenever
=   needed.  Compared to block FEC codes, these sliding = window FEC codes
  offer key advantages with = real-time flows in terms of reduced FEC-
=   related latency while often providing improved packet = erasure
  recovery capabilities.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-schem= e/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-03<= br = class=3D"">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-= scheme-03

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rlc-fec-sc= heme-03


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


= --Apple-Mail=_90EC9E67-74AB-4830-B6DB-F6BDAB1F56D6-- From nobody Mon May 7 12:23:38 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D450E12783A; Mon, 7 May 2018 12:23:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152572100582.1399.1069032621613899291@ietfa.amsl.com> Date: Mon, 07 May 2018 12:23:25 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-iana-dscp-registry-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 19:23:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC Author : Godred Fairhurst Filename : draft-ietf-tsvwg-iana-dscp-registry-03.txt Pages : 7 Date : 2018-05-07 Abstract: The Differentiated Services (Diffserv) architecture specifies use of a field in the IPv4 and IPv6 packet headers to carry Diffserv Codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the Codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-iana-dscp-registry-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-dscp-registry-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 7 12:29:55 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6953E128961 for ; Mon, 7 May 2018 12:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 17nLfQwtMhp7 for ; Mon, 7 May 2018 12:29:53 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id E446E126FDC for ; Mon, 7 May 2018 12:29:52 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 827B01B00218 for ; Mon, 7 May 2018 20:29:19 +0100 (BST) Message-ID: <5AF0A90F.6080702@erg.abdn.ac.uk> Date: Mon, 07 May 2018 20:29:19 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "tsvwg@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [tsvwg] New rev for draft-ietf-tsvwg-iana-dscp-registry X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 19:29:54 -0000 This email is to announce a new revision to the draft for draft-ietf-tsvwg-iana-dscp-registry. This revision inlcudes corrections, in response to David's review (see below). There changes are all editorial. Gorry (as editor) --- [1] Abstract OLD Pool 1 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes NEW Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes - Done [2] Section 1, Introduction OLD At the time of writing this document, 23 of the 32 Pool 1 codepoints have currently been assigned. NEW At the time of writing this document, 22 of the 32 Pool 1 codepoints have currently been assigned. - Done [3] Section 3, the Update to RFC2474 Figure 2 omits the Reserved for experimental or Local Use note on Pool 2 in the IANA registry. Either here, or in Section 5 IANA Considerations, it needs to be clear that IANA is to preserve that note. The underlying situation appears to be that in creating the registry, IANA appears to have added the Note column to the initial contents specified in RFC 2474, and Figure 2 is updating RFC 2474s contents. I would add the note to the Pool 2 line Figure 2. - I added the note, so this is not missed by IANA (although the registry has more columns that an IETF ID, and so this was inserted on a separate line. To ne clear, also noted the presence of the note in the IANA considerations. [4] References Both [RFC8126] and [Registry] need to be Normative References. I did this. Editorial nit in first paragraph of Introduction: IPV6 -> IPv6 - Annoyingly, I forgot this, but I have now fixed in the source file - so it will be in rev -04. Gorry From nobody Mon May 7 12:53:44 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79E12783A for ; Mon, 7 May 2018 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=Yd3IYOJN; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=rkABAqhX 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 p8VvSjVBZSau for ; Mon, 7 May 2018 12:53:40 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 D1479124C27 for ; Mon, 7 May 2018 12:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1525722819; x=1557258819; h=from:to:subject:date:message-id:mime-version; bh=mqQg8T3Aw3l4yiXCV4Ri7EmaAck/XQllJZKqY+iOAjo=; b=Yd3IYOJNylZ6tNbozLhfw0kWCg7OBKnmhSMo7+f0WTetVu29ZMjDzNLX DT+IKY62cVqVp4ikHY83+3KqiQp2Di24t4/HNTddAUG8dd3t7NASsZvrm 9TW0hihdAkOFR5Hsclp63HDzJIYA0aicvA7JFNhZMszCNpYFlFxN/ZqQr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HFAABIrfBamGOa6ERaAx+CXyIqfg4XY?= =?us-ascii?q?ygKmFuDCJMmgT07CycHhD4CglQhNBgBAgEBAQEBAQIBAQIQAQEBAQEICwsGKCM?= =?us-ascii?q?BC4I1IhFLIQgzAQEBAQEBAQEBAQEBAQEBAQEBFwJDARIBRwYTHxsRARoQHTkUA?= =?us-ascii?q?w8BBAoJCBOEImQBDqlnM4J2hVCCQAMFiCWBVT6DG4NuIgEBAwGBOSUfDBqCaYI?= =?us-ascii?q?khziQdAMFAoVjglKHS4Ngh02JRoZfAgQCBAUCFIElHIILcIMTgi6BAwEHCAeBL?= =?us-ascii?q?YEHhRSFPm8wjnyBGAEB?= X-IPAS-Result: =?us-ascii?q?A2HFAABIrfBamGOa6ERaAx+CXyIqfg4XYygKmFuDCJMmgT0?= =?us-ascii?q?7CycHhD4CglQhNBgBAgEBAQEBAQIBAQIQAQEBAQEICwsGKCMBC4I1IhFLIQgzA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBFwJDARIBRwYTHxsRARoQHTkUAw8BBAoJCBOEImQ?= =?us-ascii?q?BDqlnM4J2hVCCQAMFiCWBVT6DG4NuIgEBAwGBOSUfDBqCaYIkhziQdAMFAoVjg?= =?us-ascii?q?lKHS4Ngh02JRoZfAgQCBAUCFIElHIILcIMTgi6BAwEHCAeBLYEHhRSFPm8wjny?= =?us-ascii?q?BGAEB?= Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2018 14:53:37 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 01:53:36 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w47JrZtx029005 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 7 May 2018 15:53:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w47JrZtx029005 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1525722816; bh=dhmSL7PXm3CsdX91BRlTP9d/0bg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=rkABAqhXtWzcyhfJtv31o4OEDwXETZfYIaH36zcfnPhjsg9rJXwKgMkgy5B+OXEnF bonFxi0EbcSwFSY+uGZtcJ4YiUXnIu/CNXs1Gys4ZFTnRyKNPvgO/I1OdyAb+bY57B EZlN9LSNLy8r5Hy/K7WH0Ed8V2+t3qa/2R18KkXg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w47JrZtx029005 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Mon, 7 May 2018 15:53:20 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w47JrLVa000419 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Mon, 7 May 2018 15:53:21 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0382.000; Mon, 7 May 2018 15:53:20 -0400 To: "tsvwg@ietf.org" Thread-Topic: David Black's Review of draft-finzi-priority-switching-scheduler Thread-Index: AdPmN8RfNwWa7gzLR+mcdFJjPmJ5DQ== Date: Mon, 7 May 2018 19:53:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.33] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363010D3D6MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: [tsvwg] David Black's Review of draft-finzi-priority-switching-scheduler X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 19:53:42 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363010D3D6MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I write as an individual, not as WG co-chair. I appreciate the effort that= the authors have made to bring this draft to the IETF. Draft status page: https://datatracker.ietf.org/doc/draft-finzi-priority-switching-scheduler/ Slides from London tsvwg meeting (March 2018): https://datatracker.ietf.org/meeting/101/materials/slides-1= 01-tsvwg-sessb-33-priority-switching-scheduler-00 I like the slides much more than I like the draft. My initial thought on = reading the draft was to suggest switching the order of Sections 2 and 3 so= that discussion of the problem in Diffserv context (important for IETF) wo= uld precede explanation of the solution. After looking at the slides, I re= alized that what's really wanted is a shorter up-front summary of how this = scheduling technique can benefit a Diffserv router implementation, as slide= 3 concisely explains. Sections 2 and 3 should then be fine in their curre= nt order if an analogous (to slide 3) explanation of how this scheduler ben= efits a Diffserv router implementation is added to Section 1, perhaps to fo= llow the current Section 1.1. As this draft is not intended to be standards track, I strongly suggest tha= t the authors submit a PDF version in addition to the text version, as the = PDF diagrams should be much more comprehensible by comparison to ASCII grap= hics, and it should be possible to include more detailed graphs. The implementation pseudo-code and discussion in Section 2.2 might be bette= r moved to an Appendix. Are there any results from simulated or actual traffic? Section 3.2's pointer to the Globecom paper for the results of the schedule= r scenario described in Section 3.1 is unsatisfying - please include conten= t analogous to slide 14. Obviously, Section 4 (Security Considerations) needs to be written ;-). At= a minimum, I suggest comparing this scheduler to others that it might repl= ace on opportunities for theft or denial of service - e.g., is one of the s= chedulers more prone to starvation of a class of traffic than another? Finally, this text on p.7 bothered me: the Assured Forwarding (AF) class deals with elastic traffic as defined in [RFC4594] (data transfer, updating process, ...) while all other remaining traffic is classified inside the default (DE) best-effort class. I traced my concern back to this text in Section 1.5 of RFC 4594 ... While Differentiated Services is a general architecture that may be used to implement a variety of services, three fundamental forwarding behaviors have been defined and characterized for general use. These are basic Default Forwarding (DF) behavior for elastic traffic, the Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF) behavior for real-time (inelastic) traffic. In other words, a lot of the best-effort traffic is elastic, so it's not co= rrect to imply that all elastic traffic would use AF. For AF, I'd suggest= instead picking a relevant service class or two from RFC 4594, perhaps Hig= h-Throughput Data or Low-Latency Data. Also, "(DE)" -> "(DF)". I think another version of this draft would be a good idea. Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949363010D3D6MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I write as an individual, not as WG co-chair.  = I appreciate the effort that the authors have made to bring this draft to t= he IETF.

 

Draft status page:

https://datat= racker.ietf.org/doc/draft-finzi-priority-switching-scheduler/

Slides from London tsvwg meeting (March 2018):<= /o:p>

        &nbs= p;       https://datatracker.ietf.org/meeting/101/materials/slides-101-tsvwg-sessb-3= 3-priority-switching-scheduler-00

 

I like the slides much more than I like the draft.&n= bsp;  My initial thought on reading the draft was to suggest switching= the order of Sections 2 and 3 so that discussion of the problem in Diffser= v context (important for IETF) would precede explanation of the solution.  After looking at the slides, I realized= that what’s really wanted is a shorter up-front summary of how this = scheduling technique can benefit a Diffserv router implementation, as slide= 3 concisely explains.  Sections 2 and 3 should then be fine in their current order if an analogous (to slide 3) explanati= on of how this scheduler benefits a Diffserv router implementation is added= to Section 1, perhaps to follow the current Section 1.1.

 

As this draft is not intended to be standards track,= I strongly suggest that the authors submit a PDF version in addition to th= e text version, as the PDF diagrams should be much more comprehensible by c= omparison to ASCII graphics, and it should be possible to include more detailed graphs.

 

The implementation pseudo-code and discussion in Sec= tion 2.2 might be better moved to an Appendix.

 

Are there any results from simulated or actual traff= ic?

 

Section 3.2’s pointer to the Globecom paper fo= r the results of the scheduler scenario described in Section 3.1 is unsatis= fying – please include content analogous to slide 14.

 

Obviously, Section 4 (Security Considerations) needs= to be written ;-).  At a minimum, I suggest comparing this scheduler = to others that it might replace on opportunities for theft or denial of ser= vice – e.g., is one of the schedulers more prone to starvation of a class of traffic than another?

 

Finally, this text on p.7 bothered me:

 

   the Assured Forwarding
   (AF) class deals with elastic traffic as defined in [RFC4594] (data<=
/pre>
   transfer, updating process, ...) while all other remainin=
g traffic is
   classified inside the default (DE) best-effort class.
 

I traced my concern back to this text in Section 1.5= of RFC 4594 …

 

   While Differentiated Services is a general architecture t=
hat may be
   used to implement a variety of services, three fundamenta=
l forwarding
   behaviors have been defined and characterized for general=
 use.  These
   are basic Default Forwarding (DF) behavior for elastic tr=
affic, the
   Assured Forwarding (AF) behavior, and the Expedited Forwa=
rding (EF)
   behavior for real-time (inelastic) traffic. 

 

In other words, a lot of the best-effort traffic is = elastic, so it’s not correct to imply that all elastic traffic would = use AF.   For AF, I’d suggest instead picking a relevant se= rvice class or two from RFC 4594, perhaps High-Throughput Data or Low-Latency Data.  Also, “(DE)” -> “(DF)= ”.

 

I think another version of this draft would be a goo= d idea.

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953    Mobile: += ;1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D243277949363010D3D6MX307CL04corpem_-- From nobody Tue May 8 00:29:31 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75D12704A; Tue, 8 May 2018 00:29:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152576456939.20158.1539784165906137453@ietfa.amsl.com> Date: Tue, 08 May 2018 00:29:29 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-iana-dscp-registry-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 07:29:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC Author : Godred Fairhurst Filename : draft-ietf-tsvwg-iana-dscp-registry-04.txt Pages : 7 Date : 2018-05-08 Abstract: The Differentiated Services (Diffserv) architecture specifies use of a field in the IPv4 and IPv6 packet headers to carry Diffserv Codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the Codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-iana-dscp-registry-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-dscp-registry-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 8 00:56:30 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10E91271FD for ; Tue, 8 May 2018 00:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 GBpKf9WrJyEQ for ; Tue, 8 May 2018 00:56:26 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.4]) (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 9E85D1270B4 for ; Tue, 8 May 2018 00:56:25 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-central-1.aws.symcld.net id 50/2B-30567-52851FA5; Tue, 08 May 2018 07:56:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUgTcRjH+93d5hVe/LZZPi2zXFmUbrk0MCE Q+iPp1USsDKubXdtgO22bNfsngxJ8A9EkM8VpFqEi5XoRNDWjFysTJbECM3GGmbJKerE/rLvd NLs/ju/v+Xx/z/O946FJ5YBcTXNOB2fjWYtGvoSKCYtP04Yf+poa9aYDYj/nXkWxTyaH5PFEQ uH0OJFQVzdDJBKpMjNvyHAel5naRl7IMrujnddmLhM56LYuHy2hKZxLQqnrvlw8KHE5AZ6Kx0 g6jCDo6+0RyGJajrdDc8OQoAPoIKyH9qR8RNMkDof2iXOiQYX3QVOP12cOwslQ654hJK2DsfP TSNQUXgcPR+op8SqDj8Ofiz4Lwsvh5/NGnyZxMLzzVPs0YAx1bb2kpJfBp9FZmeQ3wPBYDZLq YVD+vjJA0qugv7rAFx7wPQJ+tw3IJaCFL2VlpDgX8Fq4M54meR4jKLpZ4m8UCU15pf5GGfC+p NA/+Ah0dA7766FQXzRCSZefktB4q8EPQqByqN0PfstgcNbji6rE6fCsctoPRhFMF08R0u9Sw9 DrPFSMIioWfLakefBMdSJRM1gB3Vc8lFSPBFfrN7mkI+BGzWdyTr/sHCUW1l0ooB5tM9jMRpP DypotWn1UlFavj9Zu0W7RR+vYs1pWx2Vp0zneYWMFqmPP2HX2bGu65YSO5xzNSFiuRcLTgh71 sF1oBU1oljHDe76mKpcaMk5km1i76Zgty8LZu1AITWuA2XtQYAobZ+ScJ80WYUPnMNCBmiDmd IqAGXsma7WbjRJ6jqLpLu+lQpJ+Jb6VFJ/Bc+pgRiF2wqLVlMXPN5rb9n60Sq1ikBBNGZjJ2a xmx/98AgXTSKNidoldAs28Y37ehBCFEKIoPnjFKA72H1LnIINzQy1ToSsK6nE7UmorH9zsLmg NYXt3VMnWJ11Ij9lacbSg9AeMejnv5jN3I9/+4g9/osrj4hTX1xQGB6TkH3DDil/jy/evCwyt ORDzcSoRZA1jqo3fd2is7r6EwebdycVT7OqWXpcqfHJmshqeNe80Gk15Bff6Y091VeHElRrKb mL1m0ibnf0Lp4q9KegDAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-40.tower-226.messagelabs.com!1525766177!484505!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 5775 invoked from network); 8 May 2018 07:56:20 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-40.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 May 2018 07:56:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hes2Hu/4Czi5veuHeHhrTmYRJfSN7rq49Tr2hu7NCG0=; b=CRhk6Ql9trMTCOvNgjurVPDQUXyDDer26Pae1D4gaGO9vmSPR9awZ0cUcIXqhRKPicgEgIisc+O0cpZgA7kV3tvc3Um65VJjYOW/PzPw86NCFAvczdLlGUibLe7d5aXYL37JxR2pUzSrcZIoVvv9ECR4rXDfoX88ev6ep/+B43E= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2103.eurprd03.prod.outlook.com (10.167.228.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Tue, 8 May 2018 07:56:16 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909%14]) with mapi id 15.20.0735.019; Tue, 8 May 2018 07:56:16 +0000 From: Alexander Vainshtein To: "gorry@erg.abdn.ac.uk" CC: "tsvwg@ietf.org" Thread-Topic: Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hw== Date: Tue, 8 May 2018 07:56:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB2103; 7:nrSNj31+/34Pc8Y5DsgggtNFaTfJMt/Gexa8iPDU23Jy7NiDPe93hgHcEPbsxxdyBbWS4JwK+H2+0VqkUHWzh/3ukbtJhjGCK49+Eut9nYDzjwCJ/Sm+yWnQc7e6JnaaCMsf8BkaJyjETB9moQ18Oe+tur1IAwjs4wYIxd7J2Ksl2dTyjzRTF0u36IJlRIfdjr1NvJa/ME+T6XEJe+OKNErjHUQM7a8Zq95FEEHVAob2PkRJ7TDnFTh+DmgG/wBD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2103; x-ms-traffictypediagnostic: DB5PR0301MB2103: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(279101305709854); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DB5PR0301MB2103; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2103; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(376002)(39380400002)(346002)(252514010)(199004)(189003)(8676002)(14454004)(25786009)(68736007)(105586002)(6506007)(6436002)(97736004)(7736002)(26005)(790700001)(476003)(6116002)(3846002)(106356001)(486006)(186003)(7696005)(102836004)(606006)(72206003)(99286004)(4326008)(6916009)(3660700001)(81156014)(53936002)(2906002)(74316002)(1730700003)(81166006)(5250100002)(2900100001)(296002)(66066001)(2351001)(316002)(33656002)(478600001)(55016002)(236005)(2501003)(9686003)(54896002)(5660300001)(5640700003)(8936002)(6306002)(3280700002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2103; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ubQzfhbL/yXpoKVRC8uFmShzrI7Gegd2gbUHOzZAS7Lf+0yYT3aDBokYsluKe/ByF1PkrzMnzrSUkspQrzcl7VoRTW9tmbc8GU5thi80xFA9mNY2UO9RLRASkwKKtSxoKIj+gT6u5hUCKSF3E+VMWtBEwA9K+RMdrmjk9MpJ3hSaJj10+IKJRORYtgzYoaHo spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0DB5PR0301MB1909_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d1e9baf1-8f30-4746-27ff-08d5b4b92d3b X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1e9baf1-8f30-4746-27ff-08d5b4b92d3b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 07:56:16.3125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2103 X-CFilter-Loop: Reflected Archived-At: Subject: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 07:56:28 -0000 --_000_DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0DB5PR0301MB1909_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Godred and all, I have looked up the draft, and I have doubts regarding validity of its motivati= on. The draft says - correctly -that 22 out of 32 values in Pool 1 of the DSCP= code points have been already assigned, therefore it considers this pool = as nearly exhausted. What the draft does not say that, out of these 22 assignments, 2o have bee= n done in 1998 and one - in 1999. Only one assignment has been requested i= n the past 19 years, and no assignments have been requested after 2010. At this rate my estimate is that Pool 1 would suffice for the next 50+ yea= rs without its exhaustion becoming an issue. So why should the IETF do any= thing now? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0DB5PR0301MB1909_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Godred and all,

I have looked up the draft, and I have doubts regarding validity of its motivation.

The draft says – correctly -that 22=20out of = 32 values in Pool 1 of the DSCP code points have been already assigned, th= erefore it considers this pool as nearly exhausted.

 

What the draft does not say that, out of these 22 a= ssignments, 2o have been done in 1998 and one – in 1999. Only one as= signment has been requested in the past 19 years, and no assignments have = been requested after 2010.

 

At this rate my estimate is that Pool 1 would suffi= ce for the next 50+ years without its exhaustion becoming an issue. So= why should the IETF do anything now?

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266= 302

Email:   Alexander.Vainshtein@ecitele.com=

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0DB5PR0301MB1909_-- From nobody Tue May 8 02:14:05 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D1B126D0C for ; Tue, 8 May 2018 02:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 fQ0N1KyW981x for ; Tue, 8 May 2018 02:14:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 196071201F2 for ; Tue, 8 May 2018 02:14:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AB777B1; Tue, 8 May 2018 11:13:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1525770838; bh=r+nJqn0vCeYnBbiWyUPEEbndSExARXjNe8OL3xVBnMA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bLaxRyE1NHfmRrJ9UT/vzJ6YAXHj5mSJ1OIiIhdLkIWeajIYmn0rQljgAlI0MSkAy FJZDvDIxRFf7C4IOaLgMgt+g51Ci1sE4Tyc3rBL/CB05iK6eivLXVi6QsQrsq5bYkw nq0ZmxoeQ33up5loJa30uC/g/iVkKv+CTUgHwrGA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A6DEFB0; Tue, 8 May 2018 11:13:58 +0200 (CEST) Date: Tue, 8 May 2018 11:13:58 +0200 (CEST) From: Mikael Abrahamsson To: Alexander Vainshtein cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 09:14:04 -0000 On Tue, 8 May 2018, Alexander Vainshtein wrote: > Godred and all, > I have looked up the draft, and I have doubts regarding validity of its motivation. > The draft says - correctly -that 22 out of 32 values in Pool 1 of the DSCP code points have been already assigned, therefore it considers this pool as nearly exhausted. > > What the draft does not say that, out of these 22 assignments, 2o have been done in 1998 and one - in 1999. Only one assignment has been requested in the past 19 years, and no assignments have been requested after 2010. > > At this rate my estimate is that Pool 1 would suffice for the next 50+ years without its exhaustion becoming an issue. So why should the IETF do anything now? The primary reason for this is not because pool 1 is becoming exhausted, but the fact that we want to use 000001 for LE (for practical/legacy reasons, not because pool 1 is becoming exhausted), so the suggestion is therefore to make Pool 3 have a different allocation policy so we can put in a standards track PHB LE RFC for 000001. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue May 8 02:25:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F417E127876 for ; Tue, 8 May 2018 02:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vLDMcelHJfhb for ; Tue, 8 May 2018 02:25:43 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 6A0981275FD for ; Tue, 8 May 2018 02:25:43 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1fFysK-0005oG-Kv; Tue, 08 May 2018 11:25:36 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 8EFE8420F55; Tue, 8 May 2018 11:25:36 +0200 (CEST) To: Alexander Vainshtein , "gorry@erg.abdn.ac.uk" Cc: "tsvwg@ietf.org" References: From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Tue, 8 May 2018 11:25:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1525771536.722003011 Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 09:25:46 -0000 Hi Sasha, Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: > I have looked up the draft > , > and I have doubts regarding validity of its motivation. > > The draft says correctly -that 22 out of 32 values in Pool 1 of the > DSCP code points have been already assigned, therefore it considers this > pool as nearly exhausted. > > What the draft does not say that, out of these 22 assignments, 2o have > been done in 1998 and one in 1999. Only one assignment has been > requested in the past 19 years, and no assignments have been requested > after 2010. > At this rate my estimate is that Pool 1 would suffice for the next 50+ > years without its exhaustion becoming an issue. So why should the IETF > do anything */now/*? This is motivated in section 1: The rationale for this update is a need to assign codepoints for particular PHBs that are unable to use any of the unassigned values in Pool 1. This problem is caused by implementations that do IP precedence bleaching (i.e., zeroing the top three bits of the DSCP) thereby rewriting (or unintentionally mapping) DSCP values to other DSCP values. This is a problem for the mentioned LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb It is possible that some other standardized DSCPs get mapped to the LE PHB DSCP if the LE DSCP were taken from the DSCP standards action pool 1 (xxxxx0). There are measurements and more background material for this: https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00 https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf Regards, Roland From nobody Tue May 8 02:26:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BA124B0A for ; Tue, 8 May 2018 02:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 63EID_Xp08zj for ; Tue, 8 May 2018 02:26:37 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.4]) (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 A91D5127275 for ; Tue, 8 May 2018 02:26:36 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-central-1.aws.symcld.net id CA/3B-30567-94D61FA5; Tue, 08 May 2018 09:26:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTURjHO/fe3W62G9dN29PQomWQ5caGlfa hiMIwrOhDI7A07/TqhtuUbdKMKCMq0wYlrFcrjRVpUSZqhctA8xUpMtHIfENDbVq6Iit6u3d3 vZ1Pv3P+z/P/n3N4KFx2i1RSnNPB2aysWUWGEKujP0epEy0zydrHRXHxvuOXUPzE9VoyvmWyn 9yIJ576MI4lejxfsMTvJcPYTjxZYrIacpxpEmOXvxvldtPOmaoCsgBVzi9CIRTBHMfhU+s4Jm xkzDkMih+dQOJmGEGZd4wsQvMoklkP1bf6AxzGRMO9+1UBxhk93PH9RALLmT0w6arFxJq9UHe 0G4msgbFvs4TABBMF7148lAhMM2ng6y0PnCNmIcx23MZETwW8Gr0aYGAY8Hif4SKHw8TID4lY b4DBN+VIPF8K5wdK54ocCV1XiwMPAKYOgyOvPYQoqGHa7eaNKJ6XQc14iljTg6C39y4p1sTAd Ks7GJYDU0+8QdNtcLOlNlizGCpdw0QwAIdjfc+DARFQ2t8Q5CEJTLkPCSxj0qGt9EOwYQTB08 sNEvG7lNDffRKdRjEX/3m1yDFQVu8nRV4FN8p9+MXAj4VC+4VRogwRlSjeYDNlGR0W1mRW67R atU4Xq9ap167TsAfUrIbLU6dzVoeN5UUNu9+usedb0s0ZGivnqEb8EM3h1wPkbchoRIsoTBVO T+yeSZYtMORk5BtZu3GfLc/M2RtRBEWpgDaaeS3UxmVxzkyTmZ/E3zJQUlUYnZrNy7Q9l7XYT Vmi1IGWKhV0nNDHCIIxz/qn7fcMd6FIpZxG/EVk0lzOZjE5/tffIgWFVHI6VnCRmqyOP+5v+W CMDw4dei8EO9i/krIAuei+sbrUS1F9sk79jkJvbmFPy7e2kl1bB/wt8hVn8frl1P4Eb027//J pNlt5DIvOTNU29YBTnzJQsSnnZefIcHJbxejha1UbNlQk7Z3arG9W1khjw89c+fo5MmRSkjDj W7Js6PzHpFmnYc1g0fctVDPXvn1b7A2XVtHbtPigJk5F2I2sbiVus7O/ACIUlMS+AwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-35.tower-226.messagelabs.com!1525771589!489158!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 30269 invoked from network); 8 May 2018 09:26:32 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-35.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 May 2018 09:26:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2u6j1HTt+9f/9/sW9gtM7pRJwW6NrG39hBkH4jdnB+Q=; b=mShBd0w98AT0BLUFhn4MuHnEckYN5DNs2p2qO5AQEpMnjYeakKaM3FhpY/TYuIdZJV4ha7Jz8VGr7setBqb1yU/6dQ+nrQvOF2swfv6sC/JyDmeaXI/EofW7Qhi77gm2BpuCZtmcamYEZlu5E7oW98txQjVA/UxxDbzAjZc1ggU= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1925.eurprd03.prod.outlook.com (10.167.227.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Tue, 8 May 2018 09:26:27 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909%14]) with mapi id 15.20.0735.019; Tue, 8 May 2018 09:26:27 +0000 From: Alexander Vainshtein To: Mikael Abrahamsson CC: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmrhr3ApP35uYHSfu+PAWDUjEHSg== Date: Tue, 8 May 2018 09:26:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1925; 7:sUMoVi7yRW1kfQhmejWcuT4AO9KIKM1MBzwWJDFd0QnB5HsyyTTLoO8cWscn4K7QLzyim1Vv08IcJ07WdV//o7tn7ha4uaYLZwhYwvoYhkWrgTcCTko/MNInJCzC7xb9dloWyaL6I5taNhpWGk13fFAfrXSzTFr4/z3M9YY/KI540ZHaRgSkzniccUjwgOHvU3PPoaxMnXCOauCFEDl2KY2AEuUROtzjNG5+QxAlDUuLrUznRagSXwog8JthuDfd x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1925; x-ms-traffictypediagnostic: DB5PR0301MB1925: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(130329453890623)(279101305709854); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB5PR0301MB1925; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1925; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(39860400002)(39380400002)(252514010)(13464003)(189003)(199004)(5660300001)(6306002)(2906002)(81156014)(3660700001)(6506007)(7696005)(99286004)(8936002)(66066001)(6116002)(5250100002)(3280700002)(6436002)(3846002)(81166006)(316002)(97736004)(74316002)(55016002)(9686003)(8676002)(68736007)(86362001)(486006)(102836004)(105586002)(26005)(6916009)(186003)(2900100001)(478600001)(53936002)(14454004)(25786009)(53546011)(229853002)(6246003)(476003)(106356001)(54906003)(305945005)(4326008)(7736002)(33656002)(72206003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1925; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GaQgfK8B9FynSXzyfBhpq65RlMKd/DgWjzSEDS5EHsLVCM82NbAUUNqM0FqCZ5UBlOZvWogAtINahyW9jk344Um91hZg3OCbgltNQuvkJ/3To/9G/tCCqzx1xMm7p/P56vkEUET3Ll0nF26hQ5iEuWYEho8E9wFuzqn+XkxchuY34LOhMxO6CVdsvqYe5Wab spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 74f55d74-2781-4fe4-3310-08d5b4c5c68f X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74f55d74-2781-4fe4-3310-08d5b4c5c68f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 09:26:27.5154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1925 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 09:26:39 -0000 Mikael, Lots of thanks for a prompt response.=20 Your objective makes sense to me, but it does not appear in the draft in a= ny form. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, May 8, 2018 12:14 PM To: Alexander Vainshtein Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 On Tue, 8 May 2018, Alexander Vainshtein wrote: > Godred and all, > I have looked up the draft, and I have doubts regarding validity of its motiva= tion. > The draft says - correctly -that 22 out of 32 values in Pool 1 of the DS= CP code points have been already assigned, therefore it considers this poo= l as nearly exhausted. > > What the draft does not say that, out of these 22 assignments, 2o have b= een done in 1998 and one - in 1999. Only one assignment has been requested= in the past 19 years, and no assignments have been requested after 2010. > > At this rate my estimate is that Pool 1 would suffice for the next 50+ y= ears without its exhaustion becoming an issue. So why should the IETF do a= nything now? The primary reason for this is not because pool 1 is becoming exhausted, b= ut the fact that we want to use 000001 for LE (for practical/legacy reason= s, not because pool 1 is becoming exhausted), so the suggestion is therefo= re to make Pool 3 have a different allocation policy so we can put in a st= andards track PHB LE RFC for 000001. --=20 Mikael Abrahamsson email: swmike@swm.pp.se __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Tue May 8 07:00:27 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5D12E889; Tue, 8 May 2018 07:00:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Black To: X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, david.black@dell.com, David Black , tsvwg-chairs@ietf.org, tsvwg@ietf.org Message-ID: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2018 07:00:10 -0700 Archived-At: Subject: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:00:10 -0000 David Black has requested publication of draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on behalf of the TSVWG working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ From nobody Tue May 8 07:04:55 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1F12E897 for ; Tue, 8 May 2018 07:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=dUhYce+K; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=NuA5NgGn 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 d470y2i1PKVX for ; Tue, 8 May 2018 07:04:49 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 C57C112E88E for ; Tue, 8 May 2018 07:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1525787656; x=1557323656; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CyilXF4J8T34DozzaU/oPwdy+sJ3zLCEE4cp9rBU8DY=; b=dUhYce+KgzI8nUhCYTGq1oyotTlDnu2tJrW7AKPXTIRdfeg4+80WXcdN tacMgmfupW+mlkHcysV0G3OGvxPKr1rCpRjREsQXDXg/GqgZOnW9XHzIx R8QhDEhm9c1IboqrhLBEqDx4FZC8L8T1AqkZBnB/Q+bZrug1lsgbSumlH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F7AABJrfFah8mZ6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJvJQR+DnooCphbgXmBD5MoFIEpOwslCYQ+AoJmITYWAQIBAQEBAQE?= =?us-ascii?q?CAQECEAEBAQoLCQgoIwyCNSQBDkshCDMBAQEBAQEBAQEBAQEBAQEBAQEXAkMBE?= =?us-ascii?q?gIYAQEBBDoGHxoBCwICAgEIEQQBAQEKFAkHFhwUCQgBAQQBDQUIg0UBgVYBDql?= =?us-ascii?q?QgnaFToJAAwUFhyR8gVU+gQ+CDH+DEQEBAwGBKQELBwEhBTGCeIIkhxcIkQ0DB?= =?us-ascii?q?QKFY26BZIdLg2CHTYdBggWGXwIEAgQFAhSBJSMIgQtxcIMDAQ+CLhppAQeCQ4U?= =?us-ascii?q?UhT5vjncPF4EIgRgBAQ?= X-IPAS-Result: =?us-ascii?q?A2F7AABJrfFah8mZ6ERcGgEBAQEBAgEBAQEIAQEBAYJvJQR?= =?us-ascii?q?+DnooCphbgXmBD5MoFIEpOwslCYQ+AoJmITYWAQIBAQEBAQECAQECEAEBAQoLC?= =?us-ascii?q?QgoIwyCNSQBDkshCDMBAQEBAQEBAQEBAQEBAQEBAQEXAkMBEgIYAQEBBDoGHxo?= =?us-ascii?q?BCwICAgEIEQQBAQEKFAkHFhwUCQgBAQQBDQUIg0UBgVYBDqlQgnaFToJAAwUFh?= =?us-ascii?q?yR8gVU+gQ+CDH+DEQEBAwGBKQELBwEhBTGCeIIkhxcIkQ0DBQKFY26BZIdLg2C?= =?us-ascii?q?HTYdBggWGXwIEAgQFAhSBJSMIgQtxcIMDAQ+CLhppAQeCQ4UUhT5vjncPF4EIg?= =?us-ascii?q?RgBAQ?= Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 08:54:15 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 20:00:37 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w48E4jDS020407 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 May 2018 10:04:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com w48E4jDS020407 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1525788287; bh=N/3tlEL+vWiPiXdrkK9fGzu0SeE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NuA5NgGnRjztRi6yFufci8ipzWvk7nxlGr+IiMl1/8biRcc9o2lgKY/w8wRhzlE+H Y9Dzlsr6lQPvYArq+JrXl/YRIp76p17ZJ9sX056H2xBxmSSaGohJvE6O/2OyagLyQ4 erok10GZnZsgc7LpJqzMqycstd6gLaA8uq+4SH0Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com w48E4jDS020407 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 8 May 2018 10:04:12 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w48E4WAc019598 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 8 May 2018 10:04:32 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0382.000; Tue, 8 May 2018 10:04:31 -0400 To: Alexander Vainshtein , "Mikael Abrahamsson" CC: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmrhr3aWKmiaf9TbeUMDqszKs2hwAJxA2g Date: Tue, 8 May 2018 14:04:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:04:52 -0000 >From the draft writeup (at https://datatracker.ietf.org/doc/draft-ietf-tsvw= g-iana-dscp-registry/shepherdwriteup/): The Transport Area WG (tsvwg) is in the process of updating the RFC 3662 specification of the Diffserv Lower Effort (LE) PHB/PDB, which provides a less than best effort or scavenger forwarding behavior. This update includes assignment of a new default Diffserv Codepoint (DSCP) to replace use of the CS1 DSCP (001000) for that purpose. The IANA registration policy for part of the IANA DSCP registry has to be changed in order to make that assignment; this draft makes that necessary IANA registration policy change. The number of possible DSCPs for the LE PHB is surprisingly limited: - The three most significant bits have to be '000' to accommodate legacy (non-Diffserv) routers whose forwarding behavior is based upon only those three bits, the former IP Precedence field - The least significant bit must be '1' in order to avoid priority inversion that could result from legacy router zeroing of the former IP Precedence field in a DSCP that is intended to provide better than best effort forwarding. That IP Precedence zeroing behavior has been observed in the Internet. This requirement excludes DSCP Pool 1 (xxxxx0) values. - DSCP values whose two least significant bits are '11' are not available because DSCP Pool 2 (xxxx11) values have been reserved for Experimental or Local Use. The only remaining DSCPs that could be assigned to the LE PHB are 000001 and 000101, both of which are in DSCP Pool 3 (xxxx01). Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander > Vainshtein > Sent: Tuesday, May 8, 2018 5:26 AM > To: Mikael Abrahamsson > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana= - > dscp-registry-04 >=20 > Mikael, > Lots of thanks for a prompt response. >=20 > Your objective makes sense to me, but it does not appear in the draft in = any > form. >=20 >=20 >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 >=20 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, May 8, 2018 12:14 PM > To: Alexander Vainshtein > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana= - > dscp-registry-04 >=20 > On Tue, 8 May 2018, Alexander Vainshtein wrote: >=20 > > Godred and all, > > I have looked up the draft iana-dscp-registry-04>, and I have doubts regarding validity of its motiv= ation. > > The draft says - correctly -that 22 out of 32 values in Pool 1 of the D= SCP > code points have been already assigned, therefore it considers this pool = as > nearly exhausted. > > > > What the draft does not say that, out of these 22 assignments, 2o have > been done in 1998 and one - in 1999. Only one assignment has been > requested in the past 19 years, and no assignments have been requested > after 2010. > > > > At this rate my estimate is that Pool 1 would suffice for the next 50+ = years > without its exhaustion becoming an issue. So why should the IETF do > anything now? >=20 > The primary reason for this is not because pool 1 is becoming exhausted, = but > the fact that we want to use 000001 for LE (for practical/legacy reasons,= not > because pool 1 is becoming exhausted), so the suggestion is therefore to > make Pool 3 have a different allocation policy so we can put in a standar= ds > track PHB LE RFC for 000001. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > __________________________________________________________ > _________________ >=20 > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > __________________________________________________________ > _________________ From nobody Tue May 8 07:08:08 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0D612E897 for ; Tue, 8 May 2018 07:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 9UNPvo_7B2xf for ; Tue, 8 May 2018 07:08:04 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.3]) (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 CF6D9124D68 for ; Tue, 8 May 2018 07:08:03 -0700 (PDT) Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-a.eu-central-1.aws.symcld.net id F2/C5-12287-14FA1FA5; Tue, 08 May 2018 14:08:01 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/fezevyyp1a/hQNXNJLt1yGWlJ Yf4REVCQRWKLXedsGc9rdJJVAI7DyQab4aAmbsixfFcuGmYgZmEkvzIQsM8vCV5pK2EOke3eX 1fnrc873+/t9zzn8SNynWRpIstlmljMyBoVURmzf/D1UGXdrLjHi2nV1zFTBVRQzX1oliemZH pbG4fHFC+NYvN3+A4u31bbhh/FEid6YmpGdItE5yyxYZoNftuXWa498VCIvRDKSoAtwcFyeIo SND23BoG9xRlKIPPnNKIIOxwaBpfQucDQNSwX2o7dCfl0xEhinj0L3dBshsC99HKZL7mKi5wQ 4zw0gkXfCy8pyl4egQ2HyxlNXH4pOgZKPNbgYXIpgZLDFVexJx8L8zLyHwIheC4t9zZgY5g9D Y1YXA02DveM5LvIamPi4LBH9qTDyqRaJ5yFQ/a7GQ+Rg6LcWISEMaCf/yotX3cVK+FpRwTPJ8 3poHU8SPYMInrfecXvCofrsJTdnwM3GfHdAEnwZ6ZSIvA4aS0YJsbgCh1dPHrkLgqBmuNMtvJ fA58pnmPi/GuitWSBKkcryz+tEDgfb/XmpyGFQXzuFW1xfJofHV8YIGyIa0Y5UTq/VmdMZvUG pjohQqtWRym1KdXS0islVMio2S6lhjWaO4VUVc9qkMuWkawxpKiNrdiB+ilbxqw2N9Gi6UQCJ KdZQAY1ziT7eqRlpOTrGpEvmsgysqRsFkaQCqNstvCbnWC2bfVJv4Efxjwykl8KP6hVkypTJp Jv0WlHqQyGB/lTRTV6gBUGXZVwp+zPE/Sg40JdC/EV8vDJZLl1v/l+fRP4kUvhSp4QuXnqjea X7JB+M8cHy97NCsJn5KwXmI1uT94EnYWWyvAf+xZtWe1Z+yLXakrN6SpdzClIqZ/0ODtiLNlF 6e1d5+227xrl0fvevn7HaoTptxYW3lrvHz0xURdXuv+dsPZKw0MB9COuqH22OlGYew73faEMf FoRKM2KT8tr3TiR471tqi9oTJbMePPSCkEu4wxu/1c9ZMV8PBWHSMeotOGdifgOSJNtNvwMAA A== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-33.tower-228.messagelabs.com!1525788477!543027!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 31548 invoked from network); 8 May 2018 14:08:00 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-33.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 May 2018 14:08:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eR4plznbuI36DfxXP+LyfOfe83akKVBt9wt7wJerjGs=; b=FZkJhttrWUoYP3qBoBdAafB5x/PLshcCJ/8KFmUbwgxwvF4t1f4vOjQTbXtvxNmxMjQjjtn3INxqzz7ba3wmcNot5WChVWHEGYf6Twshs/wRDtxk7iky7N2jboYf2Epj2diqt1i6b04+r/5mx/LMUVZkf4UyBGlESkwqlS8YDWU= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.18; Tue, 8 May 2018 14:07:50 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909%14]) with mapi id 15.20.0735.019; Tue, 8 May 2018 14:07:50 +0000 From: Alexander Vainshtein To: "Bless, Roland (TM)" CC: "tsvwg@ietf.org" , "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hwADjKcAAAmz/VA= Date: Tue, 8 May 2018 14:07:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1909; 7:2oOqggrLzqdEE7U5Xha7npN15Go82zipGgGbrDEVLdfkrecr7+LLtpX2DGQ5BWExVRbJLipFB+Nxa13M+kBi5Gym9kRjRWkk+YYhY3cxHNzpRa/eqREI1N0HcKpSvgyvLZNVcGexFnQDXE6ISHQV29efndHie7yOhjz6ePZ2lh/5/dyFyfSfD7cIZRJkABJkHyNpG+Qp4I1yDhgMamQMvshuH/BvYTZI0HFwJ6Rw1+O0H2LispQWqwbXKjjgDqi+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1909; x-ms-traffictypediagnostic: DB5PR0301MB1909: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(130329453890623)(279101305709854); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201703061421075)(201703161042150)(20161123562045)(6072148)(201708071742011); SRVR:DB5PR0301MB1909; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1909; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(252514010)(13464003)(199004)(189003)(76176011)(14454004)(54906003)(74316002)(33656002)(2900100001)(3280700002)(66066001)(6116002)(3846002)(7696005)(7736002)(6436002)(2906002)(53936002)(53546011)(6506007)(59450400001)(25786009)(97736004)(55016002)(305945005)(6306002)(68736007)(102836004)(26005)(4326008)(105586002)(81166006)(81156014)(186003)(5660300001)(72206003)(446003)(229853002)(8936002)(6246003)(476003)(8676002)(11346002)(2171002)(3660700001)(106356001)(498600001)(99286004)(86362001)(6916009)(9686003)(486006)(5250100002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1909; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kfeM+vvs3fwRMjAkNonPiWrTofzjoRf3UWRMwnk9LV7LM9DoRaX2CoaRAo0lryJWDUzzC2gA6Md/i1e5x/G8d7945I9IE/3uDgjlKuwHW+ipapilZ5q3/oodFGJrWjv5zcz446uBCCTPwppuoVUu/hKXdqTQjVBtTROC32NvBQlVNeu8ppCAriZ94gDVU6z0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c8d25591-46f1-4435-0fad-08d5b4ed1565 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8d25591-46f1-4435-0fad-08d5b4ed1565 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 14:07:50.1517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1909 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:08:06 -0000 Ronald, Lots of thanks for a prompt response. I have to admit that your explanation looks problematic to me. It provides a workaround for the IP precedence bleaching for LE traffic th= at you want to introduce - but what about all other PHBs? Would they not require some intelligent rewrite of the DSCP when traffic e= nters the bleaching domain? And if so, why should not the same approach be used for LE in this domain?= Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Bless, Roland (TM) [mailto:roland.bless@kit.edu]=20 Sent: Tuesday, May 8, 2018 12:26 PM To: Alexander Vainshtein ; gorry@erg.abd= n.ac.uk Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 Hi Sasha, Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: > I have looked up the draft > , > and I have doubts regarding validity of its motivation. >=20 > The draft says - correctly -that 22 out of 32 values in Pool 1 of the=20= > DSCP code points have been already assigned, therefore it considers=20 > this pool as nearly exhausted. >=20 > What the draft does not say that, out of these 22 assignments, 2o have=20= > been done in 1998 and one - in 1999. Only one assignment has been=20 > requested in the past 19 years, and no assignments have been requested=20= > after 2010. > At this rate my estimate is that Pool 1 would suffice for the next 50+=20= > years without its exhaustion becoming an issue. So why should the IETF=20= > do anything */now/*? This is motivated in section 1: The rationale for this update is a need to assign codepoints for particular PHBs that are unable to use any of the unassigned values in Pool 1. This problem is caused by implementations that do IP precedence bleaching = (i.e., zeroing the top three bits of the DSCP) thereby rewriting (or unint= entionally mapping) DSCP values to other DSCP values. This is a problem fo= r the mentioned LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg-le= -phb It is possible that some other standardized DSCPs get mapped to the LE PHB= DSCP if the LE DSCP were taken from the DSCP standards action pool 1 (xxx= xx0). There are measurements and more background material for this: https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31= measurements-concerning-the-dscp-for-a-le-phb-00 https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf Regards, Roland __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Tue May 8 07:49:25 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20742124D37 for ; Tue, 8 May 2018 07:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=l/lLvtmZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=wjWdzLNd 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 S0TKeo2Q3bMB for ; Tue, 8 May 2018 07:49:21 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 1B889124235 for ; Tue, 8 May 2018 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1525790960; x=1557326960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=snB3tKRrOYWw05a8FwQ5Aw9Y1nF7udQ2SwP7uCEIiSA=; b=l/lLvtmZ2WNVWJ/1TlKA/2AW6k18qlQWytCWVzQeeATOUUSOQwx/4JYJ K26rlqLij12PlqTcFMh1YFAt90hJbnwEt5ShVXrjPYnZg44gteE4/CuDT X+kVtKHJ/p4EspqWc8fdihDOcD7IN7EGb90E/794IjE7m1XccwXMCs4nv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F7AACWt/Fahz+a6ERcDgwBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCbyl+DnooCphbgXmBD5M8gSk7CyMLhD4CgmYhNxUBAgEBAQEBAQI?= =?us-ascii?q?BAQIQAQEBCgsJCCgjDII1JAEOLxwhCAYBAQEBAQEnAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFwJDARICGAEBAQIBAToGHxoBBAcCAgIBCBEEAQELFAkHFhwUCQgBAQQOBQi?= =?us-ascii?q?DRQGBTggBDqlSgnaFTIJAAwUFhyR8gVU+gQ+CDH+DEQEBAQJbTwESASEFMYJ4g?= =?us-ascii?q?iSHFwiRDQMFAoVjbokvg2CHTYdBggWGXwIEAgQFAhSBJTKBBHFwgxOCLhppAQe?= =?us-ascii?q?CQ4UUhQQ6bwGPBYEfgRgBAQ?= X-IPAS-Result: =?us-ascii?q?A2F7AACWt/Fahz+a6ERcDgwBAQEBAQIBAQEBCAEBAQGCbyl?= =?us-ascii?q?+DnooCphbgXmBD5M8gSk7CyMLhD4CgmYhNxUBAgEBAQEBAQIBAQIQAQEBCgsJC?= =?us-ascii?q?CgjDII1JAEOLxwhCAYBAQEBAQEnAQEBAQEBAQEBAQEBAQEBAQEBFwJDARICGAE?= =?us-ascii?q?BAQIBAToGHxoBBAcCAgIBCBEEAQELFAkHFhwUCQgBAQQOBQiDRQGBTggBDqlSg?= =?us-ascii?q?naFTIJAAwUFhyR8gVU+gQ+CDH+DEQEBAQJbTwESASEFMYJ4giSHFwiRDQMFAoV?= =?us-ascii?q?jbokvg2CHTYdBggWGXwIEAgQFAhSBJTKBBHFwgxOCLhppAQeCQ4UUhQQ6bwGPB?= =?us-ascii?q?YEfgRgBAQ?= Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 09:49:18 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 20:49:01 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w48EnAAv024353 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 May 2018 10:49:16 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w48EnAAv024353 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1525790956; bh=RMTDvhY4b+6/fpL2PhKEibA9+TY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wjWdzLNd14XlQqO+iW2QKeiZKDSP9z+YdGUGO0yqhVDBCP5QvybqGg/hm72asNig6 bX4iP4haar99Sgkmbi0KstwTzjwop8+DU2q+OpAqD/61QVJGbWhh4Clo6lRjEqjuXO W7/EmfRXtyfUh2PTalADtI0rUnV8L5p0aYdV8DuE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com w48EnAAv024353 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 8 May 2018 10:48:46 -0400 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w48EiJWc019802 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 8 May 2018 10:49:05 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0382.000; Tue, 8 May 2018 10:46:22 -0400 To: Alexander Vainshtein , "Bless, Roland (TM)" CC: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hwAL7mwAAAnbXQAAB3rSMA== Date: Tue, 8 May 2018 14:46:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.21.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:49:24 -0000 Writing as an individual, not WG chair ... > It provides a workaround for the IP precedence bleaching for LE traffic t= hat > you want to introduce - but what about all other PHBs? The concern is not about what happens in Diffserv domains/regions that are = updated to implement support for the new LE PHB, but what happens when that= LE PHB traffic transits through routers elsewhere that bleach IP Precedenc= e. Right now IP Precedence bleaching tends to result in best effort service, w= hich is ok, albeit not ideal. If IP Precedence bleaching could result in = a DSCP for the LE PHB, the result downstream of the bleaching could be wors= e than best effort service for a DSCP that was intended to obtain better th= an best effort service - that is the priority inversion that we're trying t= o avoid. > Would they not require some intelligent rewrite of the DSCP when traffic > enters the bleaching domain? Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching alre= ady violates a bunch of RFCs, dating back to RFC 2474. We can write what= we like in a new RFC, but that "running code" in deployed routers isn't go= ing to magically stop bleaching IP Precedence just because we publish a new= RFC. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander > Vainshtein > Sent: Tuesday, May 8, 2018 10:08 AM > To: Bless, Roland (TM) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana= - > dscp-registry-04 >=20 > Ronald, > Lots of thanks for a prompt response. >=20 > I have to admit that your explanation looks problematic to me. > It provides a workaround for the IP precedence bleaching for LE traffic t= hat > you want to introduce - but what about all other PHBs? > Would they not require some intelligent rewrite of the DSCP when traffic > enters the bleaching domain? > And if so, why should not the same approach be used for LE in this domain= ? >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 >=20 > -----Original Message----- > From: Bless, Roland (TM) [mailto:roland.bless@kit.edu] > Sent: Tuesday, May 8, 2018 12:26 PM > To: Alexander Vainshtein ; > gorry@erg.abdn.ac.uk > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana= - > dscp-registry-04 >=20 > Hi Sasha, >=20 > Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: > > I have looked up the draft > > , > > and I have doubts regarding validity of its motivation. > > > > The draft says - correctly -that 22 out of 32 values in Pool 1 of the > > DSCP code points have been already assigned, therefore it considers > > this pool as nearly exhausted. > > > > What the draft does not say that, out of these 22 assignments, 2o have > > been done in 1998 and one - in 1999. Only one assignment has been > > requested in the past 19 years, and no assignments have been requested > > after 2010. >=20 > > At this rate my estimate is that Pool 1 would suffice for the next 50+ > > years without its exhaustion becoming an issue. So why should the IETF > > do anything */now/*? >=20 > This is motivated in section 1: >=20 > The rationale for this update is a need > to assign codepoints for particular PHBs that are unable to use any > of the unassigned values in Pool 1. >=20 > This problem is caused by implementations that do IP precedence bleaching > (i.e., zeroing the top three bits of the DSCP) thereby rewriting (or > unintentionally mapping) DSCP values to other DSCP values. This is a prob= lem > for the mentioned LE PHB I-D https://tools.ietf.org/html/draft-ietf-tsvwg= -le- > phb > It is possible that some other standardized DSCPs get mapped to the LE PH= B > DSCP if the LE DSCP were taken from the DSCP standards action pool 1 > (xxxxx0). >=20 > There are measurements and more background material for this: > https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb- > 31measurements-concerning-the-dscp-for-a-le-phb-00 > https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf >=20 > Regards, > Roland >=20 > __________________________________________________________ > _________________ >=20 > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > __________________________________________________________ > _________________ From nobody Tue May 8 07:55:44 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE85C124D37 for ; Tue, 8 May 2018 07:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 AwaB6WTx2AVf for ; Tue, 8 May 2018 07:55:40 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.5]) (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 E56581243F3 for ; Tue, 8 May 2018 07:55:39 -0700 (PDT) Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.eu-central-1.aws.symcld.net id 20/5E-11732-96AB1FA5; Tue, 08 May 2018 14:55:37 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSWUwTURT1zUzLYBjzKGAvDbhUPtxaKRpTPow ajcEYjfHHBESZ4kgb2kJmBi0mJg3uIMagaKlFKNQNjUSEgmjUuCAYDUtIo0ZUIhrFFYhRTFxm OnWbj5fz7jnnnncnlyY1rWodzblEjneydr16IrVg1tcUg619JDO19GmyecRbT5nf7jmOzKOHj qnMHe8G1EuojIoqD5lxYOw1kREIjBMZtf42ci2VqbI5LQWuHJW16sIdVDgwx1V24gHlRp0ppW giTeE9JPg+NankiwZ7COipfkgql0EE3/c+I0pRNK3Gi6Dp3IC6FNF0PJ4Fg9XLZQ2JSxB4W8q jZE0czoJ35S1hfTzeAMGd/UjBK+BD0BOuUzgF9h3+TMmYwTnQdvEnoYSdJaDe10PKRDReA4/H W8NNEZ4MX+6dD5tJrIXHQzVhDBhD4Go3qeAEePPih0rRW+DZSz9S6tPB89QXpeBk6KspQ3IY4 CABr0q61QphgE+VlaQ8GeAZ0Pw6W9GEpMlCoYh5LvjrLkWaFkDd9eZI3QH7S05EHjQFGsoHqU gACR0VdyOGJPANXIsQATWc8vvDbg3OhU7fGHUIGb3/TKfguVB7ZVSt4DmS5S3pDf+yWOiqGqJ qEdWA0i28Lc8qOlib3WBKTTWYTPMN0rlwgZHdbmCNXJEhl3OKPCuxRnabYBSKHbn2zUYnJzYh aaEmSF8bCr3PvYkSaUKfwCQ2jGRqJlkKNhdbWcG6iS+yc8JNlETTemD4yxIXy3N5nGuLzS5t5 W8a6Bh9PFPfKtGMUMg6BFueQt1D03VaxiP7sExYi5x/bL/3uQ8l6+IYJD1EE1PI8Q6b+D8/jL Q00scxl+UuMTan+Kf7sBRMSMGxzz/KwSL7l9K50e0RU2330vNbVvU+X3xNu9q70ZJ29Emwrj2 WP8jc6spanN9orl9/RFx6Zse0S41bT/afTlkVnGJw7vz5oqdyavXx1M/Nu9uz15WFKub37kdC 167salf/juDt0RXl+fPW3hfTdVeKH+22d7y6kfZtmXvmnbSk4ehGN7dyfVSnz/doQiBLTwlW1 jSb5AX2F+Vr64/KAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-23.tower-228.messagelabs.com!1525791334!545159!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 18107 invoked from network); 8 May 2018 14:55:36 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-23.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 May 2018 14:55:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5zYzzNxCrURukEoQyJI00UnpeoVgSEqXzDR+HszaT3w=; b=XB3KBHWlgGNNHkAmmtknDB6PifoNw4zs5aiRF00KkZDgfoAYvU5VodUU9CuEUJb4mhokXLWvx6avIRqBWqeTu0Z3Q29ujY++oYWpVbWh6nsb7ozRG4TfRffivxmWvjKIkFPpJOi2mtnKujaWkGFAh1WWu2vz/QikTn7upEPPnXY= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1992.eurprd03.prod.outlook.com (10.167.227.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.18; Tue, 8 May 2018 14:55:32 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909%14]) with mapi id 15.20.0735.019; Tue, 8 May 2018 14:55:32 +0000 From: Alexander Vainshtein To: "Black, David" CC: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "Bless, Roland (TM)" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hwADjKcAAAmz/VAAAX/kAAAAL+oA Date: Tue, 8 May 2018 14:55:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1992; 7:uufHRd3ufozq1+GiF0BWu3wlH6fNkB52tvlloN0v7OpIgN5QU/UUzaglobzypUSpiLbzor+wI9cokUxWghpZiaapGW3crGZr13YStdPUFfORMZkQrAFDSQ74DLtjIRqC6finztnOm7AJzD2oppxc+waln+dYYCOFU/HBaqZ7Hm83+/ZEbbrAjNPxVyJl5H2/VdNAOkbu1ISoCgf0V0BGCQvfiRYP+S4jpP0Vc3cuYaeACWgzaNn9tSZWj0IMAuqw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1992; x-ms-traffictypediagnostic: DB5PR0301MB1992: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(130329453890623)(279101305709854)(56004941905204); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DB5PR0301MB1992; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1992; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(346002)(39380400002)(376002)(366004)(396003)(199004)(13464003)(189003)(252514010)(476003)(59450400001)(2900100001)(316002)(3660700001)(5660300001)(99286004)(7696005)(446003)(11346002)(2906002)(478600001)(72206003)(966005)(3280700002)(54906003)(4326008)(486006)(33656002)(14454004)(76176011)(25786009)(26005)(8676002)(55016002)(66066001)(8666007)(102836004)(6916009)(8936002)(9686003)(53936002)(6306002)(68736007)(7736002)(6116002)(3846002)(305945005)(81156014)(97736004)(105586002)(93886005)(53546011)(86362001)(6246003)(6506007)(6436002)(106356001)(74316002)(186003)(229853002)(5250100002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1992; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RfILTXywkzrDWtKKOfGpQDRgpresDoGbq8dIi5KV1dQjTTxANKXxfhDms+a7v3hQpzRw/FgkKCDorID/umpH/AZt/q7guCxR6U8e7lm72H1n9IVI6Nk3pI21eTnyRi4/CLD3rgV44ryeQ2CYGagHypkdIPWE+8jq8+/l9jJMdkY8oJcGMu1f0wOE1xuBvjMK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bf32e2c6-ca51-4ed7-5f80-08d5b4f3bf6a X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf32e2c6-ca51-4ed7-5f80-08d5b4f3bf6a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 14:55:32.3796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1992 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 14:55:43 -0000 David, Lots of thanks for a very detailed explanation. Coming back to my original doubt, , changing the IANA allocation policy on= Pool 3 (16 values) in order to make just one value standard still looks a= n exaggeration to me.=20 What are we going to do with the remaining 15 values?=20 Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Black, David [mailto:David.Black@dell.com]=20 Sent: Tuesday, May 8, 2018 5:46 PM To: Alexander Vainshtein ; Bless, Roland= (TM) Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org Subject: RE: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 Writing as an individual, not WG chair ... > It provides a workaround for the IP precedence bleaching for LE=20 > traffic that you want to introduce - but what about all other PHBs? The concern is not about what happens in Diffserv domains/regions that are= updated to implement support for the new LE PHB, but what happens when th= at LE PHB traffic transits through routers elsewhere that bleach IP Preced= ence. Right now IP Precedence bleaching tends to result in best effort service, = which is ok, albeit not ideal. If IP Precedence bleaching could result i= n a DSCP for the LE PHB, the result downstream of the bleaching could be w= orse than best effort service for a DSCP that was intended to obtain bette= r than best effort service - that is the priority inversion that we're try= ing to avoid. > Would they not require some intelligent rewrite of the DSCP when=20 > traffic enters the bleaching domain? Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching alr= eady violates a bunch of RFCs, dating back to RFC 2474. We can write wh= at we like in a new RFC, but that "running code" in deployed routers isn't= going to magically stop bleaching IP Precedence just because we publish a= new RFC. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander=20 > Vainshtein > Sent: Tuesday, May 8, 2018 10:08 AM > To: Bless, Roland (TM) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] Doubts regarding motivation of=20 > draft-ietf-tsvwg-iana- > dscp-registry-04 >=20 > Ronald, > Lots of thanks for a prompt response. >=20 > I have to admit that your explanation looks problematic to me. > It provides a workaround for the IP precedence bleaching for LE=20 > traffic that you want to introduce - but what about all other PHBs? > Would they not require some intelligent rewrite of the DSCP when=20 > traffic enters the bleaching domain? > And if so, why should not the same approach be used for LE in this domai= n? >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 >=20 > -----Original Message----- > From: Bless, Roland (TM) [mailto:roland.bless@kit.edu] > Sent: Tuesday, May 8, 2018 12:26 PM > To: Alexander Vainshtein ; > gorry@erg.abdn.ac.uk > Cc:=20tsvwg@ietf.org > Subject: Re: [tsvwg] Doubts regarding motivation of=20 > draft-ietf-tsvwg-iana- > dscp-registry-04 >=20 > Hi Sasha, >=20 > Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: > > I have looked up the draft > > > > , and I have doubts regarding validity of its motivation. > > > > The draft says - correctly -that 22 out of 32 values in Pool 1 of=20 > > the DSCP code points have been already assigned, therefore it=20 > > considers this pool as nearly exhausted. > > > > What the draft does not say that, out of these 22 assignments, 2o=20 > > have been done in 1998 and one - in 1999. Only one assignment has=20 > > been requested in the past 19 years, and no assignments have been=20 > > requested after 2010. >=20 > > At this rate my estimate is that Pool 1 would suffice for the next=20 > > 50+ years without its exhaustion becoming an issue. So why should=20 > > the IETF do anything */now/*? >=20 > This is motivated in section 1: >=20 > The rationale for this update is a need > to assign codepoints for particular PHBs that are unable to use any > of the unassigned values in Pool 1. >=20 > This problem is caused by implementations that do IP precedence=20 > bleaching (i.e., zeroing the top three bits of the DSCP) thereby=20 > rewriting (or unintentionally mapping) DSCP values to other DSCP=20 > values. This is a problem for the mentioned LE PHB I-D=20 > https://tools.ietf.org/html/draft-ietf-tsvwg-le- > phb > It is possible that some other standardized DSCPs get mapped to the LE=20= > PHB DSCP if the LE DSCP were taken from the DSCP standards action pool=20= > 1 (xxxxx0). >=20 > There are measurements and more background material for this: > https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sess > b- > 31measurements-concerning-the-dscp-for-a-le-phb-00 > https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf >=20 > Regards, > Roland >=20 > __________________________________________________________ > _________________ >=20 > This e-mail message is=20intended for the recipient only and contains=20= > information which is CONFIDENTIAL and which may be proprietary to ECI=20= > Telecom. If you have received this transmission in error, please=20 > inform us by e-mail, phone or fax, and then delete the original and=20 > all copies thereof. > __________________________________________________________ > _________________ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Tue May 8 10:23:00 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22286127077 for ; Tue, 8 May 2018 10:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ5CnxvpTV-e for ; Tue, 8 May 2018 10:22:57 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9980A12D877 for ; Tue, 8 May 2018 10:22:57 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f21-v6so39344595iob.13 for ; Tue, 08 May 2018 10:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=udbU4Tu8eNTD9pUE+D4oqPMBOUPNaX5p6PK274lxNUI=; b=fC2hswrcejc81M+i3M7TgqfY/Q+AS4Lz61gX36VIGW/+xoOlOw+of5Cqf28fuBSjEq PxSJml9ByYgkr3uaFMRf/qIOaT47vVYTfKGlxhqB4R6qyjsoLLCkRWLF1UrkogYUWPSY y+iCek/9aIE0nyhStIgzcK7zycRbubb9kz/Ny/DLerd3nfrjXxg0aZ8kDEbi1Kf6ovnv e3pCvbE040QVYn/aZcbX/h3e0/krhBvZ/X6YENJaEliUVL0TcYqbXp/guLso2+RYvp+t QajsRAhH2kBnZfI67k8ac+AEobW7LNIHXRupSrpm0fXIdaxXQDGVLXMzNE2eDglSCDAf NiGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=udbU4Tu8eNTD9pUE+D4oqPMBOUPNaX5p6PK274lxNUI=; b=qisWP2X7lISAJcdX1wKwg75/GyOjU2zgaIJh9wVMbZ3E3tUMd5lPqdAM8uEcQsa2wD 3uYcxAoqeBKA02Qc51tNe507wNd7iBmF2w+UAhSvr509RAcBo71/UyWclJXuhQRmR9tX sPXQst8wOqqevhxe2xmfQ/GGGGjh5b7Z7KHGSCEeMqu4aVyRe9csfazDjyl5AkJw94Wx t+miWNVd+u5P3ZyWqVa1Wf99OLpYWYCqkKxGZdFhRLKJkCn0v48FIRGgwOMaGmiXECz1 LOozud4+H6kYWudStNuyBMFwA8mVMFqKBYWiHY9M6ax9+kLuvtBokKjxKQJV25aYhoJj OD7Q== X-Gm-Message-State: ALQs6tD2SP0n5gM35OrM1WHeDe2bX0T15ajk3zlLMfR4WmZ5RPldTnH7 Mn9RhowMwLAy3AYTKBkPmmaBmMTfDp1LR5MvFceN6g== X-Google-Smtp-Source: AB8JxZo1gcBV5kBDzTJUQ8vCf9P1u8qKOu7b/B45jCZx2Jv+Zfl+MBcnMGTGTb6h8MLKjaKoEXvNlJK22bLIszxNfu4= X-Received: by 2002:a6b:9a05:: with SMTP id c5-v6mr37374489ioe.142.1525800176894; Tue, 08 May 2018 10:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.188.19 with HTTP; Tue, 8 May 2018 10:22:16 -0700 (PDT) From: Kathleen Moriarty Date: Tue, 8 May 2018 13:22:16 -0400 Message-ID: To: tsvwg@ietf.org, Gorry Fairhurst , Colin Perkins Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:22:59 -0000 Hello Gorry & Colin, Thanks for your work on this draft. In my opinion, it is very important to dig through the implications of encrypting transport headers. The document is well written and easy to read, thanks for that as well. Al and I had a hard time with that since ours was contribution driven and controversial. Here's some feedback from my review that I hope you find helpful: General: If you added section references to mm-wg-encrypt where it is referenced, that may be helpful to the reader. Specific feedback: The apps side will object to this phrasing as they don't see the need for any 'help'. I agree with your point, just warning of the obstacle in case you can reword it to prevent objections. Choosing to encrypt all information may reduce the ability for networks to "help" (e.g., in response to tracing issues, making appropriate QoS decisions). Section 3 intro text Encrypted traffic can also be profiled to identify threat actors. This will continue to be important as threat actors may have advanced capabilities and may modify the encrypted streams in identifiable ways that can differentiate their traffic from others. I was expecting to see some text toward the end of 3 on adoption of these protocols. We can put out protocols, but it's up to industry to decide when and where to adopt protocols. From a few recent talks, what I saw from the audiences is that those aware of QUIC are outright blocking it. The business imperative is not there for the applications using QUIC to justify it's use within the business network, at least not yet. Section 3.3 Do you want to make this specific to IPsec tunnel mode since that hides the true end points as well? Transport mode isn't well deployed because of interoperability issues and not current use case driving it's usage, but that does leave the true IP source and destination addresses exposed, more than what you see with tunnel mode. Section 5.3 This is starting to touch on NetNeutrality and if you are going to go there, you should state it explicitly. At the enterprise level (it doesn't seem like you are covering that in this draft), I am hearing QUIC is outright blocked by those that are aware of it on the network, so it's not just NetNeutrality that will impact it's deployment. Perhaps rephrasing may help? Here's the text I'm talking about: A lack of data reduces the level of precision with which mechanisms are applied, and this needs to be considered when evaluating the impact of designs for transport encryption. This could lead to increased use of rate limiting, circuit breaker techniques [RFC8084], or even blocking of uncharacterised traffic. This would hinder deployment of new mechanisms and/or protocols. Section 5.4 I think you have a typo here: Integrity checks can undetected modification of protocol fields by network devices, -- Best regards, Kathleen From nobody Tue May 8 11:49:03 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D54127869 for ; Tue, 8 May 2018 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0pjARewze84G for ; Tue, 8 May 2018 11:48:58 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id EFFF4127698 for ; Tue, 8 May 2018 11:48:57 -0700 (PDT) Received: from [192.168.0.3] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1B18F1B00056; Tue, 8 May 2018 19:48:57 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Gorry Fairhurst X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Tue, 8 May 2018 19:48:56 +0100 Cc: "Black, David" , "tsvwg@ietf.org" , "Bless, Roland (TM)" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alexander Vainshtein Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 18:49:02 -0000 Hi, Maybe I can provide a little more context about other unallocated values in t= he registry. Each request for a new DSCP needs to be considered carefully an= d separately looking at the implications on both the deployed use of Codepoi= nts and the needs for the PHB. As it happens, the unassigned DSCPs in pool 1= could well remain useful for any new PHBs- if any new ones are approved by T= SVWG that can be bleached to default (BE) - the case for most currently def= ined PHBs.=20 I expect the new pool will be only used by IANA requests from TSVWG when th= ere is a case for not using any of the remaining pool 1 values. That case ha= s been made for the LE PHB. There could potentially be other allocations in= the future, but that is none are currently considered. Gorry Sent from my iPad > On 8 May 2018, at 15:55, Alexander Vainshtein wrote: >=20 > David, > Lots of thanks for a very detailed explanation. >=20 > Coming back to my original doubt, , changing the IANA allocation policy on= Pool 3 (16 values) in order to make just one value standard still looks an e= xaggeration to me.=20 > What are we going to do with the remaining 15 values?=20 >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 >=20 > -----Original Message----- > From: Black, David [mailto:David.Black@dell.com]=20 > Sent: Tuesday, May 8, 2018 5:46 PM > To: Alexander Vainshtein ; Bless, Roland= (TM) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: RE: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 >=20 > Writing as an individual, not WG chair ... >=20 >> It provides a workaround for the IP precedence bleaching for LE=20 >> traffic that you want to introduce - but what about all other PHBs? >=20 > The concern is not about what happens in Diffserv domains/regions that are= updated to implement support for the new LE PHB, but what happens when that= LE PHB traffic transits through routers elsewhere that bleach IP Precedence= . >=20 > Right now IP Precedence bleaching tends to result in best effort service, w= hich is ok, albeit not ideal. If IP Precedence bleaching could result in a= DSCP for the LE PHB, the result downstream of the bleaching could be worse t= han best effort service for a DSCP that was intended to obtain better than b= est effort service - that is the priority inversion that we're trying to avo= id. >=20 >> Would they not require some intelligent rewrite of the DSCP when=20 >> traffic enters the bleaching domain? >=20 > Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching alr= eady violates a bunch of RFCs, dating back to RFC 2474. We can write what= we like in a new RFC, but that "running code" in deployed routers isn't goi= ng to magically stop bleaching IP Precedence just because we publish a new R= FC. >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander=20 >> Vainshtein >> Sent: Tuesday, May 8, 2018 10:08 AM >> To: Bless, Roland (TM) >> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org >> Subject: Re: [tsvwg] Doubts regarding motivation of=20 >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >>=20 >> Ronald, >> Lots of thanks for a prompt response. >>=20 >> I have to admit that your explanation looks problematic to me. >> It provides a workaround for the IP precedence bleaching for LE=20 >> traffic that you want to introduce - but what about all other PHBs? >> Would they not require some intelligent rewrite of the DSCP when=20 >> traffic enters the bleaching domain? >> And if so, why should not the same approach be used for LE in this domain= ? >>=20 >> Regards, >> Sasha >>=20 >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >>=20 >>=20 >> -----Original Message----- >> From: Bless, Roland (TM) [mailto:roland.bless@kit.edu] >> Sent: Tuesday, May 8, 2018 12:26 PM >> To: Alexander Vainshtein ; >> gorry@erg.abdn.ac.uk >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] Doubts regarding motivation of=20 >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >>=20 >> Hi Sasha, >>=20 >>> Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: >>> I have looked up the draft >>> >>> , and I have doubts regarding validity of its motivation. >>>=20 >>> The draft says - correctly -that 22 out of 32 values in Pool 1 of=20 >>> the DSCP code points have been already assigned, therefore it=20 >>> considers this pool as nearly exhausted. >>>=20 >>> What the draft does not say that, out of these 22 assignments, 2o=20 >>> have been done in 1998 and one - in 1999. Only one assignment has=20 >>> been requested in the past 19 years, and no assignments have been=20 >>> requested after 2010. >>=20 >>> At this rate my estimate is that Pool 1 would suffice for the next=20 >>> 50+ years without its exhaustion becoming an issue. So why should=20 >>> the IETF do anything */now/*? >>=20 >> This is motivated in section 1: >>=20 >> The rationale for this update is a need >> to assign codepoints for particular PHBs that are unable to use any >> of the unassigned values in Pool 1. >>=20 >> This problem is caused by implementations that do IP precedence=20 >> bleaching (i.e., zeroing the top three bits of the DSCP) thereby=20 >> rewriting (or unintentionally mapping) DSCP values to other DSCP=20 >> values. This is a problem for the mentioned LE PHB I-D=20 >> https://tools.ietf.org/html/draft-ietf-tsvwg-le- >> phb >> It is possible that some other standardized DSCPs get mapped to the LE=20= >> PHB DSCP if the LE DSCP were taken from the DSCP standards action pool=20= >> 1 (xxxxx0). >>=20 >> There are measurements and more background material for this: >> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sess >> b- >> 31measurements-concerning-the-dscp-for-a-le-phb-00 >> https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf >>=20 >> Regards, >> Roland >>=20 >> __________________________________________________________ >> _________________ >>=20 >> This e-mail message is intended for the recipient only and contains=20 >> information which is CONFIDENTIAL and which may be proprietary to ECI=20 >> Telecom. If you have received this transmission in error, please=20 >> inform us by e-mail, phone or fax, and then delete the original and=20 >> all copies thereof. >> __________________________________________________________ >> _________________ >=20 > __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 > transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original=20 > and all copies thereof. > __________________________________________________________________________= _ From nobody Tue May 8 12:42:35 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456F212E8AF for ; Tue, 8 May 2018 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 r36wqYiha6TR for ; Tue, 8 May 2018 12:42:30 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.109]) (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 ED10012D95B for ; Tue, 8 May 2018 12:42:29 -0700 (PDT) Received: from [193.109.254.3] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta-6.messagelabs.com id 31/84-18181-4ADF1FA5; Tue, 08 May 2018 19:42:28 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa0gUURj1zsyOozg1rqZfpkFbVJgraQ+EKCI L9kdlEUVqkbM6uRv70J01tgdkJVa6hT18Z77WQjMQUzMUia2kTHoRBqWu70wtX5EkJc3srD3u r3PPOXzn3MtH4fKPZADFWcycycDqFKQnsX5JnUVZ/msyZm2afVnEZEE5ETGaXogiprJyZRGtY 13kVkJ1LT8PV1mnhzGVzfYDU5WUNuJ7iBiZ1qA2WuJkmpzqQTKpNB1ZCgq7ZanIlpyBPCmCSc eh4tYTmXiRM3kY5F8fIjOQh3DpRXCjMlDEJLMZau92OXlfJhjen3+MixhnTsLsfYcT+zCxUD3 yDUmeQ9Bw/p2AKQEfAGuRUaQJZgXMTWc4LTQTB+8yX7lLufU4NNQ4MFHwYLbB9IM+50zE+MFM WzUmZfnDh4FiJwaGAVvzK1zCi+Bz/5xM8qvBMViKJF4BjZk9Lk8QvC3ORGIYMA0YnHV8lEmCE iays3GxKDDLoW74sOTpQFBZVERKnhBoutDjCjZCc+esK0APl87dcvFLoepyL+EKwOHhtUuugE C42dXiEmpJKK647y59bzw8uzlNZCFlwT+vk7ABrra34AXOb/KG5/kDhMSHQEnTFCnhNXC7dBS fx+2P+rF/+RLkXoVW85zpOGdShoeHqk3aRI1Zz2p1yrC1G0P1HM+ziZyOVfOh8UZ9LRJWzE04 jai6eK8dLaYwxSJ658RkjHyB2phwQsPymiOmFB3H21EgRSmATvgpaN4mLpGzHNXqhD2dl4HyU vjSu0WZ5pNYPa9NlKQ2tI56OX7DilNDtmwrLicMRgMX4E/rRSsjWjUphj+D5nf+LQoK8KGRUE 3ulcSZ9Frz//oI8qeQwoe+Ik7x0hrMf/JGhCqYUMW7Z1ysYmb/SgGpKLrm+/vlnrNP84NzxhS ZOzpbrR1LEqKYeuXmnTNn9Ec3+ZV9ajan702lZ2qbNF+644IuquxFjpAaIqVylce+vF13IM1+ b2jDlsiy/SuTGnyTYxPebOpPO8ZmP38x4WV28N/75kIPjnYeiu536/l2+vV2+MoNnYqMas312 BZiXNhaqCB4DRsWjJt49jfQ1Lxz7gMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-184.messagelabs.com!1525808544!136642391!1 X-Originating-IP: [52.27.180.120] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 26447 invoked from network); 8 May 2018 19:42:26 -0000 Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-11.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 May 2018 19:42:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sM9KCaL8XVqQzNC4m7Dsq0bjwRhdYarpGuloNcnb+0c=; b=eTdmR/iaPUGJq5GmkxGDG4fQIUhAHq1sXFQ3WM5z6n0luJRd1quZJ63RVYXNNfVfIe5G0KOc53OXYFq6XHdBlS9ARm5CamyJq37bYnyP2NhfQgsgCIUYDPcNe2BihcidyBHoq3guQcAQzLvXA606isylcUtsnRYL/atXd9Ht2Ik= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2120.eurprd03.prod.outlook.com (10.167.228.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.19; Tue, 8 May 2018 19:42:21 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909%14]) with mapi id 15.20.0735.019; Tue, 8 May 2018 19:42:21 +0000 From: Alexander Vainshtein To: Gorry Fairhurst CC: "Black, David" , "tsvwg@ietf.org" , "Bless, Roland (TM)" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hwADjKcAAAmz/VAAAX/kAAAAL+oAAAhIzQAAAd2OFw== Date: Tue, 8 May 2018 19:42:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.164.212.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB2120; 7:d9gbLz7b8u0DBc5bds4NQv4GZr/T7tul85Cj9c9cpNV1bViOteslkcmaDgk+aLFdmJITQ0JkwkvDvA2RyNik221b3uddb7hA1h3ZxPS1BCpsABOteyC5nCCkgXZOihuFo7H/WuEvT7wt392E/RnMPkL5kxDvozL1hOUJl+3nA9v2Br7dzcH++fLHkgKjy6XCBnP+qsFWv9EnAKuA1TCZfXHU/LoM7S+CcMkwpMjGAhH6Ovkf5l1MKYcWenvBkMdy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2120; x-ms-traffictypediagnostic: DB5PR0301MB2120: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(130329453890623)(279101305709854)(56004941905204); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DB5PR0301MB2120; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2120; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(39850400004)(366004)(346002)(396003)(252514010)(13464003)(189003)(199004)(54896002)(6916009)(7736002)(8676002)(6306002)(4326008)(76176011)(6246003)(106356001)(8666007)(6116002)(55016002)(229853002)(3846002)(9686003)(81156014)(33656002)(59450400001)(3660700001)(446003)(11346002)(2906002)(3280700002)(81166006)(6436002)(25786009)(486006)(53936002)(2900100001)(105586002)(99286004)(316002)(5660300001)(86362001)(97736004)(93886005)(14454004)(5250100002)(53546011)(72206003)(966005)(68736007)(7696005)(5003630100001)(6506007)(476003)(102836004)(66066001)(26005)(186003)(478600001)(74316002)(8936002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2120; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0v70Mcwh6M83OvOhesUa6PnXf8FwY2y2UEF+AY5RdSjJ1na9KJtzzhm1csjkCf2wq+v2qfLS3/lnMZoa/Gu5YD6ErFZ5OqRgzC+VlOMTMFnmrR0aoFQdZPrhJnHxfsKiQctscdlTbDi0zgPpJ5gJNTTNgVflKR3Vv0vz4dzoWGJ2E9QvnExtOIwaKRwlxsAk spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909DBAE4BD858DA2530781E9D9A0DB5PR0301MB1909_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1a2b2464-4ee5-4eb9-6efe-08d5b51bd09c X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a2b2464-4ee5-4eb9-6efe-08d5b51bd09c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 19:42:21.0981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2120 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 19:42:33 -0000 --_000_DB5PR0301MB1909DBAE4BD858DA2530781E9D9A0DB5PR0301MB1909_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gorry, Providing additional context including explicit description of bleaching o= f the IP Precedence bits would surely help. Thumb typed by Sasha Vainshtein From: Gorry Fairhurst Sent: Tuesday, May 8, 21:49 Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 To: Alexander Vainshtein Cc: Black, David, tsvwg@ietf.org, Bless, Roland (TM) Hi, Maybe I can provide a little more context about other unallocated valu= es in the registry. Each request for a new DSCP needs to be considered car= efully and separately looking at the implications on both the deployed use= of Codepoints and the needs for the PHB. As it happens, the unassigned DS= CPs in pool 1 could well remain useful for any new PHBs- if any new ones a= re approved by TSVWG that can be bleached to default (BE) - the case for m= ost currently defined PHBs. I expect the new pool will be only used by IAN= A requests from TSVWG when there is a case for not using any of the remain= ing pool 1 values. That case has been made for the LE PHB. There could pot= entially be other allocations in the future, but that is none are currentl= y considered. Gorry Sent from my iPad > On 8 May 2018, at 15:55, Alexander= Vainshtein wrote: > > David, > Lots of thanks for a very detailed explana= tion. > > Coming back to my original doubt, , changing the IANA allocation= policy on Pool 3 (16 values) in order to make just one value standard sti= ll looks an exaggeration to me. > What are we going to do with the remaini= ng 15 values? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-= 549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Me= ssage----- > From: Black, David [mailto:David.Black@dell.com] > Sent: Tues= day, May 8, 2018 5:46 PM > To: Alexander Vainshtein ; Bless, Roland (TM) >= Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: RE: [tsvwg] Doubts re= garding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 > > Writing a= s an individual, not WG chair ... > >> It provides a workaround for the IP= precedence bleaching for LE >> traffic that you want to introduce - but w= hat about all other PHBs? > > The concern is not about what happens in Dif= fserv domains/regions that are updated to implement support for the new LE= PHB, but what happens when that LE PHB traffic transits through routers e= lsewhere that bleach IP Precedence. > > Right now IP Precedence bleaching = tends to result in best effort service, which is ok, albeit not ideal. If = IP Precedence bleaching could result in a DSCP for the LE PHB, the result = downstream of the bleaching could be worse than best effort service for a = DSCP that was intended to obtain better than best effort service - that is= the priority inversion that we're trying to avoid. > >> Would they not re= quire some intelligent rewrite of the DSCP when >> traffic enters the blea= ching domain? > > Unfortunately, that's wishful thinking, IMHO. IP Precede= nce bleaching already violates a bunch of RFCs, dating back to RFC 2474. W= e can write what we like in a new RFC, but that "running code" in deployed= routers isn't going to magically stop bleaching IP Precedence just becaus= e we publish a new RFC. > > Thanks, --David > >> -----Original Message----= - >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander >>= Vainshtein >> Sent: Tuesday, May 8, 2018 10:08 AM >> To: Bless, Roland (T= M) >> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org >> Subject: Re: [tsvwg] Dou= bts regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 = >> >> Ronald, >> Lots of thanks for a prompt response. >> >> I have to adm= it that your explanation looks problematic to me. >> It provides a workaro= und for the IP precedence bleaching for LE >> traffic that you want to int= roduce - but what about all other PHBs? >> Would they not require some int= elligent rewrite of the DSCP when >> traffic enters the bleaching domain? = >> And if so, why should not the same approach be used for LE in this doma= in? >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-5492= 66302 >> Email: Alexander.Vainshtein@ecitele.com >> >> >> -----Original Me= ssage----- >> From: Bless, Roland (TM) [mailto:roland.bless@kit.edu] >> Se= nt: Tuesday, May 8, 2018 12:26 PM >> To: Alexander Vainshtein ; >> gorry@e= rg.abdn.ac.uk >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg] Doubts regardi= ng motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >> >> Hi Sa= sha, >> >>> Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: >>> I hav= e looked up the draft >>> >>> , and I have doubts regarding validity of it= s motivation. >>> >>> The draft says - correctly -that 22 out of 32 values= in Pool 1 of >>> the DSCP code points have been already assigned, therefo= re it >>> considers this pool as nearly exhausted. >>> >>> What the draft = does not say that, out of these 22 assignments, 2o >>> have been done in 1= 998 and one - in 1999. Only one assignment has >>> been requested in the p= ast 19 years, and no assignments have been >>> requested after 2010. >> >>= > At this rate my estimate is that Pool 1 would suffice for the next >>> 5= 0+ years without its exhaustion becoming an issue. So why should >>> the I= ETF do anything */now/*? >> >> This is motivated in section 1: >> >> The r= ationale for this update is a need >> to assign codepoints for particular = PHBs that are unable to use any >> of the unassigned values in Pool 1. >> = >> This problem is caused by implementations that do IP precedence >> blea= ching (i.e., zeroing the top three bits of the DSCP) thereby >> rewriting = (or unintentionally mapping) DSCP values to other DSCP >> values. This is = a problem for the mentioned LE PHB I-D >> https://tools.ietf.org/html/draf= t-ietf-tsvwg-le- >> phb >> It is possible that some other standardized DSC= Ps get mapped to the LE >> PHB DSCP if the LE DSCP were taken from the DSC= P standards action pool >> 1 (xxxxx0). >> >> There are measurements and mo= re background material for this: >> https://datatracker.ietf.org/meeting/9= 9/materials/slides-99-tsvwg-sess >> b- >> 31measurements-concerning-the-ds= cp-for-a-le-phb-00 >> https://www.ietf.org/proceedings/96/slides/slides-96= -maprg-6.pdf >> >> Regards, >> Roland >> >> ______________________________= ____________________________ >> _________________ >> >> This e-mail messag= e is intended for the recipient only and contains >> information which is = CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have r= eceived this transmission in error, please >> inform us by e-mail, phone o= r fax, and then delete the original and >> all copies thereof. >> ________= __________________________________________________ >> _________________ > = > ________________________________________________________________________= ___ > > This e-mail message is intended for the recipient only and contain= s information which is > CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this > transmission in error, please inform = us by e-mail, phone or fax, and then delete the original > and all copies = thereof. > _______________________________________________________________= ____________ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB5PR0301MB1909DBAE4BD858DA2530781E9D9A0DB5PR0301MB1909_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Gorry,
Providing additional context including explicit description of bleaching o= f the IP Precedence bits would surely help.

Thumb typed by Sasha Vainshtein



From: Gorry Fairhurst
Sent: Tuesday, May 8, 21:49
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04
To: Alexander Vainshtein
Cc: Black, David, tsvwg@ietf.org, Bless, Roland (TM)


Hi, Maybe I can provide a little more context about other unallocated valu= es in the registry. Each request for a new DSCP needs to be considered car= efully and separately looking at the implications on both the deployed use= of Codepoints and the needs for the PHB. As it happens, the unassigned DSCPs in pool 1 could well remain usef= ul for any new PHBs- if any new ones are approved by TSVWG that can be ble= ached to default (BE) - the case for most currently defined PHBs. I expect= the new pool will be only used by IANA requests from TSVWG when there is a case for not using any of the re= maining pool 1 values. That case has been made for the LE PHB. There could= potentially be other allocations in the future, but that is none are curr= ently considered. Gorry Sent from my iPad > On 8 May 2018, at 15:55, Alexander Vainshtein wrote: > > = David, > Lots of thanks for a very detailed explanation. > > Comi= ng back to my original doubt, , changing the IANA allocation policy on Poo= l 3 (16 values) in order to make just one value standard still looks an exaggeration to me. > What are we going to do with the = remaining 15 values? > > Regards, > Sasha > > Office: += 972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtei= n@ecitele.com > > > -----Original Message----- > From: Black, = David [mailto:David.Black@dell.com] > Sent: Tuesday, May 8, 2018 5:46 PM >= ; To: Alexander Vainshtein ; Bless, Roland (TM) > Cc: gorry@erg.abdn.ac= .uk; tsvwg@ietf.org > Subject: RE: [tsvwg] Doubts regarding motivation = of draft-ietf-tsvwg-iana-dscp-registry-04 > > Writing as an individual, not WG chair ... > >> It provides a workaround= for the IP precedence bleaching for LE >> traffic that you want to = introduce - but what about all other PHBs? > > The concern is not ab= out what happens in Diffserv domains/regions that are updated to implement support for the new LE PHB, but what happens when that LE PH= B traffic transits through routers elsewhere that bleach IP Precedence. &g= t; > Right now IP Precedence bleaching tends to result in best effort s= ervice, which is ok, albeit not ideal. If IP Precedence bleaching could result in a DSCP for the LE PHB, the result= downstream of the bleaching could be worse than best effort service for a= DSCP that was intended to obtain better than best effort service - that i= s the priority inversion that we're trying to avoid. > >> Would they not require some intelligent re= write of the DSCP when >> traffic enters the bleaching domain? > = > Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching= already violates a bunch of RFCs, dating back to RFC 2474. We can write what we like in a new RFC, but that "running code"= in deployed routers isn't going to magically stop bleaching IP Precedence= just because we publish a new RFC. > > Thanks, --David > >>= ; -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ie= tf.org] On Behalf Of Alexander >> Vainshtein >> Sent: Tuesday, May 8,= 2018 10:08 AM >> To: Bless, Roland (TM) >> Cc: gorry@erg.abdn= .ac.uk; tsvwg@ietf.org >> Subject: Re: [tsvwg] Doubts regarding moti= vation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >&g= t; >> Ronald, >> Lots of thanks for a prompt response. >> >> I have t= o admit that your explanation looks problematic to me. >> It provide= s a workaround for the IP precedence bleaching for LE >> traffic tha= t you want to introduce - but what about all other PHBs? >> Would they not require some intelligent rewrite of the DSCP when >> traff= ic enters the bleaching domain? >> And if so, why should not the sam= e approach be used for LE in this domain? >> >> Regards, >&= gt; Sasha >> >> Office: +972-39266302 >> Cell: += 972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >> >> >> -----O= riginal Message----- >> From: Bless, Roland (TM) [mailto:roland.bles= s@kit.edu] >> Sent: Tuesday, May 8, 2018 12:26 PM >> To: Alexa= nder Vainshtein ; >> gorry@erg.abdn.ac.uk >> Cc: tsvwg@ietf.or= g >> Subject: Re: [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana= - >> dscp-registry-04 >> >> Hi Sasha, >> >>&= gt; Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: >>> I ha= ve looked up the draft >>> >>> , and I have doubts regar= ding validity of its motivation. >>> >>> The draft says - correctly -that 22 out of 32 v= alues in Pool 1 of >>> the DSCP code points have been already ass= igned, therefore it >>> considers this pool as nearly exhausted. = >>> >>> What the draft does not say that, out of these 2= 2 assignments, 2o >>> have been done in 1998 and one - in 1999. Only one assign= ment has >>> been requested in the past 19 years, and no assignme= nts have been >>> requested after 2010. >> >>> At = this rate my estimate is that Pool 1 would suffice for the next >>&g= t; 50+ years without its exhaustion becoming an issue. So why should >>> the = IETF do anything */now/*? >> >> This is motivated in section 1= : >> >> The rationale for this update is a need >> to as= sign codepoints for particular PHBs that are unable to use any >> of= the unassigned values in Pool 1. >> >> This problem is caused by implementat= ions that do IP precedence >> bleaching (i.e., zeroing the top three= bits of the DSCP) thereby >> rewriting (or unintentionally mapping)= DSCP values to other DSCP >> values. This is a problem for the mentioned LE PHB I-D >> https://tools.ietf.org/html/draft-ietf-= tsvwg-le- >> phb >> It is possible that some other standardize= d DSCPs get mapped to the LE >> PHB DSCP if the LE DSCP were taken f= rom the DSCP standards action pool >> 1 (xxxxx0). >> >> = There are measurements and more background material for this: >> https://= datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sess >> b-= >> 31measurements-concerning-the-dscp-for-a-le-phb-00 >> http= s://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf >> >> Regards, >> Roland >> >> ____________= ______________________________________________ >> _________________ = >> >> This e-mail message is intended for the recipient only a= nd contains >> information which is CONFIDENTIAL and which may be pr= oprietary to ECI >> Telecom. If you have received this transmission in error, please= >> inform us by e-mail, phone or fax, and then delete the original = and >> all copies thereof. >> ________________________________= __________________________ >> _________________ > > __________= _________________________________________________________________ > > This e-mail message is intended for the recipient only and cont= ains information which is > CONFIDENTIAL and which may be proprietary t= o ECI Telecom. If you have received this > transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original > and all copies thereof. > __________________________= _________________________________________________


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB5PR0301MB1909DBAE4BD858DA2530781E9D9A0DB5PR0301MB1909_-- From nobody Tue May 8 13:46:23 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1BE12EABF for ; Tue, 8 May 2018 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp7f5Inq5W3Y for ; Tue, 8 May 2018 13:46:20 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41DD12EABB for ; Tue, 8 May 2018 13:46:19 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id m21-v6so21670851pgv.8 for ; Tue, 08 May 2018 13:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FsQc7GDE0bPw9FeUPOFFMCjGZE/fbsMTG5UFTBZ4NiI=; b=Zn3NqTpb8EwdOMawQaYwdSc42QcU0JnUdPajwDvIcOZGNXJrcC8G2dwbSbe2fcIPr0 XMqOGqcnFHerG/aWXRHvWejGLruJsyMAyvuzJ+uGi88ETjm5DO75rnoz/qLQYeMO66S6 z8DXnYtYRAnEhsy/2UEzWjksx61JMrP7T7VWYQXsva627fePqvVyUe5T7wXRRtgtjoqG PQJ+8igO3g0Vt/YcyfcBi85GrMR2ZrpASCK7VX/XCdFshpqrMcF1VIiOLHxwV/a7HzYJ WbtRj7OOAnaIVoA/iMMVhFQMeqZZzB+d/VpYOm6lxRJPfvO2Mnlt2SGwcR2fwImNDDG/ Vs1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FsQc7GDE0bPw9FeUPOFFMCjGZE/fbsMTG5UFTBZ4NiI=; b=qc17/weg17k47Ym8jLd027wkYKsqaE1pCp9zNY4ZfSJtmZLtIXeCFlJxXnQ/90IgqJ 2HhDeGfTr8w02lNups6cWOh5F8BvRziPZXsGQYANKVEJ8bM5K3WG8nfRWF7ygrOzJv4I QuPOMettUUb48chSxhwaQHZ/LD18bMHxTGEutErz5iAJ9XrUdAL1CfjHqWmkNFiMUBHg qNNw0lhzY8FdbqAYx4nBLR/abGwCfqZLu1/4AOZhlVsrxKGUQZrh22Tigl8ewNcwZ03t /S/NRij87ibEdxtAyBkaWmWC5pftRQy2uqYztBYacLmoYjCMzU5yVYLLdwye/AWmPiLI Q2TA== X-Gm-Message-State: ALQs6tAMjbqWEL+02zktH3hZIyX9m4FecnO48B1jCY8H0eHEaUMMdcPY y43ojWkRnD/6jQMIxraC6digvA== X-Google-Smtp-Source: AB8JxZqmrGxEZNTc30hPYTeDka2iY3lt5x3e0wdeCTLW2vUV3CbM99gFziqX6FRX7OnQ7DWAwPijVg== X-Received: by 10.98.130.140 with SMTP id w134mr33534069pfd.138.1525812379243; Tue, 08 May 2018 13:46:19 -0700 (PDT) Received: from [192.168.178.26] (65.21.255.123.dynamic.snap.net.nz. [123.255.21.65]) by smtp.gmail.com with ESMTPSA id c87sm1707365pfd.78.2018.05.08.13.46.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 13:46:18 -0700 (PDT) To: Alexander Vainshtein Cc: "Black, David" , "gorry@erg.abdn.ac.uk" , "Bless, Roland (TM)" , "tsvwg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <6df5ae09-3a4e-2b34-05ba-d935c92afe0f@gmail.com> Date: Wed, 9 May 2018 08:46:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 20:46:22 -0000 On 09/05/2018 02:55, Alexander Vainshtein wrote: > David, > Lots of thanks for a very detailed explanation. > > Coming back to my original doubt, , changing the IANA allocation policy on Pool 3 (16 values) in order to make just one value standard still looks an exaggeration to me. > What are we going to do with the remaining 15 values? To be honest, probably nothing. Having as many as 6 bits to select a per-hop behaviour has always seemed like a lot (and led to rather complex solutions such as 4 distinct AF classes each with 3 drop precedences). However, if somebody ever came along with a need for a very large number of local-use PHBs, there's nothing to stop them using Pool 3, since all DSCP values are RECOMMENDED anyway, except for CS0-7. (Paragraph 3 at https://tools.ietf.org/html/rfc2474#page-8 ) This is the irony of having misused CS1 for LE - it's one of the few code points that is truly mandated by RFC2474. Brian From nobody Tue May 8 22:18:13 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74985127058; Tue, 8 May 2018 22:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRvmTDRdnQOF; Tue, 8 May 2018 22:18:10 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7278A1270FC; Tue, 8 May 2018 22:18:10 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id r202-v6so10364435ywg.10; Tue, 08 May 2018 22:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4RpmgjJ4UNFrkBlHmCuvLjW4q+pv3A6SuYqbMdCS4Jw=; b=FYvZHswdFpVDYjgfZbygq/FecP5c4STtfBtIX93chKNmWfp5ytXdpm5jl5eMG8HGvs z39ss/oTa6lNmoyMtvXlEcYQ6fQN88fuZMuyJ1QInGK9NDTiSLqlFOXu16146LePOKtp dlZ89beS5PnsQMhL9PQfZh1+Oq/f9iOc44H0MqmGuRDOUWfMy283VuwHjEJhPT3Nu/mz 2quRqJb+Nhe5kmR99LcaBk6jvR0plz5XDCikRZWWgXibtDJA96NXttkDjVcMrNgsNoy9 7BoWQys1vP0E6eVkYgdj730ZxC4BXcLz385eiR41J4ivWXUkRgQXf5ncEiDvgpubsXZB JpWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4RpmgjJ4UNFrkBlHmCuvLjW4q+pv3A6SuYqbMdCS4Jw=; b=lTJpOk8Xc+vN8UMu9BlCNhWAR+WelNRShS4tXeYT84WeGLxKVWBnEqv/QqlZ9APVA6 hrQQxcBZzmRKiHRu3g8mNH+noEw2w0AefWcIcR/R7fw0NZh/45Bz7lgxK/+5kYmppAKD 2rcfEYLbrH8WdDk73xMJORYf/a+lW6Kw9gnNZ1hHcsDDcaN/Lyo/fOqhQJtntPL5yu7b L7n2kOP7iN9ONaydqGXk0ou0vyu023o634pqKbfgYMC0hZEq4Bxjd8aEmWctbEwj/iVc TAYVVH4j9ds+KjgMN0L6qIBSvV9mjpOHQxE2EFoS/M2n2iSkL05/q6KJzPYTCPOpSs4s 2F+w== X-Gm-Message-State: ALQs6tCj16Sr6vUsW+CpeBOPOPQYDaYXq7GSvXn/c0s4G++iawczuZv+ lG+D5kUgzRyBfeEjXV+yhh9/nGlhYi6KwA0Gq4hnfA== X-Google-Smtp-Source: AB8JxZrf83Xdnh2Suaag8nMkKje33ucTaWn7HK7v00ry3z/c8a+5bv60hTLCek1Y5e7vNPz3yTKLQxtT7h5pA6iA/2Y= X-Received: by 2002:a0d:ed06:: with SMTP id w6-v6mr22652227ywe.467.1525843089614; Tue, 08 May 2018 22:18:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Tue, 8 May 2018 22:18:08 -0700 (PDT) In-Reply-To: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> References: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 9 May 2018 00:18:08 -0500 Message-ID: To: David Black Cc: tsvwg-chairs , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="00000000000056ee6e056bbf0700" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 05:18:12 -0000 --00000000000056ee6e056bbf0700 Content-Type: text/plain; charset="UTF-8" On Tue, May 8, 2018 at 9:00 AM, David Black wrote: David Black has requested publication of draft-ietf-tsvwg-iana-dscp-registry-04 > as Proposed Standard on behalf of the TSVWG working group. > > Please verify the document's state at https://datatracker.ietf.org/ > doc/draft-ietf-tsvwg-iana-dscp-registry/ I have a couple of comments, but this draft is ready for Last Call. Could you take a look at my comments, and let me know what the right thing to do is? Thanks! Spencer There's a reference to https://tools.ietf.org/html/rfc8126#section-4.9 in the Introduction, but that text uses "Standards Action" with the reference but without any expansion, while further down, the next occurrence of "Standards Action" explains that this means "values are assigned by Standards Track or Best Current Practice RFCs", without providing a reference. Perhaps expanding These are assigned by Standards Action, as defined in [RFC8126]. to read These are assigned by Standards Action, as defined in [RFC8126], i.e., values are assigned by Standards Track or Best Current Practice RFCs and dropping the expansion from the second mention would be clearer? Independent of that question, I had to read through the text containing the second mention a couple of times. Although Pool 1 has not yet been completely exhausted, this document changes the IANA registration policy of Pool 3 to assignment by Standards Action, i.e., values are assigned by Standards Track or Best Current Practice RFCs. The rationale for this update is a need to assign codepoints for particular PHBs that are unable to use any of the unassigned values in Pool 1. Would it be correct to say Although Pool 1 has not yet been completely exhausted, there is a need to assign codepoints for particular PHBs that are unable to use any of the unassigned values in Pool 1. This document changes the IANA registration policy of Pool 3 to assignment by Standards Action, i.e., values are assigned by Standards Track or Best Current Practice RFCs, allowing these codepoints to be assigned. ? --00000000000056ee6e056bbf0700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 8, 2018 at 9:00 AM, David Black <david.black@dell.com> wrote:

David Black has requested publication of draft-ietf= -tsvwg-iana-dscp-registry-04 as Proposed Standard on behalf of the TSV= WG working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/

I have a couple of com= ments, but this draft is ready for Last Call. Could you take a look at my c= omments, and let me know what the right thing to do is?

Thanks!

Spencer

=C2=A0There's a reference to https://tools.ietf.org= /html/rfc8126#section-4.9 in the Introduction, but that text uses "= ;Standards Action" with the reference but without any expansion, while= further down, the next occurrence=C2=A0of "Standards Action" exp= lains that this means "values are assigned by Standards Track or Best = Current Practice RFCs", without providing a reference. Perhaps expandi= ng
=C2=A0
=
=C2=A0 =C2=A0These are assigned by=
=C2=A0 =C2=A0Standard= s Action, as defined in [RFC8126].=C2=A0


=C2=A0 =C2=A0These are = assigned by
=C2=A0 =C2= =A0Standards Action, as defined in [RFC8126], i.e., values are assigned=C2= =A0
=C2=A0 =C2=A0by St= andards Track or Best Current Practice RFCs

and dropping the expansion from the second mention would be clearer?= =C2=A0

Independent of that question, I = had to read through the text containing the second mention a couple of time= s.

=C2=A0 Although Pool 1 has not yet b= een completely exhausted, this document
=C2=A0 =C2=A0changes the IANA registration policy of Pool= 3 to assignment by
= =C2=A0 =C2=A0Standards Action, i.e., values are assigned by Standards Track= or
=C2=A0 =C2=A0Best = Current Practice RFCs.=C2=A0 The rationale for this update is a need=
=C2=A0 =C2=A0to assign codep= oints for particular PHBs that are unable to use any
=C2=A0 =C2=A0of the unassigned values in Poo= l 1.

=
Would it be correct to say=C2=A0

<= font face=3D"monospace, monospace">=C2=A0 Although Pool 1 has not yet been = completely exhausted, there is a need
=C2=A0 =C2=A0to assign codepoints for particular PHBs that = are unable to use any
= =C2=A0 =C2=A0of the unassigned values in Pool 1. This document
=
=C2=A0 =C2=A0changes the IANA regi= stration policy of Pool 3 to assignment by
=C2=A0 =C2=A0Standards Action, i.e., values are assign= ed by Standards Track or
=C2=A0 =C2=A0Best Current Practice RFCs, allowing these codepoints to be= assigned.

=
?
--00000000000056ee6e056bbf0700-- From nobody Wed May 9 01:14:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F143B12EB1B; Wed, 9 May 2018 01:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 6qQXjfwXxfuW; Wed, 9 May 2018 01:14:23 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id F118812EAF1; Wed, 9 May 2018 01:14:22 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 153041B00223; Wed, 9 May 2018 09:13:46 +0100 (BST) Message-ID: <5AF2ADBA.9060402@erg.abdn.ac.uk> Date: Wed, 09 May 2018 09:13:46 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Spencer Dawkins at IETF CC: David Black , tsvwg-chairs , tsvwg@ietf.org References: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 08:14:26 -0000 These request are all OK with me, and I have made the changes. The recent thread on the TSVWG list has made me wonder again whether it is possible for me to be slightly clearer about explaining the TOS precedence bleaching - without drilling into all the detail. This has always a nightmare to write concisely, but I think I may be able to do better, and if you agree, I would also incorporate the slightly longer replacement text below: OLD: An example is the need to assign a suitable recommended default codepoint for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. The LE PHB is designed to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. The continued presence of bleaching of the IP precedence field, setting the first three bits of the former TOS byte to zero (i.e., zeroing the top three bits of the DSCP) in deployed networks motivates the desire for the LE PHB to use a DSCP with a zero value for the first three bits [I-D.ietf-tsvwg-le-phb]. NEW: An example is the need to assign a suitable recommended default codepoint for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. The LE PHB is designed to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and is allowed to preempt it. The continued presence of bleaching of the IP precedence field in deployed networks can result in setting the first three bits of the former TOS byte to zero (disabling any class-based flow management by routers configured with TOS-based packet processing). There is a need to avoid this remapping of the DSCP for the LE PHB by assiging a codepoint that has a zero value in the first three bits [I-D.ietf-tsvwg-le-phb]. Furthermore, if the LE PHB were to have been assigned one of the currently unused Pool 1 codepoints with a zero value in the first three bits, any bleaching of the IP precedence field would result in other (higher assurance) traffic being remapped to the assigned DSCP. This remapping could then cause diffserv-marked traffic to receive an unintentional LE treatment for the remainder of the Internet path. It is therefore important to avoid the resulting priority inversion. The absence of unassigned codepoints in Pool 1 that exhibit these important properties motivates assigning a Pool 3 codepoint as the default that is recommended for use with this PHB. --- - Your thoughts please, I'll hold publishing the new revision until I hear from you, Gorry On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote: > On Tue, May 8, 2018 at 9:00 AM, David Black > wrote: > > David Black has requested publication of > draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on > behalf of the TSVWG working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ > > > > I have a couple of comments, but this draft is ready for Last Call. > Could you take a look at my comments, and let me know what the right > thing to do is? > > Thanks! > > Spencer > > There's a reference to > https://tools.ietf.org/html/rfc8126#section-4.9 in the Introduction, > but that text uses "Standards Action" with the reference but without > any expansion, while further down, the next occurrence of "Standards > Action" explains that this means "values are assigned by Standards > Track or Best Current Practice RFCs", without providing a reference. > Perhaps expanding > These are assigned by > Standards Action, as defined in [RFC8126]. > > to read > > These are assigned by > Standards Action, as defined in [RFC8126], i.e., values are assigned > by Standards Track or Best Current Practice RFCs > > and dropping the expansion from the second mention would be clearer? > > Independent of that question, I had to read through the text > containing the second mention a couple of times. > > Although Pool 1 has not yet been completely exhausted, this document > changes the IANA registration policy of Pool 3 to assignment by > Standards Action, i.e., values are assigned by Standards Track or > Best Current Practice RFCs. The rationale for this update is a need > to assign codepoints for particular PHBs that are unable to use any > of the unassigned values in Pool 1. > > Would it be correct to say > > Although Pool 1 has not yet been completely exhausted, there is a need > to assign codepoints for particular PHBs that are unable to use any > of the unassigned values in Pool 1. This document > changes the IANA registration policy of Pool 3 to assignment by > Standards Action, i.e., values are assigned by Standards Track or > Best Current Practice RFCs, allowing these codepoints to be assigned. > > ? From nobody Wed May 9 12:04:57 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25AF1274D2; Wed, 9 May 2018 12:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB9M-pwEIkIE; Wed, 9 May 2018 12:04:53 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAC1127076; Wed, 9 May 2018 12:04:53 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f3-v6so4301922ybg.13; Wed, 09 May 2018 12:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wocV9c45WMkpn0XVVuXOVQRc1ef81ldoDgt1qHb6ybM=; b=tvLQgP5tmEGId7Wgyxbn/j/qeIAqaD0zXW95r8G08MDqRbnE40Upowp5oM3R32BeDa X0zwcx7g2yJmgM+F/jEOYrM0B+zOzA8cDSx4dAkLmL2k//hz5Zql4NvbCQFC1i0nXsln e4kfgEouCTs6Dyutl0l3IbNh9tCE5c5xo2UpqiE6Y9DQxUwM6XKgin0vSJfDl787WX9y ZxnQ9MN9+DBbUwTww5Eh5AVnmiO43JVBUH0ai/lFUIfUm1ewlxErp32RoQcq4B6jHLiY WnaAR7pvMbh229pgS0zhmVbBOmHFJIUF6+FmsQsLez4i7A28Oo2q8AtPGwBHRcyqv2nt 9mWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wocV9c45WMkpn0XVVuXOVQRc1ef81ldoDgt1qHb6ybM=; b=f+h7luk0e3FgqiEuoIdrbWwo93WL8+6iIoFLBXehFPxynLAaZR+ZWoJW1dEBdRMSdl Z6FZ07nKoZHP3mUZSfSgBrT6UK5RyYljaXyGvifbmxURV+otgaoCXR8IISBY7IksyX97 NTZOF/AvhoyCquUSZn+SVwGatrKZVv580OWmg3JcgaFecYl5BrtOSmEyVQ2Bg//BSacW FOq4PlkhBIkvBbfqy9biO2SgO+yKbGNsASqkHluhl2W3eHrDNHy8QO7GkFqv5nEtsjfK b6io7ujLgI+dpMkiEQGViMjILWL+VumNcCeDYbepqRaWDc18gcEkWjWlg0bJAV73w1is he+A== X-Gm-Message-State: ALQs6tChQLjH8CPQso+wRWP8ZFBCP4k2CgZyXKA0s8WNmZSunt9Z1H9q vJcNotF44Wn0Jmi7s9XrIPw9FylvGJ/OD7Csbf8= X-Google-Smtp-Source: AB8JxZqtyoGI0oDknhEeWksx4rtiWv7dQkwhWJ/28jBeidcLWdJytUnvYL5n5tRV4z/F4RRCCTvoOxea1BkA7Bawp9M= X-Received: by 2002:a25:6a55:: with SMTP id f82-v6mr12349105ybc.235.1525892692073; Wed, 09 May 2018 12:04:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Wed, 9 May 2018 12:04:51 -0700 (PDT) In-Reply-To: <5AF2ADBA.9060402@erg.abdn.ac.uk> References: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> <5AF2ADBA.9060402@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Wed, 9 May 2018 14:04:51 -0500 Message-ID: To: G Fairhurst Cc: David Black , tsvwg-chairs , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000e06947056bca930a" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 19:04:56 -0000 --000000000000e06947056bca930a Content-Type: text/plain; charset="UTF-8" Hi, Gorry, On Wed, May 9, 2018 at 3:13 AM, Gorry Fairhurst wrote: > These request are all OK with me, and I have made the changes. > > The recent thread on the TSVWG list has made me wonder again whether it is > possible for me to be slightly clearer about explaining the TOS precedence > bleaching - without drilling into all the detail. This has always a > nightmare to write concisely, but I think I may be able to do better, and > if you agree, I would also incorporate the slightly longer replacement text > below: > > OLD: > An example is the need to assign a suitable recommended default codepoint > for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. > The LE PHB is designed to protect best-effort (BE) traffic (packets > forwarded with the default PHB) from LE traffic in congestion situations, > i.e., when resources become scarce, best-effort traffic has precedence over > LE traffic and may preempt it. The continued presence of bleaching of the > IP precedence field, setting the first three bits of the former TOS byte to > zero (i.e., zeroing the top three bits of the DSCP) in deployed networks > motivates the desire for the LE PHB to use a DSCP with a zero value for the > first three bits [I-D.ietf-tsvwg-le-phb]. > > NEW: > An example is the need to assign a suitable recommended default codepoint > for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. > The LE PHB is designed to protect best-effort (BE) traffic (packets > forwarded with the default PHB) from LE traffic in congestion situations, > i.e., when resources become scarce, best-effort traffic has precedence over > LE traffic and is allowed to preempt it. The continued presence of > bleaching of the IP precedence field in deployed networks can result in > setting the first three bits of the former TOS byte to zero (disabling any > class-based flow management by routers configured with TOS-based packet > processing). There is a need to avoid this remapping of the DSCP for the LE > PHB by assiging a codepoint that has a zero value in the first three bits > [I-D.ietf-tsvwg-le-phb]. Furthermore, if the LE PHB were to have been > assigned one of the currently unused Pool 1 codepoints with a zero value in > the first three bits, any bleaching of the IP precedence field would result > in other (higher assurance) traffic being remapped to the assigned DSCP. > This remapping could then cause diffserv-marked traffic to receive an > unintentional LE treatment for the remainder of the Internet path. It is > therefore important to avoid the resulting priority inversion. The absence > of unassigned codepoints in Pool 1 that exhibit these important properties > motivates assigning a Pool 3 codepoint as the default that is recommended > for use with this PHB. > --- > > - Your thoughts please, I'll hold publishing the new revision until I hear > from you, > I don't object to the new text, but it looks like there's still some mailing list traffic on this draft - I'll go read that next. If you do the right thing, that will be fine with me, of course ... Spencer > Gorry > > On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote: > > On Tue, May 8, 2018 at 9:00 AM, David Black > david.black@dell.com>> wrote: >> >> David Black has requested publication of >> draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on >> behalf of the TSVWG working group. >> >> Please verify the document's state at >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ >> > -registry/> >> >> >> I have a couple of comments, but this draft is ready for Last Call. Could >> you take a look at my comments, and let me know what the right thing to do >> is? >> >> Thanks! >> >> Spencer >> >> There's a reference to https://tools.ietf.org/html/rfc8126#section-4.9 >> in the Introduction, but that text uses "Standards Action" with the >> reference but without any expansion, while further down, the next >> occurrence of "Standards Action" explains that this means "values are >> assigned by Standards Track or Best Current Practice RFCs", without >> providing a reference. Perhaps expanding >> These are assigned by >> Standards Action, as defined in [RFC8126]. >> >> to read >> >> These are assigned by >> Standards Action, as defined in [RFC8126], i.e., values are assigned >> by Standards Track or Best Current Practice RFCs >> >> and dropping the expansion from the second mention would be clearer? >> >> Independent of that question, I had to read through the text containing >> the second mention a couple of times. >> >> Although Pool 1 has not yet been completely exhausted, this document >> changes the IANA registration policy of Pool 3 to assignment by >> Standards Action, i.e., values are assigned by Standards Track or >> Best Current Practice RFCs. The rationale for this update is a need >> to assign codepoints for particular PHBs that are unable to use any >> of the unassigned values in Pool 1. >> >> Would it be correct to say >> >> Although Pool 1 has not yet been completely exhausted, there is a need >> to assign codepoints for particular PHBs that are unable to use any >> of the unassigned values in Pool 1. This document >> changes the IANA registration policy of Pool 3 to assignment by >> Standards Action, i.e., values are assigned by Standards Track or >> Best Current Practice RFCs, allowing these codepoints to be assigned. >> >> ? >> > > --000000000000e06947056bca930a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Gorry,

On Wed, May 9, 2018 at 3:13 AM, Gorry Fairhurst <gorry@erg.ab= dn.ac.uk> wrote:
These re= quest are all OK with me, and I have made the changes.

The recent thread on the TSVWG list has made me wonder again whether it is = possible for me to be slightly clearer about explaining the TOS precedence = bleaching - without drilling into all the detail. This has always a nightma= re to write concisely, but I think I may be able to do better, and if you a= gree, I would also incorporate the slightly longer replacement text below:<= br>
OLD:
An example is the need to assign a suitable recommended default codepoint f= or the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. Th= e LE PHB is designed to protect best-effort (BE) traffic (packets forwarded= with the default PHB) from LE traffic in congestion situations, i.e., when= resources become scarce, best-effort traffic has precedence over LE traffi= c and may preempt it. The continued presence of bleaching of the IP precede= nce field, setting the first three bits of the former TOS byte to zero (i.e= ., zeroing the top three bits of the DSCP) in deployed networks motivates t= he desire for the LE PHB to use a DSCP with a zero value for the first thre= e bits [I-D.ietf-tsvwg-le-phb].

NEW:
An example is the need to assign a suitable recommended default codepoint f= or the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. Th= e LE PHB is designed to protect best-effort (BE) traffic (packets forwarded= with the default PHB) from LE traffic in congestion situations, i.e., when= resources become scarce, best-effort traffic has precedence over LE traffi= c and is allowed to preempt it. The continued presence of bleaching of the = IP precedence field in deployed networks can result in setting the first th= ree bits of the former TOS byte to zero (disabling any class-based flow man= agement by routers configured with TOS-based packet processing). There is a= need to avoid this remapping of the DSCP for the LE PHB by assiging a code= point that has a zero value in the first three bits [I-D.ietf-tsvwg-le-phb]= . Furthermore, if the LE PHB were to have been assigned one of the currentl= y unused Pool 1 codepoints with a zero value in the first three bits, any b= leaching of the IP precedence field would result in other (higher assurance= ) traffic being remapped to the assigned DSCP. This remapping could then ca= use diffserv-marked traffic to receive an unintentional LE treatment for th= e remainder of the Internet path. It is therefore important to avoid the re= sulting priority inversion. The absence of unassigned codepoints in Pool 1 = that exhibit these important properties motivates assigning a Pool 3 codepo= int as the default that is recommended for use with this PHB.
---

- Your thoughts please, I'll hold publishing the new revision until I h= ear from you,

I don't object to the= new text, but it looks like there's still some mailing list traffic on= this draft - I'll go read that next.

If you d= o the right thing, that will be fine with me, of course ...

<= /div>
Spencer
=C2=A0
= Gorry

On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote:
<= div class=3D"h5">
On Tue, May 8, 2018 at 9:00 AM, David Black <david.black@dell.com <mailto:david.black@dell.com= >> wrote:

=C2=A0 =C2=A0 David Black has requested publication of
=C2=A0 =C2=A0 draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Stand= ard on
=C2=A0 =C2=A0 behalf of the TSVWG working group.

=C2=A0 =C2=A0 Please verify the document's state at
=C2=A0 =C2=A0 https://datatrack= er.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/
=C2=A0 =C2=A0 <https://datat= racker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/><= br>

I have a couple of comments, but this draft is ready for Last Call. Could y= ou take a look at my comments, and let me know what the right thing to do i= s?

Thanks!

Spencer

=C2=A0There's a reference to https://tools.ietf.o= rg/html/rfc8126#section-4.9 in the Introduction, but that text use= s "Standards Action" with the reference but without any expansion= , while further down, the next occurrence of "Standards Action" e= xplains that this means "values are assigned by Standards Track or Bes= t Current Practice RFCs", without providing a reference. Perhaps expan= ding
=C2=A0 =C2=A0These are assigned by
=C2=A0 =C2=A0Standards Action, as defined in [RFC8126].

to read

=C2=A0 =C2=A0These are assigned by
=C2=A0 =C2=A0Standards Action, as defined in [RFC8126], i.e., values are as= signed
=C2=A0 =C2=A0by Standards Track or Best Current Practice RFCs

and dropping the expansion from the second mention would be clearer?

Independent of that question, I had to read through the text containing the= second mention a couple of times.

=C2=A0 Although Pool 1 has not yet been completely exhausted, this document=
=C2=A0 =C2=A0changes the IANA registration policy of Pool 3 to assignment b= y
=C2=A0 =C2=A0Standards Action, i.e., values are assigned by Standards Track= or
=C2=A0 =C2=A0Best Current Practice RFCs.=C2=A0 The rationale for this updat= e is a need
=C2=A0 =C2=A0to assign codepoints for particular PHBs that are unable to us= e any
=C2=A0 =C2=A0of the unassigned values in Pool 1.

Would it be correct to say

=C2=A0 Although Pool 1 has not yet been completely exhausted, there is a ne= ed
=C2=A0 =C2=A0to assign codepoints for particular PHBs that are unable to us= e any
=C2=A0 =C2=A0of the unassigned values in Pool 1. This document
=C2=A0 =C2=A0changes the IANA registration policy of Pool 3 to assignment b= y
=C2=A0 =C2=A0Standards Action, i.e., values are assigned by Standards Track= or
=C2=A0 =C2=A0Best Current Practice RFCs, allowing these codepoints to be as= signed.

?


--000000000000e06947056bca930a-- From nobody Wed May 9 12:32:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409B11270AC; Wed, 9 May 2018 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFN7knEuSf_8; Wed, 9 May 2018 12:32:22 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF35126DD9; Wed, 9 May 2018 12:32:22 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id i13-v6so12729227ybl.4; Wed, 09 May 2018 12:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hwyfltvap5FCmfrILRXOkfVjnfW5ZIbNdlgCBnD2tNo=; b=ea6onzRaWcq0QdWKPvFw7/RefJ8zKG0rw83SgiAndWQSQcm2yyMRP11+a1t6JkVu7b Ed/mQbM2Z1ZiPRuIwxRxXdCFAlfTcgc3qIJkUQR83ZcTbLbp4VjA3vi4PzyyM/6nzVhK RLMl0prrMSdJzK5D6gbQajM/S7+1XFM9RFBp7GPkKXicbLyUSwejFOakCT4StB6DeNN8 xWytQ2UchxVEqnsZh6hWayixuWac3X8VGxf2k+sPz5hyxXxrky8PBNo2wQJ+XQGEy3u0 GeNTW0QeQOr13JB/v7A7E6X7hq41xGfQ2M24s+892AtJLUrmRWzCEAyRqyybsd4S2zE+ kqnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hwyfltvap5FCmfrILRXOkfVjnfW5ZIbNdlgCBnD2tNo=; b=n82n55ZUUVZnlz6fg+IrNDkbEc+SIqW8RHMmNyEzbUC4cPvPXpmUWnYLUYmaUG3+B6 qXs/zHXLr++Dj4mYi6tNVOieESvvNz7UTFlM+kKqZ9ow+xHRyMSMFdf5v0db0bQ+IZ6v M8crln5G9Vhcznc0zvsMmHOP1PnDr3d7b9a9t/COsmFefAIY5gHqAuQe+oMHeEsfwQpr ZZHmWt4ESSCqAgwtcpXiOjgAgZ0VljkVvF0xfjuxk7rFBiUBivMTgKE0+OirdYYr3Vri 383dzscSApFEihta/qPfU4ek4XE84NDWf65EjugtZ8uuuuzHdz1fZFy1OIpkQmzFpocf fw+g== X-Gm-Message-State: ALQs6tB0n+gxbsda9PZy/io8BZYpf2047Ty40UzzbWuZnpFq0ckKixZf rzfvqj6rvWvj+kx2jMTrsWKyoZ5GmTL9PPBgi9E= X-Google-Smtp-Source: AB8JxZqDFzTvbIfoRActcxvSlJbNmxICi5/0YNhOYXffyyJKuClL7pZi8UorjcSoEwSyI4mXrJzZ6OvBCw/IXPqG0/o= X-Received: by 2002:a25:e08:: with SMTP id 8-v6mr21688188ybo.71.1525894341244; Wed, 09 May 2018 12:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Wed, 9 May 2018 12:32:20 -0700 (PDT) In-Reply-To: References: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> <5AF2ADBA.9060402@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Wed, 9 May 2018 14:32:20 -0500 Message-ID: To: G Fairhurst Cc: David Black , tsvwg-chairs , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="0000000000002cc2fc056bcaf643" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 19:32:25 -0000 --0000000000002cc2fc056bcaf643 Content-Type: text/plain; charset="UTF-8" And, just following up ... On Wed, May 9, 2018 at 2:04 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Gorry, > > On Wed, May 9, 2018 at 3:13 AM, Gorry Fairhurst > wrote: > >> These request are all OK with me, and I have made the changes. >> >> The recent thread on the TSVWG list has made me wonder again whether it >> is possible for me to be slightly clearer about explaining the TOS >> precedence bleaching - without drilling into all the detail. This has >> always a nightmare to write concisely, but I think I may be able to do >> better, and if you agree, I would also incorporate the slightly longer >> replacement text below: >> >> OLD: >> An example is the need to assign a suitable recommended default codepoint >> for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. >> The LE PHB is designed to protect best-effort (BE) traffic (packets >> forwarded with the default PHB) from LE traffic in congestion situations, >> i.e., when resources become scarce, best-effort traffic has precedence over >> LE traffic and may preempt it. The continued presence of bleaching of the >> IP precedence field, setting the first three bits of the former TOS byte to >> zero (i.e., zeroing the top three bits of the DSCP) in deployed networks >> motivates the desire for the LE PHB to use a DSCP with a zero value for the >> first three bits [I-D.ietf-tsvwg-le-phb]. >> >> NEW: >> An example is the need to assign a suitable recommended default codepoint >> for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. >> The LE PHB is designed to protect best-effort (BE) traffic (packets >> forwarded with the default PHB) from LE traffic in congestion situations, >> i.e., when resources become scarce, best-effort traffic has precedence over >> LE traffic and is allowed to preempt it. The continued presence of >> bleaching of the IP precedence field in deployed networks can result in >> setting the first three bits of the former TOS byte to zero (disabling any >> class-based flow management by routers configured with TOS-based packet >> processing). There is a need to avoid this remapping of the DSCP for the LE >> PHB by assiging a codepoint that has a zero value in the first three bits >> [I-D.ietf-tsvwg-le-phb]. Furthermore, if the LE PHB were to have been >> assigned one of the currently unused Pool 1 codepoints with a zero value in >> the first three bits, any bleaching of the IP precedence field would result >> in other (higher assurance) traffic being remapped to the assigned DSCP. >> This remapping could then cause diffserv-marked traffic to receive an >> unintentional LE treatment for the remainder of the Internet path. It is >> therefore important to avoid the resulting priority inversion. The absence >> of unassigned codepoints in Pool 1 that exhibit these important properties >> motivates assigning a Pool 3 codepoint as the default that is recommended >> for use with this PHB. >> --- >> >> - Your thoughts please, I'll hold publishing the new revision until I >> hear from you, >> > > I don't object to the new text, but it looks like there's still some > mailing list traffic on this draft - I'll go read that next. > > If you do the right thing, that will be fine with me, of course ... > Having caught up on the mailing list traffic, I still think you're doing the right thing. Thanks! Spencer > Spencer > > >> Gorry >> >> On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote: >> >> On Tue, May 8, 2018 at 9:00 AM, David Black >> > wrote: >>> >>> David Black has requested publication of >>> draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on >>> behalf of the TSVWG working group. >>> >>> Please verify the document's state at >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp- >>> registry/ >>> >> -registry/> >>> >>> >>> I have a couple of comments, but this draft is ready for Last Call. >>> Could you take a look at my comments, and let me know what the right thing >>> to do is? >>> >>> Thanks! >>> >>> Spencer >>> >>> There's a reference to https://tools.ietf.org/html/rfc8126#section-4.9 >>> in the Introduction, but that text uses "Standards Action" with the >>> reference but without any expansion, while further down, the next >>> occurrence of "Standards Action" explains that this means "values are >>> assigned by Standards Track or Best Current Practice RFCs", without >>> providing a reference. Perhaps expanding >>> These are assigned by >>> Standards Action, as defined in [RFC8126]. >>> >>> to read >>> >>> These are assigned by >>> Standards Action, as defined in [RFC8126], i.e., values are assigned >>> by Standards Track or Best Current Practice RFCs >>> >>> and dropping the expansion from the second mention would be clearer? >>> >>> Independent of that question, I had to read through the text containing >>> the second mention a couple of times. >>> >>> Although Pool 1 has not yet been completely exhausted, this document >>> changes the IANA registration policy of Pool 3 to assignment by >>> Standards Action, i.e., values are assigned by Standards Track or >>> Best Current Practice RFCs. The rationale for this update is a need >>> to assign codepoints for particular PHBs that are unable to use any >>> of the unassigned values in Pool 1. >>> >>> Would it be correct to say >>> >>> Although Pool 1 has not yet been completely exhausted, there is a need >>> to assign codepoints for particular PHBs that are unable to use any >>> of the unassigned values in Pool 1. This document >>> changes the IANA registration policy of Pool 3 to assignment by >>> Standards Action, i.e., values are assigned by Standards Track or >>> Best Current Practice RFCs, allowing these codepoints to be assigned. >>> >>> ? >>> >> >> > --0000000000002cc2fc056bcaf643 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, just following up ...

<= div class=3D"gmail_quote">On Wed, May 9, 2018 at 2:04 PM, Spencer Dawkins a= t IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Gorry,

On Wed, May 9, 2= 018 at 3:13 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wr= ote:
These request are all OK with me, an= d I have made the changes.

The recent thread on the TSVWG list has made me wonder again whether it is = possible for me to be slightly clearer about explaining the TOS precedence = bleaching - without drilling into all the detail. This has always a nightma= re to write concisely, but I think I may be able to do better, and if you a= gree, I would also incorporate the slightly longer replacement text below:<= br>
OLD:
An example is the need to assign a suitable recommended default codepoint f= or the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. Th= e LE PHB is designed to protect best-effort (BE) traffic (packets forwarded= with the default PHB) from LE traffic in congestion situations, i.e., when= resources become scarce, best-effort traffic has precedence over LE traffi= c and may preempt it. The continued presence of bleaching of the IP precede= nce field, setting the first three bits of the former TOS byte to zero (i.e= ., zeroing the top three bits of the DSCP) in deployed networks motivates t= he desire for the LE PHB to use a DSCP with a zero value for the first thre= e bits [I-D.ietf-tsvwg-le-phb].

NEW:
An example is the need to assign a suitable recommended default codepoint f= or the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-le-phb]. Th= e LE PHB is designed to protect best-effort (BE) traffic (packets forwarded= with the default PHB) from LE traffic in congestion situations, i.e., when= resources become scarce, best-effort traffic has precedence over LE traffi= c and is allowed to preempt it. The continued presence of bleaching of the = IP precedence field in deployed networks can result in setting the first th= ree bits of the former TOS byte to zero (disabling any class-based flow man= agement by routers configured with TOS-based packet processing). There is a= need to avoid this remapping of the DSCP for the LE PHB by assiging a code= point that has a zero value in the first three bits [I-D.ietf-tsvwg-le-phb]= . Furthermore, if the LE PHB were to have been assigned one of the currentl= y unused Pool 1 codepoints with a zero value in the first three bits, any b= leaching of the IP precedence field would result in other (higher assurance= ) traffic being remapped to the assigned DSCP. This remapping could then ca= use diffserv-marked traffic to receive an unintentional LE treatment for th= e remainder of the Internet path. It is therefore important to avoid the re= sulting priority inversion. The absence of unassigned codepoints in Pool 1 = that exhibit these important properties motivates assigning a Pool 3 codepo= int as the default that is recommended for use with this PHB.
---

- Your thoughts please, I'll hold publishing the new revision until I h= ear from you,

I don't object= to the new text, but it looks like there's still some mailing list tra= ffic on this draft - I'll go read that next.

I= f you do the right thing, that will be fine with me, of course ...

Having caught up on the mai= ling list traffic, I still think you're doing the right thing.

Thanks!

Spencer
=C2=A0<= /div>
Spencer
=C2=A0<= br>
Gorry

On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote:

On Tue, May 8, 2018 at 9:00 AM, David Black <david.black@dell.com <mailto:david.black@dell.com= >> wrote:

=C2=A0 =C2=A0 David Black has requested publication of
=C2=A0 =C2=A0 draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Stand= ard on
=C2=A0 =C2=A0 behalf of the TSVWG working group.

=C2=A0 =C2=A0 Please verify the document's state at
=C2=A0 =C2=A0 https://datatrack= er.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/
=C2=A0 =C2=A0 <https://datat= racker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/><= br>

I have a couple of comments, but this draft is ready for Last Call. Could y= ou take a look at my comments, and let me know what the right thing to do i= s?

Thanks!

Spencer

=C2=A0There's a reference to https://tools.ietf.o= rg/html/rfc8126#section-4.9 in the Introduction, but that text use= s "Standards Action" with the reference but without any expansion= , while further down, the next occurrence of "Standards Action" e= xplains that this means "values are assigned by Standards Track or Bes= t Current Practice RFCs", without providing a reference. Perhaps expan= ding
=C2=A0 =C2=A0These are assigned by
=C2=A0 =C2=A0Standards Action, as defined in [RFC8126].

to read

=C2=A0 =C2=A0These are assigned by
=C2=A0 =C2=A0Standards Action, as defined in [RFC8126], i.e., values are as= signed
=C2=A0 =C2=A0by Standards Track or Best Current Practice RFCs

and dropping the expansion from the second mention would be clearer?

Independent of that question, I had to read through the text containing the= second mention a couple of times.

=C2=A0 Although Pool 1 has not yet been completely exhausted, this document=
=C2=A0 =C2=A0changes the IANA registration policy of Pool 3 to assignment b= y
=C2=A0 =C2=A0Standards Action, i.e., values are assigned by Standards Track= or
=C2=A0 =C2=A0Best Current Practice RFCs.=C2=A0 The rationale for this updat= e is a need
=C2=A0 =C2=A0to assign codepoints for particular PHBs that are unable to us= e any
=C2=A0 =C2=A0of the unassigned values in Pool 1.

Would it be correct to say

=C2=A0 Although Pool 1 has not yet been completely exhausted, there is a ne= ed
=C2=A0 =C2=A0to assign codepoints for particular PHBs that are unable to us= e any
=C2=A0 =C2=A0of the unassigned values in Pool 1. This document
=C2=A0 =C2=A0changes the IANA registration policy of Pool 3 to assignment b= y
=C2=A0 =C2=A0Standards Action, i.e., values are assigned by Standards Track= or
=C2=A0 =C2=A0Best Current Practice RFCs, allowing these codepoints to be as= signed.

?



--0000000000002cc2fc056bcaf643-- From nobody Thu May 10 00:40:24 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF4126CC7; Thu, 10 May 2018 00:40:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152593801818.10463.16553178199650978943@ietfa.amsl.com> Date: Thu, 10 May 2018 00:40:18 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-iana-dscp-registry-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 07:40:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC Author : Godred Fairhurst Filename : draft-ietf-tsvwg-iana-dscp-registry-05.txt Pages : 7 Date : 2018-05-10 Abstract: The Differentiated Services (Diffserv) architecture specifies use of a field in the IPv4 and IPv6 packet headers to carry Diffserv Codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the Codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-iana-dscp-registry-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-dscp-registry-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 10 01:19:37 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2DE12AAB6 for ; Thu, 10 May 2018 01:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 GGM-Z-WlFjRl for ; Thu, 10 May 2018 01:19:33 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.4]) (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 16315126DFB for ; Thu, 10 May 2018 01:19:32 -0700 (PDT) Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-central-1.aws.symcld.net id 98/7E-30567-39004FA5; Thu, 10 May 2018 08:19:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTW0gUURjHPTOz61hOTruaX6KFGxFUs7lluBZ CEJEUUQ9BtN0ct8ldWkfbmS01AsMSSi2RNvMS7eYWVOJDNwx7SEstu2JqV7PSwtLKtOhmbjN7 tOw8HH58//93OYdzaFI3oI2ihSxZcIq8w6CdQMXHLtnElQR9scQN+GeaP5dXUea+/ApkHiwu1 Zib+ju1S6jkkrJjZHLhUC+R7PP9IJI93lpyDWXR2MXUjKwUje17/+bMqoso68NdP5WLTh1HB9 EEmmLzSfjxxBd8EIXQOraCgN+laaqgY18j8N7OR6qgZZPg/LlOrcrh7Gx4lHedVJlkc+Dnha4 A69kN0F90icCejXA5rw1htkB9x5FAnGJnwr1PjYE4w6ZAY127BjcroKDz5DtKFUJYHvqaDmhU RuwU+NZSTeBmkfC050SAgWXBd/U+iTkC3nWPjPpToeuNF+F4LBx7URmMOQZaTxQEjgzsZQKG9 /4aFTgYcLuVQrTCM+Bi7ybs6UBw5lc3geNzoeZxErZnwIOCsmDsKUJQf/jnaLNpcLboFYW5mY QbRVacGw29t6dgf7sWjt7tIvBVW+Fm5RBVjLjycWcrV1JIVoTm+2HlgTuaDLfKeihsmQueukE t5jlw2ttHjvGda93E+LgHBZ9FialOe5pNTuftDs4UF8eZTAu4+ZwpIcHI53C8UXBxVkGUnbyi GvldklHKTrc6thpFQT6PlBcXpKxa1NVkbUBTacIQwZS1DVp0k1IztmbbeMm2xelyCFIDiqZpA zCcf8iim+wU0oSsbXaH8mzHZKBDDeHM6RFFZqRMPl2yp2GpBSXSDZ+OFJL0vcD+1ucuJHWUmC EKUZHMQrUeqybYXOLfcmMfoRXFROkZpAyoC80UnOl2+X/9PYqkkUHP7FSrhNpF+W/X98pAhDJ QfXtgIJn/J0XlopQnsQm7d7jDVpI1E/MkeSSF6VvxvEM3g0MPQk5K8+dd2Vxiy2vz75v3UV+a n/1wcIMrp3jPan3Q7rXi/mrOMcvlu2pzcLXWo95V5nUh0yd2J5461DrnbXz0lTvPvi6O3760O vemfdkiz4Kq9e7lZzy/nbUx/rrhGkGmhlpehn3+aqAkG2+aTTol/g9aNevDAwQAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-228.messagelabs.com!1525940366!617407!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 8059 invoked from network); 10 May 2018 08:19:29 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-11.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 10 May 2018 08:19:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WAe88zt0EnQ0zJBJ/21yfNsQBqQzih+YKdnW7xiSdAM=; b=ZInSGAQEPX4ds4EKs2LdTRbaGOgFkgCMMbU5a9g/lXtnt7QtAk80SmWfyj4SR7v7zzeuJi5bfLpHTVQ3/DxvHthlDOzFYDJDyr6p5bMMAGQoysuyCmgKWli+LM5Vi9Ry4EULmocS9oTL1P5th6jDMSUP2caMnGx255w3algBRo0= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2023.eurprd03.prod.outlook.com (10.167.227.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.18; Thu, 10 May 2018 08:19:25 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::fdb3:6753:a5e:5909%14]) with mapi id 15.20.0735.021; Thu, 10 May 2018 08:19:25 +0000 From: Alexander Vainshtein To: Gorry Fairhurst CC: "Black, David" , "tsvwg@ietf.org" , "Bless, Roland (TM)" Thread-Topic: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 Thread-Index: AdPmoFK9aWKmiaf9TbeUMDqszKs2hwADjKcAAAmz/VAAAX/kAAAAL+oAAAhIzQAAAd2OFwBMr9OQ Date: Thu, 10 May 2018 08:19:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB2023; 7:Oj5T/Dwj+nyvmBYtX1Bd8M+g8BfcmPqeghKb7/o+feYKiUfGB4olyKiZo05J4UamF9fEnO17cwMvJMYBnHgK1Ba23FDW5YB+0L61KKat2w/2K/lYNGmE4Ju1ztJy1MqHDHdSUyj9yoAWrUie53LA3QrM7+xKgaim244AoqpclRNG89UWGy4GXLqz6b8DGICu8jgcZnFbN0I+5E0ySPEbuW4N7VMCFZJWivNyv3j6iRkfFfNQxL60c0HgbzD1ZMoy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2023; x-ms-traffictypediagnostic: DB5PR0301MB2023: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(130329453890623)(21748063052155)(279101305709854)(56004941905204); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DB5PR0301MB2023; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2023; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(346002)(39380400002)(13464003)(252514010)(189003)(199004)(606006)(53546011)(59450400001)(11346002)(102836004)(7696005)(6506007)(186003)(76176011)(54906003)(68736007)(2906002)(3280700002)(14454004)(476003)(486006)(446003)(99286004)(3660700001)(26005)(5003630100001)(296002)(316002)(478600001)(6436002)(229853002)(2900100001)(6916009)(966005)(72206003)(97736004)(25786009)(86362001)(5250100002)(6246003)(4326008)(106356001)(66066001)(53936002)(81166006)(7736002)(8676002)(81156014)(74316002)(105586002)(5660300001)(8936002)(93886005)(6306002)(9686003)(3846002)(6116002)(790700001)(8666007)(33656002)(236005)(55016002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2023; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VT9GDIl5IAMWoTX6oL2+f7jOzckqbgODG9xfBXZQT3GUYV81i9EaUPzBCQ83G56TbXVV/coHfuQAELjLrmpe+tlNmcpESgS0mj36uF6/gu32J2FwmGDpZnH0V/dpvJ/VXuS5ZcYuRU8nVWzoA2QvLoLYK0E2K1S01vQp9jGTHrhwSg7w8XwR+7vQgU+JTOyI spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909D6B0AB6DE1E9450802BD9D980DB5PR0301MB1909_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8bdbec7c-8ef4-4bdb-856e-08d5b64ebde0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bdbec7c-8ef4-4bdb-856e-08d5b64ebde0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 08:19:25.1168 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2023 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 08:19:36 -0000 --_000_DB5PR0301MB1909D6B0AB6DE1E9450802BD9D980DB5PR0301MB1909_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gorry and all, I have looked up the -05 revision of the draft, and it provides a reasonab= le explanation of motivation. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Tuesday, May 8, 2018 10:42 PM To: Gorry Fairhurst Cc: Black, David ; tsvwg@ietf.org; Bless, Roland (TM= ) Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 Gorry, Providing additional context including explicit description of bleaching o= f the IP Precedence bits would surely help. Thumb typed by Sasha Vainshtein From: Gorry Fairhurst Sent: Tuesday, May 8, 21:49 Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-= dscp-registry-04 To: Alexander Vainshtein Cc: Black, David, tsvwg@ietf.org, Bless, Roland (TM= ) Hi, Maybe I can provide a little more context about other unallocated valu= es in the registry. Each request for a new DSCP needs to be considered car= efully and separately looking at the implications on both the deployed use= of Codepoints and the needs for the PHB. As it happens, the unassigned DS= CPs in pool 1 could well remain useful for any new PHBs- if any new ones a= re approved by TSVWG that can be bleached to default (BE) - the case for m= ost currently defined PHBs. I expect the new pool will be only used by IAN= A requests from TSVWG when there is a case for not using any of the remain= ing pool 1 values. That case has been made for the LE PHB. There could pot= entially be other allocations in the future, but that is none are currentl= y considered. Gorry Sent from my iPad > On 8 May 2018, at 15:55, Alexander= Vainshtein wrote: > > David, > Lots of thanks for a very detailed explana= tion. > > Coming back to my original doubt, , changing the IANA allocation= policy on Pool 3 (16 values) in order to make just one value standard sti= ll looks an exaggeration to me. > What are we going to do with the remaini= ng 15 values? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-= 549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Black, David [= mailto:David.Black@dell.com] > Sent: Tuesday, May 8, 2018 5:46 PM > To: Al= exander Vainshtein ; Bless, Roland (TM) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: RE= : [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-regist= ry-04 > > Writing as an individual, not WG chair ... > >> It provides a wo= rkaround for the IP precedence bleaching for LE >> traffic that you want t= o introduce - but what about all other PHBs? > > The concern is not about = what happens in Diffserv domains/regions that are updated to implement sup= port for the new LE PHB, but what happens when that LE PHB traffic transit= s through routers elsewhere that bleach IP Precedence. > > Right now IP Pr= ecedence bleaching tends to result in best effort service, which is ok, al= beit not ideal. If IP Precedence bleaching could result in a DSCP for the = LE PHB, the result downstream of the bleaching could be worse than best ef= fort service for a DSCP that was intended to obtain better than best effor= t service - that is the priority inversion that we're trying to avoid. > >= > Would they not require some intelligent rewrite of the DSCP when >> traf= fic enters the bleaching domain? > > Unfortunately, that's wishful thinkin= g, IMHO. IP Precedence bleaching already violates a bunch of RFCs, dating = back to RFC 2474. We can write what we like in a new RFC, but that "runnin= g code" in deployed routers isn't going to magically stop bleaching IP Pre= cedence just because we publish a new RFC. > > Thanks, --David > >> -----O= riginal Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Beh= alf Of Alexander >> Vainshtein >> Sent: Tuesday, May 8, 2018 10:08 AM >> T= o: Bless, Roland (TM) >> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org >> Subject: Re: [tsvwg] Doubts= regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registry-04 >> = >> Ronald, >> Lots of thanks for a prompt response. >> >> I have to admit = that your explanation looks problematic to me. >> It provides a workaround= for the IP precedence bleaching for LE >> traffic that you want to introd= uce - but what about all other PHBs? >> Would they not require some intell= igent rewrite of the DSCP when >> traffic enters the bleaching domain? >> = And if so, why should not the same approach be used for LE in this domain?= >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-5492663= 02 >> Email: Alexander.Vainshtein@ecitele.com >> >> >> -----Original Message----- >> From: Bless, Roland (T= M) [mailto:roland.bless@kit.edu] >> Sent: Tuesday, May 8, 2018 12:26 PM >>= To: Alexander Vainshtein ; >> gorry@erg.abdn.ac.uk >> Cc: tsvwg@ietf.org >> Subject: Re: [tsvwg= ] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- >> dscp-registr= y-04 >> >> Hi Sasha, >> >>> Am 08.05.2018 um 09:56 schrieb Alexander Vains= htein: >>> I have looked up the draft >>> >>> , and I have doubts regardin= g validity of its motivation. >>> >>> The draft says - correctly -that 22 = out of 32 values in Pool 1 of >>> the DSCP code points have been already a= ssigned, therefore it >>> considers this pool as nearly exhausted. >>> >>>= What the draft does not say that, out of these 22 assignments, 2o >>> hav= e been done in 1998 and one - in 1999. Only one assignment has >>> been re= quested in the past 19 years, and no assignments have been >>> requested a= fter 2010. >> >>> At this rate my estimate is that Pool 1 would suffice fo= r the next >>> 50+ years without its exhaustion becoming an issue. So why = should >>> the IETF do anything */now/*? >> >> This is motivated in sectio= n 1: >> >> The rationale for this update is a need >> to assign codepoints= for particular PHBs that are unable to use any >> of the unassigned value= s in Pool 1. >> >> This problem=20is caused by implementations that do IP = precedence >> bleaching (i.e., zeroing the top three bits of the DSCP) the= reby >> rewriting (or unintentionally mapping) DSCP values to other DSCP >= > values. This is a problem for the mentioned LE PHB I-D >> https://tools.= ietf.org/html/draft-ietf-tsvwg-le- >> phb >> It is possible that some othe= r standardized DSCPs get mapped to the LE >> PHB DSCP if the LE DSCP were = taken from the DSCP standards action pool >> 1 (xxxxx0). >> >> There are m= easurements and more background material for this: >> https://datatracker.= ietf.org/meeting/99/materials/slides-99-tsvwg-sess >> b- >> 31measurements= -concerning-the-dscp-for-a-le-phb-00 >> https://www.ietf.org/proceedings/9= 6/slides/slides-96-maprg-6.pdf >> >> Regards, >> Roland >> >> ____________= ______________________________________________ >> _________________ >> >> = This e-mail message is intended for the recipient only and contains >> inf= ormation which is CONFIDENTIAL and which may be proprietary to ECI >> Tele= com. If you have received this transmission in error, please >> inform us = by e-mail, phone or fax, and then delete the original and >> all copies th= ereof. >> __________________________________________________________ >> __= _______________ > > ______________________________________________________= _____________________ > > This e-mail message is intended for the recipien= t only and contains information which is > CONFIDENTIAL and which may be p= roprietary to ECI Telecom. If you have received this > transmission in err= or, please inform us by e-mail, phone or fax, and then delete the original= > and all copies thereof. > _____________________________________________= ______________________________ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_DB5PR0301MB1909D6B0AB6DE1E9450802BD9D980DB5PR0301MB1909_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gorry and all,

I have looked up the -05 revision o= f the draft, and it provides a reasonable explanation of motivation.<= /o:p>

 

Regards,

Sasha

 

Office: +972-39266302

Cell:     = +972-549266302

Email:   Alexander.Vainsh= tein@ecitele.com

 

From: Alexander Vainshtein
Sent: Tuesday, May 8, 2018 10:42 PM
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Black, David <david.black@dell.com>; tsvwg@ietf.org; Bles= s, Roland (TM) <roland.bless@kit.edu>
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvw= g-iana-dscp-registry-04

 

Gorry,

Providin= g additional context including explicit description of bleaching of the IP= Precedence bits would surely help.

Thumb typed by Sasha Vainshtein



From: Gorry Fairhurst=

Sent: Tuesday, May 8, 21:49<= /span>

Subject: Re: [tsvwg] Doubts regarding m= otivation of draft-ietf-tsvwg-iana-dscp-registry-04

To: Alexander Vainshtein

Cc: Blac= k, David, tsvwg@ietf.org, Bless, Roland (TM)

Hi, Mayb= e I can provide a little more context about other unallocated values in th= e registry. Each request for a new DSCP needs to be considered carefully and separately looking at the implications on both t= he deployed use of Codepoints and the needs for the PHB. As it happens, th= e unassigned DSCPs in pool 1 could well remain useful for any new PHBs- if= any new ones are approved by TSVWG that can be bleached to default (BE) - the case for most currently define= d PHBs. I expect the new pool will be only used by IANA requests from TSVW= G when there is a case for not using any of the remaining pool 1 values. T= hat case has been made for the LE PHB. There could potentially be other allocations in the future, but that is n= one are currently considered. Gorry Sent from my iPad > On 8 May 2018, = at 15:55, Alexander Vainshtein wrote: > > David, > Lots of thanks= for a very detailed explanation. > > Coming back to my original doubt, , changing the IANA allocation policy on Pool 3 (16= values) in order to make just one value standard still looks an exaggerat= ion to me. > What are we going to do with the remaining 15 values? >= > Regards,=20> Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message-= ---- > From: Black, David [mail= to:David.Black@dell.com] > Sent: Tuesday, May 8, 2018 5:46 PM > = To: Alexander Vainshtein ; Bless, Roland (TM) > Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: RE: [tsvwg] Doubts regarding motivation o= f draft-ietf-tsvwg-iana-dscp-registry-04 > > Writing as an individua= l, not WG chair ... > >> It provides a workaround for the IP prec= edence bleaching for LE >> traffic that you want to introduce - but what about all other PHBs? > > The concern is not about what = happens in Diffserv domains/regions that are updated to implement support = for the new LE PHB, but what happens when that LE PHB traffic transits thr= ough routers elsewhere that bleach IP Precedence. > > Right now IP Precedence bleaching tends to result in best effor= t service, which is ok, albeit not ideal. If IP Precedence bleaching could= result in a DSCP for the LE PHB, the result downstream of the bleaching c= ould be worse than best effort service for a DSCP that was intended to obtain better than best effort service - that= is the priority inversion that we're trying to avoid. > >> Would= they not require some intelligent rewrite of the DSCP when >> traff= ic enters the bleaching domain? > > Unfortunately, that's wishful thinking, IMHO. IP Precedence bleaching already violates a= bunch of RFCs, dating back to RFC 2474. We can write what we like in a ne= w RFC, but that "running code" in deployed routers isn't going t= o magically stop bleaching IP Precedence just because we publish a new RFC. > > Thanks, --David > >> ---= --Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Alexander &g= t;> Vainshtein >> Sent: Tuesday, May 8, 2018 10:08 AM >> To= : Bless, Roland (TM) >> Cc: g= orry@erg.abdn.ac.uk; tsvwg@ietf.org >> Subject: Re:= [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- &g= t;> dscp-registry-04 >> >> Ronald, >> Lots of thanks = for a prompt response. >> >> I have to admit that your explana= tion looks problematic to me. >> It provides a workaround for the IP precedenc= e bleaching for LE >> traffic that you want to introduce - but what = about all other PHBs? >> Would they not require some intelligent rew= rite of the DSCP when >> traffic enters the bleaching domain? >> And if so, why should not the same approach be used for = LE in this domain? >> >> Regards, >> Sasha >> >= > Office: +972-39266302 >> Cell: +972-549266302 >> = Email: Alexander.Vainshtein@e= citele.com >> >> >> -----Original Message----- >&= gt; From: Bless, Roland (TM) [mail= to:roland.bless@kit.edu] >> Sent: Tuesday, May 8, 2018 12:26 PM >> To: Alexander Vainshtein ; >> gorry@erg.abdn.ac.uk >> Cc: tsvwg@ietf.org >> Subject: Re:= [tsvwg] Doubts regarding motivation of >> draft-ietf-tsvwg-iana- &g= t;> dscp-registry-04 >> >> Hi Sasha, >> >>> = Am 08.05.2018 um 09:56 schrieb Alexander Vainshtein: >>> I have l= ooked up the draft >>> >>> , and I have doubts regarding validity of its m= otivation. >>> >>> The draft says - correctly -that 22 o= ut of 32 values in Pool 1 of >>> the DSCP code points have been a= lready assigned, therefore it >>> considers this pool as nearly e= xhausted. >>> >>> What the draft does not say that, out of these 22 assignments, 2o >>= ;> have been done in 1998 and one - in 1999. Only one assignment has &g= t;>> been requested in the past 19 years, and no assignments have be= en >>> requested after 2010. >> >>> At this rate m= y estimate is that Pool 1 would suffice for the next >>> 50+ years with= out its exhaustion becoming an issue. So why should >>> the IETF = do anything */now/*? >> >> This is motivated in section 1: >= ;> >> The rationale for this update is a need >> to assign = codepoints for particular PHBs that are unable to use any >> of the unassigned val= ues in Pool 1. >> >> This problem is caused by implementations= that do IP precedence >> bleaching (i.e., zeroing the top three bit= s of the DSCP) thereby >> rewriting (or unintentionally mapping) DSCP values to other DSCP >> values. This=20is a problem for the me= ntioned LE PHB I-D >> https://tools= .ietf.org/html/draft-ietf-tsvwg-le- >> phb >> It is possib= le that some other standardized DSCPs get mapped to the LE >> PHB DS= CP if the LE DSCP were taken from the DSCP standards action pool >> 1 (xxxxx0). >> >> There are measurements and mo= re background material for this: >> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sess= >> b- >> 31measurements-concerning-the-dscp-for-a-le-phb-00 &= gt;> https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf &g= t;> >> Regards, >> Roland >> >> _______________= ___________________________________________ >> _________________ >= ;> >> This e-mail message is intended for the recipient only and conta= ins >> information which is CONFIDENTIAL and which may be proprietar= y to ECI >> Telecom. If you have received this transmission in error= , please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> ___________= _______________________________________________ >> _________________= > > _______________________________________________________________= ____________ > > This e-mail message is intended for the recipient only and contains information which is > CONFIDENTIAL and which may be= proprietary to ECI Telecom. If you have received this > transmission i= n error, please inform us by e-mail, phone or fax, and then delete the ori= ginal > and all copies thereof. > __________________________________= _________________________________________


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_DB5PR0301MB1909D6B0AB6DE1E9450802BD9D980DB5PR0301MB1909_-- From nobody Thu May 10 21:20:49 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763FD12D86F for ; Thu, 10 May 2018 21:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 dYzm2gKxi2mi for ; Thu, 10 May 2018 21:20:46 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 960BB12D86D for ; Thu, 10 May 2018 21:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+HTcCTqqsiVUoapOIZBqFY8KsRuBBwzUYanxdU/SvJk=; b=lctdNAd49hBULy12QRbJ+ujBG XG3s0U0fJBhaphn7AXFVBXzcRIvg66nJCOuCyB7VVWleriNY4Hp0Dz6Hckg2W6PvUikoIeuo8m1y6 lIZcrep7ByfE4Jwf+2EfWIzi887/z2cvA2Tj1eRk/2HOYqYBlR5Zs6bGPUrdao5tXXMJR19PT2QrF IkRTGQuYj8U+p+VgOKjJJG1EghSaYWR/WLq/NKaBW35iR7FLB9VVoMu6bjCWCxfr+udXe+C4pJMDq R/uybjjKyrzVAkKf66XL9O93KQoik8dMLQNssBh1WXy4w6E4f0tfgWOQffr0SwS/rW+RbZB2l5JKT bKnlE52+g==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51438 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fGzXu-004BTg-1t; Fri, 11 May 2018 00:20:42 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Joe Touch In-Reply-To: <5ACC6E04.8070107@erg.abdn.ac.uk> Date: Thu, 10 May 2018 21:20:40 -0700 Cc: "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <152334654802.13452.17469061242049682843.idtracker@ietfa.amsl.com> <5ACC6E04.8070107@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3445.6.18) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 04:20:48 -0000 Hi, Gorry, et al., I disagree with the tone and focus of this document. It appears to give many reasons why hiding transport info from on-path = observers is bad - bad for the network, bad for operators, and bad for = everyone. It reads like an Orwellian propaganda brochure on how Big Brother is = only here to help - won=E2=80=99t you leave the cameras on? The doc fails to recognize: - the fact that encryption (via tunneling, esp) is already = undermining a lot of this sort of =E2=80=9Chelp=E2=80=9D=20 - the fact that users can - and should - find a lot of what = passes for =E2=80=9Chelp=E2=80=9D quite a bit creepy - the fact that transport protocols were never intended to have = any meaning anywhere but the endpoints and that, in fact, that=E2=80=99s the only place where = they do have meaning anyway If this doc goes forward, I sincerely hope there will be a more balanced = presentation of the CONS of the kind of on-path snooping of traffic that = this document largely presents as beneficial. Joe =E2=80=94=E2=80=94=E2=80=94 Some details follow: - the title and abstract focus on transport header confidentiality; this = begs the need for sections 3.1, 3.2, and parts of 3.4 - which have = nothing to do with *transport header* confidentiality - the doc reports in other ways to address transport encryption = in general; that=E2=80=99s a much larger issue to include, with entirely = different implications - the doc speaks of ossification as if it is only harmful; that same = ossification provides the stability on which other upper layer protocols = often rely, so having a =E2=80=9Cstable=E2=80=9D (ossified) protocol = could be considered an advantage too (beyond merely allowing in-network = devices to predict their location) - I disagree that encryption of transport headers would prevent = ossification; they could similarly be ossified by being the only ones = supported using encryption at the endpoints - the doc focuses on the impact of transport header encryption on a = number of =E2=80=9Cfeatures=E2=80=9D that have emerged, but fails to = address whether those =E2=80=9Cfeatures=E2=80=9D are desirable (i.e., = just because we CAN do certain things, and HAVE DONE certain things, is = independent of whether we should continue to design protocols to support = those things) - the intro fails to address the valid privacy motivations for obscuring = transport information, esp. given transport protocols are themselves = meaningful ONLY at the endpoints e.g., I could easily modify two hosts to exchange packets that = look like UDP but are actually TCP this is akin to port renumbering at the endpoints fundamentally, in the Internet, transport headers have meaning = ONLY at the two endpoints engaging in a given communication, so we = really are =E2=80=9Cliving on borrowed time=E2=80=9D to assume that = in-network devices can - or should - be able to interpret them at all, = even when they appear not to be encrypted - I do NOT agree of nearly anything in section 2.1, especially as it is = then used to justify the remainder of section 2 this entire section reads a lot like =E2=80=9Cthe government = needs to track your every move so we can build better roads for you=E2=80=9D= ; it=E2=80=99s quite creepy. - section 3 omits discussions of encrypted tunnels (IPsec or otherwise), = all of which obscure access to transport headers - sec 3.2 (if retained, and I hope it is not), should include tcp-ao-enc = (yes, still a draft, but relevant to the discussion if retained) - sec 3 omits TCPcrypt too (not sure where to put it because I haven=E2=80= =99t cared to track how it has (d)evolved). - not sure I agree that the transport layer is the first end-to-end = interaction across the Internet; the same is true for the IP layer (esp, = e.g., IPv6 Destination Options, among other things). - finally, this doc seems oblivious to the reality that encryption is = coming, like it or not - esp across the backbone, and that this has been = the case for a while now (with VPNs) ---- From nobody Fri May 11 03:07:47 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88EE12D947 for ; Fri, 11 May 2018 03:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 M_i4kLUqMFOh for ; Fri, 11 May 2018 03:07:28 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 653F0127078 for ; Fri, 11 May 2018 03:07:28 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 666511B00243; Fri, 11 May 2018 11:07:26 +0100 (BST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 0827C232F4; Fri, 11 May 2018 06:07:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 11 May 2018 06:07:25 -0400 X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 68AED102C7; Fri, 11 May 2018 06:07:24 -0400 (EDT) Date: Fri, 11 May 2018 11:07:32 +0100 From: Tom Jones To: "C. M. Heard" Cc: Joe Touch , tsvwg Message-ID: <20180511100731.GA886@tom-desk.erg.abdn.ac.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 10:07:47 -0000 Hi Mike, inline On Sun, May 06, 2018 at 10:23:54AM -0700, C. M. Heard wrote: > Greetings, > > Some issues came to my attention during a recent off-list discussion with > someone from the DNS community. > > Section 5.4, Alternate Checksum (ACS): since the option area is not > included in the ACS, the following text seems out of place: > > When ACS is computed, its checksum (CRC) area is zeroed. No other > options are zeroed before computing ACS. I need some clarification on this too. > > All that is needed is to stuff the remainder of the standard polynomial > long division in the ACS checksum area. > > There are also some issues that need to nailed down for clarity. the usual > way that the specified polynomial is used is to invert the first 16 bits of > data and transmit the complement of the resulting polynomial division. If > that is not done here, it would probably be good to say so. Also, it is > necessary to specify whether the data polynomial is constructed as if the > bytes are transmitted most significant bit first or least significant bit > first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be > 0x11021, but that fact is not needed, and I recommend omitting it). The currect text on the OCS says the checksum is not inverted, this should be added here as well. > Section 5.5, LITE option: the following instruction > > 3. Swap all four bytes of the LITE option with the first 4 bytes of > the LITE data area (Figure 11). > > > works only if the LITE data area is at least four bytes long. However, the > option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one > simply moves the option to the start of the LITE data area and moves the > displaced LITE bytes just past the end of the relocated LITE option. This > operation is then reversed on the receive side. In effect, one is swapping > the locations of the LITE option and the initial segment of the LITE data > area of length min(4, LITE offset). A UDP Lite region greater than 0 must be a minimum of 8 octets. A Checksum Coverage of zero indicates that the entire UDP-Lite packet is covered by the checksum. This means that the value of the Checksum Coverage field MUST be either 0 or at least 8. So only the 0 coverage case must be considered by this document. > Note that being able to use the LITE option with a length of zero is > important for option negotiation. > - [tj] From nobody Fri May 11 08:08:28 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3075612D94E; Fri, 11 May 2018 08:08:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk CC: tsvwg@ietf.org, draft-ietf-tsvwg-iana-dscp-registry@ietf.org, david.black@dell.com, spencerdawkins.ietf@gmail.com, David Black , tsvwg-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152605130717.10585.16213085554793884117.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2018 08:08:27 -0700 Archived-At: Subject: [tsvwg] Last Call: (IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 15:08:27 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-05-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Differentiated Services (Diffserv) architecture specifies use of a field in the IPv4 and IPv6 packet headers to carry Diffserv Codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the Codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3260: New Terminology and Clarifications for Diffserv (Informational - IETF stream) From nobody Fri May 11 13:12:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579A612D881; Fri, 11 May 2018 13:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sunTJ9FcLAjm; Fri, 11 May 2018 13:12:37 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81DB126E64; Fri, 11 May 2018 13:12:33 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p144-v6so1936049ywg.7; Fri, 11 May 2018 13:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nEIo5l1dz2H/hmg65HrIRUk+msuIaYKQ/ITRPZHGE7o=; b=Wip/otS8g+ZsMNdSz1om/PJm9ZqKn2DlxaZMTl6w97eVu20PwMdbVxEmQ8aPm9Iql8 FUcZ8HHkeaHTuTa6owhOSBPpWVUeIKxZNivIs09V6xHpA49ZV4duTIG+63RtYQVBHPNi C4eBUCUhMhY1A+QUj++ZbnhQdEc2T/1IjvPD9rX+8PdlRT0J25nv3FradTvgHSGqV+FN h8/5C/XwdwZcmMtrYUpLgTECkN+pmRmu9NlR5/+4sbcmMxjOeyAwczbxVnrUrYZ/ia2d PrXUCLgMHX4R/AfF1mnet0/w6B0lCmfxlL3h7sqFs7WnZf2SRttG3jz8Xl8XSaXW3zWH fxtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nEIo5l1dz2H/hmg65HrIRUk+msuIaYKQ/ITRPZHGE7o=; b=a+KEd8v80uJ5upKEWpHiERIkyJ+9cM9rsBVuwo//lHje5sRsmhwIjBUG1GOuzY+YoM +KAIt074bauAk04DuXbWJn+3rVR3d9zDNl3N6rihvm3HH8U7LliGo2/meB6EFD1uDoD4 H6QpmdTwLnlRHZcSEzjnyEXQgKitstQOnp3Ay/rxc7lCh462/P7pP4aHX/l/sbz84T6O bI4/WtGY8KuGki64ouJXKIW+K71TYi5KPbC26V4s1eO4wTW9ad4TUXSjuaD4F/E5e3EW kOXZEaNNGhdoKQxexq5c5mZCY6+O6AZ45GSrab+s7y2Wu4tqURONP4JzTfEXx6FS7f2Q T5uQ== X-Gm-Message-State: ALKqPwcDwFO13r+9Pzng1AiIXX3vlVGn4kj5EEw+YU0Ud1nS+2485MC5 1yGdraGviFUIMJljPCbWfZwT3V3x+HJeD2476nfRCA== X-Google-Smtp-Source: AB8JxZrOo8MtNljdB1N2keHf3YMySAx4rrz+DI6uovHGGGv+XU5NQuorQrRwAMhcow1Nm/kI7i4JIy3w0e70UkKGAaM= X-Received: by 2002:a0d:e8c2:: with SMTP id r185-v6mr239761ywe.27.1526069552556; Fri, 11 May 2018 13:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Fri, 11 May 2018 13:12:31 -0700 (PDT) In-Reply-To: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 11 May 2018 15:12:31 -0500 Message-ID: To: draft-ietf-tsvwg-rfc4960-errata@ietf.org Cc: tsvwg-chairs , tsvwg@ietf.org, Gorry Fairhurst Content-Type: multipart/alternative; boundary="000000000000953e12056bf3c1f5" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 20:12:39 -0000 --000000000000953e12056bf3c1f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Authors, On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst wrote: > Gorry Fairhurst has requested publication of draft-ietf-tsvwg-rfc4960-err= ata-05 > as Informational on behalf of the TSVWG working group. > > Please verify the document's state at https://datatracker.ietf.org/ > doc/draft-ietf-tsvwg-rfc4960-errata/ Thanks for doing this work (and even more so, for being willing to provide an updated RFC to implementers, at some point in the future). I've completed AD evaluation for this draft, and have comments, but almost all of them are requests for clarifications. I'd like to work through them with you before requesting Last Call. Please let me know if you have questions. Thanks! Spencer A high-order bit here ... I'm not sure why this draft isn't standards-track, and I wonder if there's a reason it doesn't UPDATE RFC 4960, unless that's a side effect of being an Informational draft that would update a standards-track RFC. I'm thinking that this draft has achieved WG consensus, and if it's published after Last Call, it would have IETF consensus, and it's been reviewed by implementers. We've certainly published Proposed Standards that didn't measure up to that level of document quality. I'm not objecting strongly to publishing as Informational, but I am saying that I expect other ADs to ask that question during IESG Evaluation, and I'd like to understand the thinking before someone asks =E2=80=A6 I note without suggesting a change that if the material in Section 3 was presented in this order 3.n.1 Description of the Problem 3.n.3. Solution Description 3.n.2. Text Changes to the Document --------- Old text: --------- --------- New text: --------- to allow readers to see the solution description before reading the detailed text changes, that would likely be easier to parse ... I'm reading this text from the Abstract Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. as saying that the deltas are cumulative, so you should apply the last change to specific text, but this text from Section 1 Note that when reading this document one must use care to assure that a field or item is not updated further on within the document. Each section should be applied in sequence to the original [RFC4960] since this document is a historical record of the sequential changes that have been found necessary at various inter-op events and through discussion on the list. seems to say that you should apply multiple deltas to the same text sequentially. IIUC, the text actually does provide cumulative text deltas, so using the phrasing from the Abstract in both places would be helpful to the reader. This is a nit, but why is "Inconsistent" capitalized in this text? The handling of the 'Path.Max.Retrans' parameter is described in Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-ts= vwg-rfc4960-errata-05.txt reports a few problems with references. I THINK this is a side effect of updating (for example) [RFC2434] to be [RFC5226], and then updating [RFC5226] to be [RFC8126]. If this was my draft, I'd put a note to the RFC Editor that obsoleted RFCs are used in "OLD TEXT" sections, and should have the obsoleting RFCs in the "NEW TEXT" sections, so multiple reviewers won't ask you about the IDNIT reporting multiple times. I'm probably due for an eye exam, but I'm not seeing any difference between --------- Old text: (Section 1.6) --------- Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN =3D 2*32 - 1 is TSN =3D 0. and --------- New text: (Section 1.6) --------- Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN =3D 2**32 - 1 is TSN =3D 0. What am I missing? In this text, Move the sample code related to CRC32c computation and its explanation from the end of Appendix C to the end of Appendix B. I'm pretty sure I can figure out what text/code actually moves from Appendix C to Appendix B, but I am figuring that out myself. Perhaps it would be clearer if you said something like "all of Appendix C starting with this sentence to the end of Appendix B". The following non-normative sample code is taken from an open-source CRC generator [WILLIAMS93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide. (If I guessed wrong, that's likely because the fix says "code and its explanation", which sounds like "everything following the beginning of the code", but the explanation comes before the code) If I'm following closely, the errata described as Section 7.2.2 of [RFC4960] is unclear about the order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance phase. is actually clear about the order - assuming that you read left to right, it's just clearly wrong :-) At the risk of asking a technical question ;-) The counter SHOULD be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK). When a HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD also be reset. The receiver of the HEARTBEAT ACK MAY choose not to clear the counter if there is outstanding data on the association. This allows for handling the possible difference in reachability based on DATA chunks and HEARTBEAT chunks. why is not clearing the counter if there is outstanding data on the association a good idea? (this was "shall", but is now "SHOULD") I have a similar (MUST vs. SHOULD) question about Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT SHOULD clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. Why would not clearing the error counter be a good idea? Section 3.21 has multiple occurrences of something like o partial flag - if this returned flag is set to 1, then this Receive contains a partial delivery of the whole message. When ^ this "Receive" is capitalized this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates ^ this "receive" is not capitalized that no more deliveries will be received for this Stream Sequence Number. Is that intentional? --000000000000953e12056bf3c1f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,

On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <gorry@er= g.abdn.ac.uk> wrote:
Gorry Fairhurst has requested publication of draft-ietf-tsvwg-= rfc4960-errata-05 as Informational on behalf of the TSVWG working grou= p.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-= errata/

Thanks for doing this work (and= even more so, for being willing to provide an updated RFC to implementers,= at some point in the future).=C2=A0

I've comp= leted AD evaluation for this draft, and have comments, but almost all of th= em are requests for clarifications.=C2=A0

I'd = like to work through them with you before requesting Last Call. Please let = me know if you have questions.

Thanks!
<= br>
Spencer=C2=A0

A high-order bit here ...=C2=A0

I'm not sure why this draft isn't standards-track, and = I wonder if there's a reason it doesn't UPDATE RFC 4960, unless tha= t's a side effect of being an Informational draft that would update a s= tandards-track RFC.=C2=A0

I'm think= ing that this draft has achieved WG consensus, and if it's published af= ter Last Call, it would have IETF consensus, and it's been reviewed by = implementers. We've certainly published Proposed Standards that didn= 9;t measure up to that level of document quality.

I'm not objecting strongly to publishing as Informational, b= ut I am saying that I expect other ADs to ask that question during IESG Eva= luation, and I'd like to understand the thinking before someone asks = =E2=80=A6

<= /div>
I note without suggesting a c= hange that if the material in Section 3 was presented in this order<= /div>

3.n.1=C2=A0 =C2=A0Description of the Problem

<= font face=3D"monospace, monospace">
3.n.3.=C2=A0 Solution Description

3.n.2.=C2=A0 Text Changes to the Document

=C2=A0 =C2=A0---------
=C2=A0 =C2=A0Old text:
=C2=A0 =C2=A0---------

=C2=A0 =C2=A0New text:
=C2=A0 =C2=A0---------

to allow rea= ders to see the solution description before reading the detailed text chang= es, that would likely be easier to parse ...

I'm reading this text from the Abstract=C2=A0

=C2=A0 =C2=A0Because some text is changed several times th= e last delta in the
= =C2=A0 =C2=A0text is the one which should be applied.=C2=A0 In addition to = the delta a
=C2=A0 =C2= =A0description of the problem and the details of the solution are also
=C2=A0 =C2=A0provided.

as saying that the deltas are cumulative, = so you should apply the last change to specific text, but this text from Se= ction 1=C2=A0

=C2=A0 Note that when rea= ding this document one must use care to assure that
=C2=A0 =C2=A0a field or item is not updated f= urther on within the document.=C2=A0 Each
=C2=A0 =C2=A0section should be applied in sequence to t= he original [RFC4960] since
=C2=A0 =C2=A0this document is a historical record of the sequential c= hanges that
=C2=A0 =C2= =A0have been found necessary at various inter-op events and through<= /div>
=C2=A0 =C2=A0discussion on th= e list.

seems to say that you should apply multiple deltas to the same text sequen= tially. IIUC, the text actually does provide cumulative text deltas, so usi= ng the phrasing from the Abstract in both places would be helpful to the re= ader.

This is a nit, but why is "I= nconsistent" capitalized in this text?

=C2=A0 The handling of the 'Path.Max.Retrans' parameter is des= cribed in
=C2=A0 =C2= =A0Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way.<= /div>

https:= //tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-tsvwg-rf= c4960-errata-05.txt reports a few problems with references. I THINK thi= s is a side effect of updating (for example) [RFC2434] to be [RFC5226], and= then updating [RFC5226] to be [RFC8126].=C2=A0If this was my draft, I'd put a note to the = RFC Editor that obsoleted RFCs are used in "OLD TEXT" sections, a= nd should have the obsoleting RFCs in the "NEW TEXT" sections, so= multiple reviewers won't ask you about the IDNIT reporting multiple ti= mes.

=
I'm probably due for an eye ex= am, but I'm not seeing any difference between=C2=A0

=C2=A0 ---------
=C2=A0 =C2=A0Old text: (Section 1.6)
=C2=A0 =C2=A0---------

=C2=A0 =C2=A0Transmission Sequence Numbers wrap around when they= reach 2**32 - 1.
=C2= =A0 =C2=A0That is, the next TSN a DATA chunk MUST use after transmitting TS= N =3D
=C2=A0 =C2=A02*3= 2 - 1 is TSN =3D 0.
and

=C2=A0 =C2=A0---------
=C2=A0 =C2=A0New text: (Section 1.6)
=C2=A0 =C2=A0---------

=C2=A0 =C2=A0Transmission Sequence Numbers wrap around= when they reach 2**32 - 1.
=C2=A0 =C2=A0That is, the next TSN a DATA chunk MUST use after transm= itting TSN =3D
=C2=A0 = =C2=A02**32 - 1 is TSN =3D 0.

What am I= missing?

<= /div>
In this text,=C2=A0

=C2=A0 Move the sample code related to CRC32c co= mputation and its
=C2= =A0 =C2=A0explanation from the end of Appendix C to the end of Appendix B.<= /font>

= I'm pretty sure I can figure out wh= at text/code actually moves from Appendix C to Appendix B, but I am figurin= g that out myself. Perhaps it would be clearer if you said something like &= quot;all of Appendix C starting with this sentence to the end of Appendix B= ".

=C2=A0 =C2=A0The following non-= normative sample code is taken from an open-source
=C2=A0 =C2=A0CRC generator [WILLIAMS93], using= the "mirroring" technique and
=C2=A0 =C2=A0yielding a lookup table for SCTP CRC32c wit= h 256 entries, each 32
=C2=A0 =C2=A0bits wide.

(If I guessed = wrong, that's likely because the fix says "code and its explanatio= n", which sounds like "everything following the beginning of the = code", but the explanation comes before the code)

If I'm following closely, the errata described as=C2=A0=

=C2=A0 Section 7.2.2 of [RFC4960] is u= nclear about the order of adjustments
=C2=A0 =C2=A0applied to partial_bytes_acked and cwnd in the= congestion avoidance
= =C2=A0 =C2=A0phase.
is actually clear a= bout the order - assuming that you read left to right, it's just clearl= y wrong :-)

At the risk of asking a tec= hnical question ;-)
=C2=A0 The counter = SHOULD be reset each time a DATA chunk sent to that peer
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0endpoint is acknowledged (b= y the reception of a SACK). When a
=C2=A0 =C2=A0HEARTBEAT ACK is received from the peer endpoint,= the counter SHOULD
= =C2=A0 =C2=A0also be reset. The receiver of the HEARTBEAT ACK MAY choose no= t to
=C2=A0 =C2=A0clea= r the counter if there is outstanding data on the association.
=
=C2=A0 =C2=A0This allows for handl= ing the possible difference in reachability
=C2=A0 =C2=A0based on DATA chunks and HEARTBEAT chunk= s.

why is not clearing the counter if t= here is outstanding data on the association a good idea? (this was "sh= all", but is now "SHOULD")

I have a similar (MUST vs. SHOULD) question about=C2=A0

=C2=A0 Upon the receipt of the HEARTBEAT ACK, the sende= r of the HEARTBEAT
=C2= =A0 =C2=A0SHOULD clear the error counter of the destination transport addre= ss
=C2=A0 =C2=A0to whi= ch the HEARTBEAT was sent, and mark the destination transport
<= div>=C2=A0 =C2=A0address as active if i= t is not so marked.
Why would not clear= ing the error counter be a good idea?

S= ection 3.21 has multiple occurrences of something like=C2=A0

=C2=A0 o=C2=A0 partial flag - if this returned flag i= s set to 1, then this
= =C2=A0 =C2=A0 =C2=A0 Receive contains a partial delivery of the whole messa= ge.=C2=A0 When
=C2=A0 = =C2=A0 =C2=A0 ^ this "Receive" is capitalized

=C2=A0 =C2=A0 =C2=A0 this flag is set, the stream id and S= tream Sequence Number MUST
=C2=A0 =C2=A0 =C2=A0 accompany this receive.=C2=A0 When this flag is s= et to 0, it indicates
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0^ this "receive" is not capitalized

=C2=A0 =C2=A0 =C2=A0 that no more deliveries will be received for= this Stream Sequence
= =C2=A0 =C2=A0 =C2=A0 Number.

Is that in= tentional?
--000000000000953e12056bf3c1f5-- From nobody Sat May 12 00:16:30 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E095612E741; Sat, 12 May 2018 00:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YRKIIyOlS007; Sat, 12 May 2018 00:16:27 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 24DC412D945; Sat, 12 May 2018 00:16:27 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 5BD3E1B0010D; Sat, 12 May 2018 08:16:06 +0100 (BST) Message-ID: <5AF694B5.6050109@erg.abdn.ac.uk> Date: Sat, 12 May 2018 08:16:05 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Spencer Dawkins at IETF CC: draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 - Document Status X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 07:16:30 -0000 On the document status: This draft is specifically to catalogue all the changes proposed for the SCTP base spec. The authors plan to then implement these changes as a textual update to RFC 4960 to realise a new completely clean base specification. Once this is done the present ID will exist only as a record of what has changed. This process was successfully used for other SCTP documents and was the rationale for the present ID requesting publication as a Information specification. This was in part explained in section 1 of the writeup - should it also be said in the ID?... There was clear consensus when this ID was adopted that the plan was to finaly provide an update to RFC 4960. I expect the authors to comment on your comments, then update their draft. best wishes, Gorry (as document shepherd for draft-ietf-tsvwg-rfc4960-errata) On 11/05/2018, 21:12, Spencer Dawkins at IETF wrote: > Dear Authors, > > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst > wrote: > > Gorry Fairhurst has requested publication of > draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of > the TSVWG working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ > > > > Thanks for doing this work (and even more so, for being willing to > provide an updated RFC to implementers, at some point in the future). > > I've completed AD evaluation for this draft, and have comments, but > almost all of them are requests for clarifications. > > I'd like to work through them with you before requesting Last Call. > Please let me know if you have questions. > > Thanks! > > Spencer > > A high-order bit here ... > > I'm not sure why this draft isn't standards-track, and I wonder if > there's a reason it doesn't UPDATE RFC 4960, unless that's a side > effect of being an Informational draft that would update a > standards-track RFC. > > I'm thinking that this draft has achieved WG consensus, and if it's > published after Last Call, it would have IETF consensus, and it's been > reviewed by implementers. We've certainly published Proposed Standards > that didn't measure up to that level of document quality. > > I'm not objecting strongly to publishing as Informational, but I am > saying that I expect other ADs to ask that question during IESG > Evaluation, and I'd like to understand the thinking before someone asks … > From nobody Sun May 13 19:47:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A15E128954; Sun, 13 May 2018 19:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPD5W2Fatrt0; Sun, 13 May 2018 19:47:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C041250B8; Sun, 13 May 2018 19:47:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u83-v6so3174130ywc.4; Sun, 13 May 2018 19:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QCvZzbPuX46ijgQe6/PdgCgW4LZ7ERuXelIns0oYoek=; b=VoanDer1VQsAOkLFRXX0dEJ770j+Se5HMAynOK54jCtDaZFyj1UOsQAq9PgFx2IPs3 mO3S3+eGl+2q8zgmdd4fRKNYndifBvAl6qzKJfFLwKszU4Bht/57CPgiCqbGTfsE7R0S 1mHlP46dSBdC7m1+bCpcg97sV7HGWrLOGQ8jwJcgvD+jkJbwkwYYZQtobWS9ocx8V7+X 1AdZsktiSshRg+7YB/eXZ13eowHda4H8pgvIAR0o8WgSwuq6mmuYmp62Ke1zQXwmi98X LO2b+JAdXc3cwPUMipjLUrIAFPKAY/7KsPoVO3SgZpc6ebhdln8olCaSl66CaGvrS/tr x4JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QCvZzbPuX46ijgQe6/PdgCgW4LZ7ERuXelIns0oYoek=; b=apBU4eg46CdT3bVmCh+VTUuc1bG4OHeFL+yIZ4SBqTpLr1S7KA6l/nuayL51R0Lmfg IhrI0GC1TM3dYF2g8hTfM8nMoNPd2jNrJrDF7x3XsYDmhIhKnQOXzsYYuTQvz/gl7JMz wCtAXvZNeoXp31536L5tkGQTCJMkiTASgdgoMlPZfQiiuYpEWTvUMbJvAxUTSAO5Yd2y Pbzcm4hNWUPK5miogb/RbF+UEO5C5airQV2L1zxAXiJmq4PfFZZi/ctAZ7LY2m+WCLwm PLvcS9qsJZyNwnJkGmFTdChwKPlTklm14xz6tnqOCi9yMmHAxRXLbBRxFN4MMo6q8jWo 5xKQ== X-Gm-Message-State: ALKqPwcuqJ8+6B0gY/3NqahVv/X4WEfA82yBag0kYkuqQN+eoW2ZlrjL TVSeiLNT2FpSetOVLAIh9lt16WBxuvDT+v5BoFo= X-Google-Smtp-Source: AB8JxZrjSrkmHLn07H+5ixEGZe2BBUMk/s0aIO4Qkx/J0O5cdNobw0Os8QCtd7gcli+hsJpxsQIXng4Rof97pgWkR0A= X-Received: by 2002:a0d:ed06:: with SMTP id w6-v6mr3581294ywe.467.1526266053385; Sun, 13 May 2018 19:47:33 -0700 (PDT) MIME-Version: 1.0 References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> <5AF694B5.6050109@erg.abdn.ac.uk> In-Reply-To: <5AF694B5.6050109@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Sun, 13 May 2018 21:47:20 -0500 Message-ID: To: G Fairhurst Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000f1e601056c2181cf" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 - Document Status X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 02:47:37 -0000 --000000000000f1e601056c2181cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Gorry, On Sat, May 12, 2018, 02:16 Gorry Fairhurst wrote: > On the document status: > > This draft is specifically to catalogue all the changes proposed for the > SCTP base spec. The authors plan to then implement these changes as a > textual update to RFC 4960 to realise a new completely clean base > specification. Once this is done the present ID will exist only as a > record of what has changed. This process was successfully used for other > SCTP documents and was the rationale for the present ID requesting > publication as a Information specification. > > This was in part explained in section 1 of the writeup - should it also > be said in the ID?... There was clear consensus when this ID was adopted > that the plan was to finaly provide an update to RFC 4960. > That's probably not necessary, now that I understand the theory behind this draft. > I expect the authors to comment on your comments, then update their draft= . > Excellent! Spencer best wishes, > > Gorry > (as document shepherd for draft-ietf-tsvwg-rfc4960-errata) > > On 11/05/2018, 21:12, Spencer Dawkins at IETF wrote: > > Dear Authors, > > > > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst > > wrote: > > > > Gorry Fairhurst has requested publication of > > draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of > > the TSVWG working group. > > > > Please verify the document's state at > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ > > > > > > > > Thanks for doing this work (and even more so, for being willing to > > provide an updated RFC to implementers, at some point in the future). > > > > I've completed AD evaluation for this draft, and have comments, but > > almost all of them are requests for clarifications. > > > > I'd like to work through them with you before requesting Last Call. > > Please let me know if you have questions. > > > > Thanks! > > > > Spencer > > > > A high-order bit here ... > > > > I'm not sure why this draft isn't standards-track, and I wonder if > > there's a reason it doesn't UPDATE RFC 4960, unless that's a side > > effect of being an Informational draft that would update a > > standards-track RFC. > > > > I'm thinking that this draft has achieved WG consensus, and if it's > > published after Last Call, it would have IETF consensus, and it's been > > reviewed by implementers. We've certainly published Proposed Standards > > that didn't measure up to that level of document quality. > > > > I'm not objecting strongly to publishing as Informational, but I am > > saying that I expect other ADs to ask that question during IESG > > Evaluation, and I'd like to understand the thinking before someone asks= =E2=80=A6 > > > > --000000000000f1e601056c2181cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Gorry,

On Sat, May 12, 2018, 02:16 Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On the document status:

This draft is specifically to catalogue all the changes proposed for the SCTP base spec. The authors plan to then implement these changes as a
textual update to RFC 4960 to realise a new completely clean base
specification. Once this is done the present ID will exist only as a
record of what has changed. This process was successfully used for other SCTP documents and was the rationale for the present ID requesting
publication as a Information specification.

This was in part explained in section 1 of the writeup - should it also be said in the ID?... There was clear consensus when this ID was adopted that the plan was to finaly provide an update to RFC 4960.
=

That's probab= ly not necessary, now that I understand the theory behind this draft.
=


I expect the authors to comment on your comments, then update their draft.<= br>

E= xcellent!

Spencer
<= div dir=3D"auto">
best wishes,

Gorry
(as document shepherd for draft-ietf-tsvwg-rfc4960-errata)

On 11/05/2018, 21:12, Spencer Dawkins at IETF wrote:
> Dear Authors,
>
> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <gorry@erg.abdn.= ac.uk
> <mailto:gorry@erg.abdn.ac.uk>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Gorry Fairhurst has requested publication of
>=C2=A0 =C2=A0 =C2=A0draft-ietf-tsvwg-rfc4960-errata-05 as Informational= on behalf of
>=C2=A0 =C2=A0 =C2=A0the TSVWG working group.
>
>=C2=A0 =C2=A0 =C2=A0Please verify the document's state at
>=C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/
>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/&g= t;
>
>
> Thanks for doing this work (and even more so, for being willing to > provide an updated RFC to implementers, at some point in the future).<= br> >
> I've completed AD evaluation for this draft, and have comments, bu= t
> almost all of them are requests for clarifications.
>
> I'd like to work through them with you before requesting Last Call= .
> Please let me know if you have questions.
>
> Thanks!
>
> Spencer
>
> A high-order bit here ...
>
> I'm not sure why this draft isn't standards-track, and I wonde= r if
> there's a reason it doesn't UPDATE RFC 4960, unless that's= a side
> effect of being an Informational draft that would update a
> standards-track RFC.
>
> I'm thinking that this draft has achieved WG consensus, and if it&= #39;s
> published after Last Call, it would have IETF consensus, and it's = been
> reviewed by implementers. We've certainly published Proposed Stand= ards
> that didn't measure up to that level of document quality.
>
> I'm not objecting strongly to publishing as Informational, but I a= m
> saying that I expect other ADs to ask that question during IESG
> Evaluation, and I'd like to understand the thinking before someone= asks =E2=80=A6
>

--000000000000f1e601056c2181cf-- From nobody Tue May 15 18:42:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7B12E8DD for ; Tue, 15 May 2018 18:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 iD1va_Kp44C5 for ; Tue, 15 May 2018 18:42:36 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17465126FB3 for ; Tue, 15 May 2018 18:42:36 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id l132-v6so1892871qke.3 for ; Tue, 15 May 2018 18:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=5IlvANdekTQ6mTZVucS7CMhDV2eKhRtvAl1VC8959vY=; b=SDW2iMDU6DcMxWHmjfYYG37jL8QTKilNT3sU+PAEE/bI6jXMyZzNMsP6MDgMAmFryS bLz9nJi3WruTwLNMPJEGw9qmBHltMK+W1Ai5O262QjM3lGHXePj76Jb3AWx2hmdgN80b 0RsCvfmdnBaXhWqsFMFclLX3TGMVf1Baa0TofFtnnYNRzIfDA5n3mqKDt28UYqtMrbDO dd2Y2TNz5CkJgr/TVRZJxY/vF1NxZ1YPMKTSSub4PAvljyMe5RuzmA6BownVpaQXWy8H VNDw85usgHyjm+3UBOgmXtrko9CQrCKs1OFfrlNphe24n1wM2XthP6aZDD1Z51SuebBC xEGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=5IlvANdekTQ6mTZVucS7CMhDV2eKhRtvAl1VC8959vY=; b=Ue96G3PXTLHejiktLotLGgg2TEU6iotm3gpdKj9+HpYQsVg93yNLc75Y+EgZbinXO/ Z7amArObIvEREsSh6vRpm/Ldc9YOWSyRe5wwQxZ9v/zxgETgr5GBJ/Fe+yc6rTDmuFxN nYcKmSh58a70pLGjhPu/2AKjc0urPr3HIHUh18AqnCgrZmv8x0HGE9dROlgDKJhuckss f4V/6himGjz6JGuRbgnVkYj1aPIunyEJe5QTeQdZQ+IQW1L7QpKOl6G5pzeJfBVRflqi 50ECqwBlnRHpCNr+OE5zdr3xe7NXPuWNw/VVxpuYJA5ddyfRtvudlcJBx5Po3p5yawuY /ECQ== X-Gm-Message-State: ALKqPwdyvh94jhdbVOVq5J0esPhfT8XKkQiUmy7VxdABXUkCwFThHbMI U8YNQ/bxQ5ubYzY5bnbvjLzjNBzDY60= X-Google-Smtp-Source: AB8JxZqtzID6+2eXaKZXTJHMId+KjhOGuMF2He38SUL2RCz7hSOJ/6LAZMbSpcDNLA7h23SAqjnyWg== X-Received: by 2002:a37:5cc5:: with SMTP id q188-v6mr14450675qkb.29.1526434955305; Tue, 15 May 2018 18:42:35 -0700 (PDT) Received: from [192.168.1.17] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id h6-v6sm1072741qtb.69.2018.05.15.18.42.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 18:42:34 -0700 (PDT) From: Wesley Eddy To: "tsvwg@ietf.org" Cc: nwcrg@irtf.org References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> Message-ID: Date: Tue, 15 May 2018 21:42:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> Content-Type: multipart/alternative; boundary="------------85333FF5745A019DBB114479" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] WGLC on FECFRAME sliding window extensions and RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 01:42:38 -0000 This is a multi-part message in MIME format. --------------85333FF5745A019DBB114479 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/17/2018 12:30 AM, Wesley Eddy wrote: > (on behalf of all three TSVWG chairs) > > This email is to start a TSVWG working group last call on the sliding > window FECFRAME extensions, and random linear code FEC scheme drafts: > > (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ > > (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ > > ... > Many thanks for the couple of technical reviews that were submitted (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in response. Since this is work for standards track, I think we really need to get a bit more feedback though. In order to get more reviews, and give people time to look at the updated drafts, so will plan to keep the WGLC open for a couple more weeks in order to give more time for reviews. *Please provide comments on the updated documents by 5/29.* Thanks in advance. --------------85333FF5745A019DBB114479 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 4/17/2018 12:30 AM, Wesley Eddy wrote:
(on behalf of all three TSVWG chairs)

This email is to start a TSVWG working group last call on the sliding window FECFRAME extensions, and random linear code FEC scheme drafts:

(1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/

(2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/

...



Many thanks for the couple of technical reviews that were submitted (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in response.

Since this is work for standards track, I think we really need to get a bit more feedback though.

In order to get more reviews, and give people time to look at the updated drafts, so will plan to keep the WGLC open for a couple more weeks in order to give more time for reviews.  Please provide comments on the updated documents by 5/29.

Thanks in advance.
--------------85333FF5745A019DBB114479-- From nobody Wed May 16 22:53:12 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE41312E8EF for ; Wed, 16 May 2018 22:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 sCaM05_lMgYp for ; Wed, 16 May 2018 22:52:52 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 42FDE12EA8D for ; Wed, 16 May 2018 22:52:52 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 1A5111B0015C; Thu, 17 May 2018 06:52:15 +0100 (BST) Message-ID: <5AFD188F.2050309@erg.abdn.ac.uk> Date: Thu, 17 May 2018 06:52:15 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kathleen Moriarty CC: tsvwg@ietf.org, Colin Perkins References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 05:53:10 -0000 Thanks Kathleen, it really helps to receive reviews, I'll try to respond to each in turn. On 08/05/2018, 18:22, Kathleen Moriarty wrote: > Hello Gorry& Colin, > > Thanks for your work on this draft. In my opinion, it is very > important to dig through the implications of encrypting transport > headers. The document is well written and easy to read, thanks for > that as well. Al and I had a hard time with that since ours was > contribution driven and controversial. > > Here's some feedback from my review that I hope you find helpful: > > General: > If you added section references to mm-wg-encrypt where it is > referenced, that may be helpful to the reader. I have now tried to do this where I could. > Specific feedback: > The apps side will object to this phrasing as they don't see the need > for any 'help'. I agree with your point, just warning of the obstacle > in case you can reword it to prevent objections. > Choosing to encrypt all information may reduce > the ability for networks to "help" (e.g., in response to tracing > issues, making appropriate QoS decisions). We aded more clarity on the ability for networks to "help" users and subscribers. > Section 3 intro text > > Encrypted traffic can also be profiled to identify threat actors. > This will continue to be important as threat actors may have advanced > capabilities and may modify the encrypted streams in identifiable ways > that can differentiate their traffic from others. > > I was expecting to see some text toward the end of 3 on adoption of > these protocols. We can put out protocols, but it's up to industry to > decide when and where to adopt protocols. I'd be happy to improve this section, but at the moment I'm unsure what you have in mind. > From a few recent talks, > what I saw from the audiences is that those aware of QUIC are outright > blocking it. The business imperative is not there for the > applications using QUIC to justify it's use within the business > network, at least not yet. Indeed. I have seen similar talks and discussions that take this view. We are trying to the base the draft on what has been deployed and approaches that have been used - do you think we could/should say more? > Section 3.3 > Do you want to make this specific to IPsec tunnel mode since that > hides the true end points as well? Transport mode isn't well deployed > because of interoperability issues and not current use case driving > it's usage, but that does leave the true IP source and destination > addresses exposed, more than what you see with tunnel mode. Yes. I have done this. > Section 5.3 > This is starting to touch on NetNeutrality and if you are going to go > there, you should state it explicitly. At the enterprise level (it > doesn't seem like you are covering that in this draft), I am hearing > QUIC is outright blocked by those that are aware of it on the network, > so it's not just NetNeutrality that will impact it's deployment. > Perhaps rephrasing may help? Here's the text I'm talking about: > A lack of data reduces the level of precision with which mechanisms > are applied, and this needs to be considered when evaluating the > impact of designs for transport encryption. This could lead to > increased use of rate limiting, circuit breaker techniques [RFC8084], > or even blocking of uncharacterised traffic. This would hinder > deployment of new mechanisms and/or protocols. I would love a suggestion? > Section 5.4 > I think you have a typo here: > Integrity checks can undetected modification of protocol fields by > network devices, Indeed, and now resolved. Gorry From nobody Thu May 17 01:16:09 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5109812EA59 for ; Thu, 17 May 2018 01:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 C-gqU9N6xQSe for ; Thu, 17 May 2018 01:15:58 -0700 (PDT) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3D112EA58 for ; Thu, 17 May 2018 01:15:58 -0700 (PDT) Received: from smtp-secu-int (smtp-secu-int.isae.fr [10.132.1.48]) by smtpextng.isae.fr (Postfix) with ESMTP id 6FE9D71265; Thu, 17 May 2018 10:15:56 +0200 (CEST) Received: from [10.161.131.30] (disc-detchart.isae.fr [10.161.131.30]) by smtp-secu-int (Postfix) with ESMTPSA id 69E3025D35A; Thu, 17 May 2018 10:15:56 +0200 (CEST) To: Wesley Eddy , "tsvwg@ietf.org" Cc: nwcrg@irtf.org References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> From: Jonathan DETCHART Message-ID: <4b35a291-f5da-f878-a21f-e05211a55b8e@isae-supaero.fr> Date: Thu, 17 May 2018 10:16:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------940B2E3011B1515B3E2E2955" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 08:16:03 -0000 This is a multi-part message in MIME format. --------------940B2E3011B1515B3E2E2955 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I read the draft-ietf-tsvwg-rlc-fec-scheme. 2 typo : - p3, $1.2. : "the Sliding Window Random Linear Codes (RLC) over either Finite Field GF(2) or GF(8)". Should it be GF(2^8)? - p22, $7 : "Lincencing" -> "Licencing" As the document "introduces two fully-specified FEC Schemes". Considering the field GF(2^8), it can be implemented in several ways, depending on the irreducible polynomial that is used and the implementation (xor-based representation or polynomial representation with lookup tables or not). All the implementations are not compatible. So, how do the encoder and decoder agree on the field and the implementation used to be compatible? Do they exchange some parameters? Should the document propose a default configuration for that? I suggest the document propose a default specification for galois field arithmetic: it should give the irreducible polynomial used (like in the rfc 5510), and the implementation to use. For gf(2^8), a lookup table implementation (with optional SIMD vector instructions) seems to be the best on most devices : http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html Jonathan DETCHART On 16/05/2018 03:42, Wesley Eddy wrote: > On 4/17/2018 12:30 AM, Wesley Eddy wrote: >> (on behalf of all three TSVWG chairs) >> >> This email is to start a TSVWG working group last call on the sliding >> window FECFRAME extensions, and random linear code FEC scheme drafts: >> >> (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ >> >> (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ >> >> ... >> > > > Many thanks for the couple of technical reviews that were submitted > (Emmanuel and Gorry), and to Vincent for quickly updating the drafts > in response. > > Since this is work for standards track, I think we really need to get > a bit more feedback though. > > In order to get more reviews, and give people time to look at the > updated drafts, so will plan to keep the WGLC open for a couple more > weeks in order to give more time for reviews. *Please provide comments > on the updated documents by 5/29.* > > Thanks in advance. > > > _______________________________________________ > nwcrg mailing list > nwcrg@irtf.org > https://www.irtf.org/mailman/listinfo/nwcrg --------------940B2E3011B1515B3E2E2955 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I read the draft-ietf-tsvwg-rlc-fec-scheme.

2 typo : 

- p3, $1.2. : "the Sliding Window Random Linear Codes (RLC) over either Finite Field GF(2) or GF(8)". Should it be GF(2^8)?

- p22, $7 : "Lincencing" -> "Licencing"


As the document "introduces two fully-specified FEC Schemes". Considering the field GF(2^8), it can be implemented in several ways, depending on the irreducible polynomial that is used and the implementation (xor-based representation or polynomial representation with lookup tables or not). All the implementations are not compatible.

So, how do the encoder and decoder agree on the field and the implementation used to be compatible? Do they exchange some parameters? Should the document propose a default configuration for that?

I suggest the document propose a default specification for galois field arithmetic: it should give the irreducible polynomial used (like in the rfc 5510), and the implementation to use. For gf(2^8), a lookup table implementation (with optional SIMD vector instructions) seems to be the best on most devices : http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html

Jonathan DETCHART
On 16/05/2018 03:42, Wesley Eddy wrote:
On 4/17/2018 12:30 AM, Wesley Eddy wrote:
(on behalf of all three TSVWG chairs)

This email is to start a TSVWG working group last call on the sliding window FECFRAME extensions, and random linear code FEC scheme drafts:

(1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/

(2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/

...



Many thanks for the couple of technical reviews that were submitted (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in response.

Since this is work for standards track, I think we really need to get a bit more feedback though.

In order to get more reviews, and give people time to look at the updated drafts, so will plan to keep the WGLC open for a couple more weeks in order to give more time for reviews.  Please provide comments on the updated documents by 5/29.

Thanks in advance.


_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg

--------------940B2E3011B1515B3E2E2955-- From nobody Thu May 17 04:07:33 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76D12D7E4 for ; Thu, 17 May 2018 04:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EF4YtGJIrbOC for ; Thu, 17 May 2018 04:07:31 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 6359512D77B for ; Thu, 17 May 2018 04:07:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,410,1520895600"; d="scan'208,217";a="327279091" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2018 13:07:27 +0200 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_62550B0A-598A-4830-8BD3-4968CB98453C" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 17 May 2018 13:07:27 +0200 In-Reply-To: <4b35a291-f5da-f878-a21f-e05211a55b8e@isae-supaero.fr> Cc: Vincent Roca , Wesley Eddy , "tsvwg@ietf.org" , nwcrg@irtf.org To: Jonathan DETCHART References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> <4b35a291-f5da-f878-a21f-e05211a55b8e@isae-supaero.fr> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 11:07:33 -0000 --Apple-Mail=_62550B0A-598A-4830-8BD3-4968CB98453C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jonathan, Excellent comments! We need to clarify the Finite Field used, I agree. Here is a new section to address this comment: NEW: 3.6. Finite Fields Operations The two RLC FEC Schemes specified in this document reuse the Finite Fields defined in [RFC5510], section 8.1. More specifically, the elements of the field GF(2^^m) are represented by polynomials with binary coefficients (i.e., over GF(2)) and degree lower or equal to m-1. The addition between two elements is defined as the addition of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation on the binary representation of these elements. With GF(2^^8), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial MUST be used for GF(2^^8): x^^8 + x^^4 + x^^3 + x^^2 + 1 With GF(2), multiplication corresponds to a logical AND operation. The reference to (the excellent) Plank=E2=80=99s research report is = already in version -03. The two typos are fixed. We=E2=80=99ll submit a new -04 version with the above corrections plus = an improved section 3.1. Possible Parameter Derivations. More to come = soon... Cheers, Vincent and Belkacem > Le 17 mai 2018 =C3=A0 10:16, Jonathan DETCHART = a =C3=A9crit : >=20 > I read the draft-ietf-tsvwg-rlc-fec-scheme. > 2 typo :=20 >=20 > - p3, $1.2. : "the Sliding Window Random Linear Codes (RLC) over = either Finite Field GF(2) or GF(8)". Should it be GF(2^8)? > - p22, $7 : "Lincencing" -> "Licencing" >=20 >=20 > As the document "introduces two fully-specified FEC Schemes". = Considering the field GF(2^8), it can be implemented in several ways, = depending on the irreducible polynomial that is used and the = implementation (xor-based representation or polynomial representation = with lookup tables or not). All the implementations are not compatible. > So, how do the encoder and decoder agree on the field and the = implementation used to be compatible? Do they exchange some parameters? = Should the document propose a default configuration for that? >=20 > I suggest the document propose a default specification for galois = field arithmetic: it should give the irreducible polynomial used (like = in the rfc 5510), and the implementation to use. For gf(2^8), a lookup = table implementation (with optional SIMD vector instructions) seems to = be the best on most devices : = http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html = > Jonathan DETCHART > On 16/05/2018 03:42, Wesley Eddy wrote: >> On 4/17/2018 12:30 AM, Wesley Eddy wrote: >>> (on behalf of all three TSVWG chairs)=20 >>>=20 >>> This email is to start a TSVWG working group last call on the = sliding window FECFRAME extensions, and random linear code FEC scheme = drafts:=20 >>>=20 >>> (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ = =20 >>>=20 >>> (2) = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ = =20 >>>=20 >>> ... >>>=20 >>=20 >>=20 >> Many thanks for the couple of technical reviews that were submitted = (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in = response. >>=20 >> Since this is work for standards track, I think we really need to get = a bit more feedback though. >>=20 >> In order to get more reviews, and give people time to look at the = updated drafts, so will plan to keep the WGLC open for a couple more = weeks in order to give more time for reviews. Please provide comments = on the updated documents by 5/29. >>=20 >> Thanks in advance. >>=20 >>=20 >> _______________________________________________ >> nwcrg mailing list >> nwcrg@irtf.org >> https://www.irtf.org/mailman/listinfo/nwcrg = >=20 > _______________________________________________ > nwcrg mailing list > nwcrg@irtf.org > https://www.irtf.org/mailman/listinfo/nwcrg --Apple-Mail=_62550B0A-598A-4830-8BD3-4968CB98453C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jonathan,

Excellent comments! We need to clarify the Finite Field = used, I agree.
Here is a new section to address this = comment:


NEW:

3.6.  Finite = Fields Operations

   The two RLC FEC Schemes specified in this = document reuse the Finite
   Fields = defined in [RFC5510], section 8.1.  More specifically, = the
   elements of the field GF(2^^m) are = represented by polynomials with
   binary = coefficients (i.e., over GF(2)) and degree lower or equal to
   m-1.  The addition between two elements is = defined as the addition of
   binary = polynomials in GF(2), which is equivalent to a bitwise XOR
   operation on the binary representation of these = elements.

 =  With GF(2^^8), multiplication between two elements is = the
   multiplication modulo a given = irreducible polynomial of degree 8.
  =  The following irreducible polynomial MUST be used for = GF(2^^8):

 =     x^^8 + x^^4 + x^^3 + x^^2 + 1

   With GF(2), multiplication = corresponds to a logical AND operation.

The reference to (the excellent) = Plank=E2=80=99s research report is already in version -03.
The two typos are fixed.


We=E2=80=99ll submit a new -04 version with the above = corrections plus an
improved section 3.1. =  Possible Parameter Derivations. More to come soon...


Cheers,

  Vincent and Belkacem


Le 17 mai 2018 =C3=A0 10:16, Jonathan = DETCHART <jonathan.detchart@isae-supaero.fr> a =C3=A9crit = :

=20 =20

I = read the draft-ietf-tsvwg-rlc-fec-scheme.

2 typo : 

- p3, $1.2. : "the = Sliding Window Random Linear Codes (RLC) over either Finite Field GF(2) or GF(8)". Should it be GF(2^8)?

- p22, $7 : "Lincencing" -> "Licencing"


As the document "introduces two fully-specified = FEC Schemes". Considering the field GF(2^8), it can be implemented in several ways, depending on the irreducible polynomial that is used and the implementation (xor-based representation or polynomial representation with lookup tables or not). All the implementations are not compatible.

So, how do the encoder and decoder agree on the = field and the implementation used to be compatible? Do they exchange some parameters? Should the document propose a default configuration for that?

I suggest the document propose a = default specification for galois field arithmetic: it should give the irreducible polynomial used (like in the rfc 5510), and the implementation to use. For gf(2^8), a lookup table implementation (with optional SIMD vector instructions) seems to be the best on most devices : htt= p://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html

Jonathan DETCHART
On 16/05/2018 03:42, Wesley Eddy = wrote:
On 4/17/2018 12:30 AM, Wesley Eddy wrote:
(on behalf of all three TSVWG chairs)

This email is to start a TSVWG working group last call on the sliding window FECFRAME extensions, and random linear code FEC scheme drafts:

(1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg= -fecframe-ext/

(2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg= -rlc-fec-scheme/

...



Many thanks for the couple of technical reviews that were submitted (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in response.

Since this is work for standards track, I think we really need to get a bit more feedback though.

In order to get more reviews, and give people time to look at the updated drafts, so will plan to keep the WGLC open for a couple more weeks in order to give more time for reviews.  Please provide comments on the updated documents by 5/29.

Thanks in advance.


_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/=
mailman/listinfo/nwcrg

_______________________________________________
nwcrg = mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg

= --Apple-Mail=_62550B0A-598A-4830-8BD3-4968CB98453C-- From nobody Thu May 17 06:06:08 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C6012DA29 for ; Thu, 17 May 2018 06:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3_OnyrDIPak for ; Thu, 17 May 2018 06:06:03 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E037212DB6D for ; Thu, 17 May 2018 06:06:02 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 140-v6so1418102ybc.9 for ; Thu, 17 May 2018 06:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=szQvB25rWTfgKGVeuukV9DTCNKDDzXBprqDpXTvOqKQ=; b=Yr4+eTV0GOQ7WdDcPR6knyMs6g+ik7npcSLJvz3tvnUD4D6SuA8PvLK1F2AFx38gz5 GdoH7ggs/kCBZxVME+PtKjp9RoVcYqF0nwL9faRJdsXUH435DHCAXYlkpd7kh+VxxW5u tDP0wzXQZ4rJfAelpn7TyE7wbhVuIgq/OIk2WG7HhQsRn7/fk9GftRkKhQfCuFqmCjQ3 DNCFYUzoBbSgGHFG2AYa/SuN7IXfB6w6xdy843rlUBwCHsZz6FD9InbAGlv2qY1QFvzg CwKL8jmL5rnftlKVh73f0BBqY33/K4I3CapkoBnCdgIudoPr2vg5TMyW79YHQQHBpE2a 9TJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=szQvB25rWTfgKGVeuukV9DTCNKDDzXBprqDpXTvOqKQ=; b=TKJz00AtStVWIbniefRlmRhNyCrPLi0Z0EAJ6tzYmxVG5lxroGPan9u7BZWeKIct9C 8rQ8hPUKSFMohHG9cjSwXP8/5CKyL9XROXjI+TAj/SxH8BUeRyt0lM56Hyja8ilofg7S ZM1z7yObiyJuyM8WeevPQwfmoSg7A90t0CroeVyCsnp5OnrTJep181sCduRojZrzYzEh +g1jLNwePtaYc+wa2NHYR0Oc93YtZb01VK2XTR+96IIn9WcarlOIfkzD1gpHUv/ASkN4 FRNMZ7z4gPGgHAmV7Jx9yqtJKXmXLHs5JFOALRkYsJ1oH2lQ8Fqyph/GXVmEj5Lbg+yv S0KQ== X-Gm-Message-State: ALKqPweQf5zoqf/c0t9m+qDltBAayPSLyquI7CbJYkhGpcv8XCw1IdZa PI3e0KD87V8lLzJU/vgaE1x306fYWzOU7I0bEZo= X-Google-Smtp-Source: AB8JxZp8l44BDDMUysKmutS8lPxaguWLXKxZ+SK2er6ZNiaD5SBDepDx9PRuGEDb4/rPiFvr1YFNnrFqUjfB9KDNH2Y= X-Received: by 2002:a25:6a55:: with SMTP id f82-v6mr2589964ybc.235.1526562361851; Thu, 17 May 2018 06:06:01 -0700 (PDT) MIME-Version: 1.0 References: <5AFD188F.2050309@erg.abdn.ac.uk> In-Reply-To: <5AFD188F.2050309@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Thu, 17 May 2018 08:05:49 -0500 Message-ID: To: G Fairhurst Cc: Kathleen Moriarty , tsvwg@ietf.org, Colin Perkins Content-Type: multipart/alternative; boundary="0000000000004e44b6056c667f6b" Archived-At: Subject: Re: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:06:07 -0000 --0000000000004e44b6056c667f6b Content-Type: text/plain; charset="UTF-8" Hi, Kathleen, On Thu, May 17, 2018 at 12:53 AM Gorry Fairhurst wrote: > Thanks Kathleen, > > it really helps to receive reviews, My thanks for your review as well. One point for Gorry, which might or might not be helpful ... > I'll try to respond to each in turn. > > On 08/05/2018, 18:22, Kathleen Moriarty wrote: > > Hello Gorry& Colin, > > > > Thanks for your work on this draft. In my opinion, it is very > > important to dig through the implications of encrypting transport > > headers. The document is well written and easy to read, thanks for > > that as well. Al and I had a hard time with that since ours was > > contribution driven and controversial. > > > > Here's some feedback from my review that I hope you find helpful: > > > > General: > > If you added section references to mm-wg-encrypt where it is > > referenced, that may be helpful to the reader. > I have now tried to do this where I could. > > Specific feedback: > > The apps side will object to this phrasing as they don't see the need > > for any 'help'. I agree with your point, just warning of the obstacle > > in case you can reword it to prevent objections. > > Choosing to encrypt all information may reduce > > the ability for networks to "help" (e.g., in response to tracing > > issues, making appropriate QoS decisions). > We aded more clarity on the ability for networks to "help" users and > subscribers. > > Section 3 intro text > > > > Encrypted traffic can also be profiled to identify threat actors. > > This will continue to be important as threat actors may have advanced > > capabilities and may modify the encrypted streams in identifiable ways > > that can differentiate their traffic from others. > > > > I was expecting to see some text toward the end of 3 on adoption of > > these protocols. We can put out protocols, but it's up to industry to > > decide when and where to adopt protocols. > I'd be happy to improve this section, but at the moment I'm unsure what > you have in mind. > In discussions about https://datatracker.ietf.org/doc/draft-dawkins-panrg-what-not-to-do/, I've been reminded that the IAB RFC on "What Makes for a Successful Protocol?" would be a good thing for me to include as a reference ( https://datatracker.ietf.org/doc/rfc5218/). Perhaps that would be useful for this draft as well? Spencer > > From a few recent talks, > > what I saw from the audiences is that those aware of QUIC are outright > > blocking it. The business imperative is not there for the > > applications using QUIC to justify it's use within the business > > network, at least not yet. > Indeed. I have seen similar talks and discussions that take this view. > We are trying to the base the draft on what has been deployed and > approaches that have been used - do you think we could/should say more? > > Section 3.3 > > Do you want to make this specific to IPsec tunnel mode since that > > hides the true end points as well? Transport mode isn't well deployed > > because of interoperability issues and not current use case driving > > it's usage, but that does leave the true IP source and destination > > addresses exposed, more than what you see with tunnel mode. > Yes. I have done this. > > Section 5.3 > > This is starting to touch on NetNeutrality and if you are going to go > > there, you should state it explicitly. At the enterprise level (it > > doesn't seem like you are covering that in this draft), I am hearing > > QUIC is outright blocked by those that are aware of it on the network, > > so it's not just NetNeutrality that will impact it's deployment. > > Perhaps rephrasing may help? Here's the text I'm talking about: > > A lack of data reduces the level of precision with which mechanisms > > are applied, and this needs to be considered when evaluating the > > impact of designs for transport encryption. This could lead to > > increased use of rate limiting, circuit breaker techniques [RFC8084], > > or even blocking of uncharacterised traffic. This would hinder > > deployment of new mechanisms and/or protocols. > I would love a suggestion? > > Section 5.4 > > I think you have a typo here: > > Integrity checks can undetected modification of protocol fields by > > network devices, > Indeed, and now resolved. > Gorry > > --0000000000004e44b6056c667f6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Kathleen,
On Thu, May 17, 2018 at 12:53 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
Thanks Kathleen,

it really helps to receive reviews,

My tha= nks for your review as well. One point for Gorry, which might or might not = be helpful ...
=C2=A0
I'll try to respond to each in turn.

On 08/05/2018, 18:22, Kathleen Moriarty wrote:
> Hello Gorry&=C2=A0 Colin,
>
> Thanks for your work on this draft.=C2=A0 In my opinion, it is very > important to dig through the implications of encrypting transport
> headers.=C2=A0 The document is well written and easy to read, thanks f= or
> that as well.=C2=A0 Al and I had a hard time with that since ours was<= br> > contribution driven and controversial.
>
> Here's some feedback from my review that I hope you find helpful:<= br> >
> General:
> If you added section references to mm-wg-encrypt where it is
> referenced, that may be helpful to the reader.
I have now tried to do this where I could.
> Specific feedback:
> The apps side will object to this phrasing as they don't see the n= eed
> for any 'help'.=C2=A0 I agree with your point, just warning of= the obstacle
> in case you can reword it to prevent objections.
>=C2=A0 =C2=A0 =C2=A0Choosing to encrypt all information may reduce
>=C2=A0 =C2=A0 =C2=A0the ability for networks to "help" (e.g.,= in response to tracing
>=C2=A0 =C2=A0 =C2=A0issues, making appropriate QoS decisions).
We aded more clarity on the ability for networks to "help" users = and
subscribers.
> Section 3 intro text
>
> Encrypted traffic can also be profiled to identify threat actors.
> This will continue to be important as threat actors may have advanced<= br> > capabilities and may modify the encrypted streams in identifiable ways=
> that can differentiate their traffic from others.
>
> I was expecting to see some text toward the end of 3 on adoption of > these protocols.=C2=A0 We can put out protocols, but it's up to in= dustry to
> decide when and where to adopt protocols.
I'd be happy to improve this section, but at the moment I'm unsure = what
you have in mind.


Perhaps that = would be useful for this draft as well?

Spencer
=C2=A0
>=C2=A0 From a few recent talks,
> what I saw from the audiences is that those aware of QUIC are outright=
> blocking it.=C2=A0 The business imperative is not there for the
> applications using QUIC to justify it's use within the business > network, at least not yet.
Indeed. I have seen similar talks and discussions that take this view.
We are trying to the base the draft on what has been deployed and
approaches that have been used - do you think we could/should say more?
> Section 3.3
> Do you want to make this specific to IPsec tunnel mode since that
> hides the true end points as well?=C2=A0 Transport mode isn't well= deployed
> because of interoperability issues and not current use case driving > it's usage, but that does leave the true IP source and destination=
> addresses exposed, more than what you see with tunnel mode.
Yes. I have done this.
> Section 5.3
> This is starting to touch on NetNeutrality and if you are going to go<= br> > there, you should state it explicitly.=C2=A0 At the enterprise level (= it
> doesn't seem like you are covering that in this draft), I am heari= ng
> QUIC is outright blocked by those that are aware of it on the network,=
> so it's not just NetNeutrality that will impact it's deploymen= t.
> Perhaps rephrasing may help?=C2=A0 Here's the text I'm talking= about:
>=C2=A0 =C2=A0 =C2=A0A lack of data reduces the level of precision with = which mechanisms
>=C2=A0 =C2=A0 =C2=A0are applied, and this needs to be considered when e= valuating the
>=C2=A0 =C2=A0 =C2=A0impact of designs for transport encryption.=C2=A0 T= his could lead to
>=C2=A0 =C2=A0 =C2=A0increased use of rate limiting, circuit breaker tec= hniques [RFC8084],
>=C2=A0 =C2=A0 =C2=A0or even blocking of uncharacterised traffic.=C2=A0 = This would hinder
>=C2=A0 =C2=A0 =C2=A0deployment of new mechanisms and/or protocols.
I would love a suggestion?
> Section 5.4
> I think you have a typo here:
>=C2=A0 =C2=A0 =C2=A0Integrity checks can undetected modification of pro= tocol fields by
>=C2=A0 =C2=A0 =C2=A0network devices,
Indeed, and now resolved.
Gorry

--0000000000004e44b6056c667f6b-- From nobody Thu May 17 07:30:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36412EAF6 for ; Thu, 17 May 2018 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgeg-9yIGumK for ; Thu, 17 May 2018 07:30:21 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC38B127333 for ; Thu, 17 May 2018 07:30:21 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id e78-v6so2219460iod.0 for ; Thu, 17 May 2018 07:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=KPP7M3RTPAliMJ5WefMIEFmiBmCNMVoUYWx2E20QgTY=; b=tPn+Yg6KyeqrmAOBzqe/ZpGVCnzhlD/SM6JHY+Nx+oR6WEwnoRe4FoFumK2dw4PkiP e3RX6/eBVzv5Y4KSuHlNrSIsMwgfLyD2VBuJJfMvTxUHbyOXsxYA2//aKzjaXG5IPqNB MgUR9XVrVGJJl8gn/223iBIyrjWY4S6FFIU9t3Gwf7XtgJozMmKgTDBoAb8KhxoMxO4O CEQabCEmgMJ2YY/ohgJCMD2fvjD4DUid1pyknfOGQIw/Y132Hqn+cp/ElSI7sFSTE++1 SS+IpofaBfDM8LV5XIud8jCRUHizic95NCgXQmA89n8JbljVKWXZ/kLStUxls2MTLybm jaXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=KPP7M3RTPAliMJ5WefMIEFmiBmCNMVoUYWx2E20QgTY=; b=AEE1MbQ1zACettOyPe71elYxTXqvG2sieC0K5vkVko4WOJBlrUJ722iOtgNnSojvaZ HYs8uqR8++OIUqHi9G36WusHOV5nL2mR9sx4Wg49g1sUCaH3K1FaS3f0AGk2TGLd2ljO Hk8xQhs7DHrwmlLgq1/QM2PVxOsQSjafp6+f+cGUnBRbrxs/0ZY3EMdwrJrG21ZHXEPw sxTJwWXiTndg15dLshlIYRHoyriruIIsmjDq7r7Cc6q+E2dMcL3wGlH2z86f0pUbM1Wr gTp1Z7USCGUMex8f2zDoKfdo0U9iVsIxfjpNxjMO1HWAJFJnnzFTr7Z20hVOWmm5QokB qsjQ== X-Gm-Message-State: ALKqPwcRVComCq4NUEKV889tkrdJzzcMQFlSYQX+JgnGsBVTDz5kSqiX PJMOS9H5BgoJZjSz7NtWVpsnMJxjp3INeeMYFRw= X-Google-Smtp-Source: AB8JxZpyHR/1AJIWrnKu+YYVqFAyuhcdvPBO9NYS2vgsLHQHvNCNt62fe9Ft//AnWVFIbsVyllwGUNdoVDFoZw2vhQs= X-Received: by 2002:a6b:9a05:: with SMTP id c5-v6mr5695306ioe.142.1526567420971; Thu, 17 May 2018 07:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.188.1 with HTTP; Thu, 17 May 2018 07:29:40 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 17 May 2018 10:29:40 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: G Fairhurst , tsvwg@ietf.org, Colin Perkins Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:30:25 -0000 Hi Gory, On Thu, May 17, 2018 at 9:05 AM, Spencer Dawkins at IETF wrote: > Hi, Kathleen, > On Thu, May 17, 2018 at 12:53 AM Gorry Fairhurst > wrote: >> >> Thanks Kathleen, >> >> it really helps to receive reviews, Very happy to help as this type of draft can be tricky and you've done a nice job! > > > My thanks for your review as well. One point for Gorry, which might or might > not be helpful ... > >> >> I'll try to respond to each in turn. I'll try to do the same and thank Spencer in advance for providing a very good solution on one of the points. >> >> On 08/05/2018, 18:22, Kathleen Moriarty wrote: >> > Hello Gorry& Colin, >> > >> > Thanks for your work on this draft. In my opinion, it is very >> > important to dig through the implications of encrypting transport >> > headers. The document is well written and easy to read, thanks for >> > that as well. Al and I had a hard time with that since ours was >> > contribution driven and controversial. >> > >> > Here's some feedback from my review that I hope you find helpful: >> > >> > General: >> > If you added section references to mm-wg-encrypt where it is >> > referenced, that may be helpful to the reader. >> I have now tried to do this where I could. >> > Specific feedback: >> > The apps side will object to this phrasing as they don't see the need >> > for any 'help'. I agree with your point, just warning of the obstacle >> > in case you can reword it to prevent objections. >> > Choosing to encrypt all information may reduce >> > the ability for networks to "help" (e.g., in response to tracing >> > issues, making appropriate QoS decisions). >> We aded more clarity on the ability for networks to "help" users and >> subscribers. Great, did you continue the use of the word help or find another way to phrase it? I could see that getting objections/comments in the IESG. >> > Section 3 intro text >> > >> > Encrypted traffic can also be profiled to identify threat actors. >> > This will continue to be important as threat actors may have advanced >> > capabilities and may modify the encrypted streams in identifiable ways >> > that can differentiate their traffic from others. >> > >> > I was expecting to see some text toward the end of 3 on adoption of >> > these protocols. We can put out protocols, but it's up to industry to >> > decide when and where to adopt protocols. >> I'd be happy to improve this section, but at the moment I'm unsure what >> you have in mind. > > > In discussions about > https://datatracker.ietf.org/doc/draft-dawkins-panrg-what-not-to-do/, I've > been reminded that the IAB RFC on "What Makes for a Successful Protocol?" > would be a good thing for me to include as a reference > (https://datatracker.ietf.org/doc/rfc5218/). > > Perhaps that would be useful for this draft as well? I think this would be a very good solution to the point as it's early and we don't know what will happen yet longer term. A business imperative could arise in time. > > Spencer > >> >> > From a few recent talks, >> > what I saw from the audiences is that those aware of QUIC are outright >> > blocking it. The business imperative is not there for the >> > applications using QUIC to justify it's use within the business >> > network, at least not yet. >> Indeed. I have seen similar talks and discussions that take this view. >> We are trying to the base the draft on what has been deployed and >> approaches that have been used - do you think we could/should say more? >> > Section 3.3 >> > Do you want to make this specific to IPsec tunnel mode since that >> > hides the true end points as well? Transport mode isn't well deployed >> > because of interoperability issues and not current use case driving >> > it's usage, but that does leave the true IP source and destination >> > addresses exposed, more than what you see with tunnel mode. >> Yes. I have done this. Thanks. >> > Section 5.3 >> > This is starting to touch on NetNeutrality and if you are going to go >> > there, you should state it explicitly. At the enterprise level (it >> > doesn't seem like you are covering that in this draft), I am hearing >> > QUIC is outright blocked by those that are aware of it on the network, >> > so it's not just NetNeutrality that will impact it's deployment. >> > Perhaps rephrasing may help? Here's the text I'm talking about: >> > A lack of data reduces the level of precision with which mechanisms >> > are applied, and this needs to be considered when evaluating the >> > impact of designs for transport encryption. This could lead to >> > increased use of rate limiting, circuit breaker techniques >> > [RFC8084], >> > or even blocking of uncharacterised traffic. This would hinder >> > deployment of new mechanisms and/or protocols. >> I would love a suggestion? This is a tough one. I think the second paragraph will be read as a threat to someone in the apps area, providing additional motivation to encrypt session headers. You may want to mention in the previous paragraph that the use of overlay protocols may be deployed to assist with evaluations performed. The second paragraph is a slippery slope. Is there a better way to bridge from the first to the second sentence in the last paragraph? There's a leap there where the first sentence would probably be fine on it's own, but the second either needs to be expanded with proceeding text or removed. >> > Section 5.4 >> > I think you have a typo here: >> > Integrity checks can undetected modification of protocol fields by >> > network devices, >> Indeed, and now resolved. Thanks! >> Gorry >> > -- Best regards, Kathleen From nobody Thu May 17 07:50:12 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B60FE127775; Thu, 17 May 2018 07:49:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-tsvwg-iana-dscp-registry.all@ietf.org, ietf@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152656859955.7651.10624051963160660895@ietfa.amsl.com> Date: Thu, 17 May 2018 07:49:59 -0700 Archived-At: Subject: [tsvwg] Secdir last call review of draft-ietf-tsvwg-iana-dscp-registry-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:50:00 -0000 Reviewer: Robert Sparks Review result: Ready Reviewer: Robert Sparks Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready for publication as Standards Track RFC This document is entirely about changing the IANA registration policies for part (pool 3) of the DSCP value registry. It is clearly written, and the instructions to IANA are detailed. The security considerations section appropriately notes that the document does not introduce new security considerations for the Internet. From nobody Thu May 17 23:51:19 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 904F212711A; Thu, 17 May 2018 23:51:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152662627753.1538.3506303682099297675@ietfa.amsl.com> Date: Thu, 17 May 2018 23:51:17 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 06:51:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME Authors : Vincent Roca Belkacem Teibi Filename : draft-ietf-tsvwg-rlc-fec-scheme-04.txt Pages : 31 Date : 2018-05-17 Abstract: This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over GF(2) (binary case), a second one for RLC over GF(2^^8), both of them with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real-time flows in terms of reduced FEC- related latency while often providing improved packet erasure recovery capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 18 00:13:27 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B29127333 for ; Fri, 18 May 2018 00:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=unavailable autolearn_force=no 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 5SiOMwWCnrtX for ; Fri, 18 May 2018 00:13:18 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 8326D12711A for ; Fri, 18 May 2018 00:13:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,413,1520895600"; d="scan'208";a="265639231" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.101]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2018 09:13:15 +0200 From: Vincent Roca Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 18 May 2018 09:13:14 +0200 References: <152662627753.1538.3506303682099297675@ietfa.amsl.com> To: tsvwg@ietf.org, nwcrg@irtf.org In-Reply-To: <152662627753.1538.3506303682099297675@ietfa.amsl.com> Message-Id: <9ACF3E21-8A26-4C74-843C-1716A95C9F3C@inria.fr> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 07:13:21 -0000 Dear all, Here is an updated version of our I-D. - It takes into accounts comments received by Jonathan Detchart (added section 3.6. Finite Fields Operations); - Section 3.1. Possible Parameter Derivations=20 has been significantly improved for more precision; - It also fixes a small bug (in parameter checks) in=20 section 3.5. Coding Coefficients Generation Function; We are not sure we will keep the current PRNG... Even with the previous fix (i.e., ignoring the first value produced), the Park-Miler minimal standard PRNG behaves badly when used with seeds that are in sequence (e.g., the application generates a repair symbol with seed s and then s+1, etc.) and when mapping the PRNG output to a small range of value (especially with [0, 15]): Ij+1 =3D A * s (modulo M) and: Ij+1 =3D A * (s+1) (modulo M) scaled to [0, 15] have a certain probability to give the same value. We are currently experimenting with alternatives. Unfortunately we only identified this side-effect recently.=20 Cheers, Vincent and Belkacem > Le 18 mai 2018 =C3=A0 08:51, internet-drafts@ietf.org a =C3=A9crit : >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group WG of = the IETF. >=20 > Title : Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Schemes for FECFRAME > Authors : Vincent Roca > Belkacem Teibi > Filename : draft-ietf-tsvwg-rlc-fec-scheme-04.txt > Pages : 31 > Date : 2018-05-17 >=20 > Abstract: > This document describes two fully-specified Forward Erasure > Correction (FEC) Schemes for Sliding Window Random Linear Codes > (RLC), one for RLC over GF(2) (binary case), a second one for RLC > over GF(2^^8), both of them with the possibility of controlling the > code density. They can protect arbitrary media streams along the > lines defined by FECFRAME extended to sliding window FEC codes. > These sliding window FEC codes rely on an encoding window that = slides > over the source symbols, generating new repair symbols whenever > needed. Compared to block FEC codes, these sliding window FEC codes > offer key advantages with real-time flows in terms of reduced FEC- > related latency while often providing improved packet erasure > recovery capabilities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rlc-fec-scheme-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 From nobody Sun May 20 09:53:51 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3425912D72F; Sun, 20 May 2018 09:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 9DZbMeHe5kk2; Sun, 20 May 2018 09:53:45 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA37912D77A; Sun, 20 May 2018 09:53:44 -0700 (PDT) Received: from [192.168.1.131] (p57BB4C93.dip0.t-ipconnect.de [87.187.76.147]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EA87A72106C24; Sun, 20 May 2018 18:53:38 +0200 (CEST) From: Michael Tuexen Message-Id: <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_EA57E5B4-C6EE-47A7-9779-C94E1E09EA7F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 20 May 2018 18:53:37 +0200 In-Reply-To: Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org, Gorry Fairhurst To: Spencer Dawkins at IETF References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2018 16:53:49 -0000 --Apple-Mail=_EA57E5B4-C6EE-47A7-9779-C94E1E09EA7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11. May 2018, at 22:12, Spencer Dawkins at IETF = wrote: >=20 > Dear Authors, >=20 > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst = wrote: > Gorry Fairhurst has requested publication of = draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of the = TSVWG working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ >=20 > Thanks for doing this work (and even more so, for being willing to = provide an updated RFC to implementers, at some point in the future).=20 >=20 > I've completed AD evaluation for this draft, and have comments, but = almost all of them are requests for clarifications.=20 >=20 > I'd like to work through them with you before requesting Last Call. = Please let me know if you have questions. Hi Spencer, thanks for the review. I'll provide feedback inline. Please note that I was also notified recently about a paragraph which = should have been removed when moving from RFC 2960 to RFC 4960, but the removal = was missed and the text is still there. I have received this not via any = mailing list but via direct e-mail conversation. The fix is included as = https://github.com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283a= b5e82d4fc9c You can see the current version in the git repository of the document in = http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2Fr= aw.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvw= g-rfc4960-errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&Submit=3D= Submit If you want additional changes, please let me know. If you are fine with = the current version in the git repo, I can submit it anytime... Best regards Michael >=20 > Thanks! >=20 > Spencer=20 >=20 > A high-order bit here ...=20 >=20 > I'm not sure why this draft isn't standards-track, and I wonder if = there's a reason it doesn't UPDATE RFC 4960, unless that's a side effect = of being an Informational draft that would update a standards-track RFC.=20= >=20 > I'm thinking that this draft has achieved WG consensus, and if it's = published after Last Call, it would have IETF consensus, and it's been = reviewed by implementers. We've certainly published Proposed Standards = that didn't measure up to that level of document quality. >=20 > I'm not objecting strongly to publishing as Informational, but I am = saying that I expect other ADs to ask that question during IESG = Evaluation, and I'd like to understand the thinking before someone asks = =E2=80=A6 That is actually a good question and it would be a possible way forward. When being in the process updating RFC 2960 to RFC 4960 we were in the = same situation. At that time we wrote RFC 4460. We thought it is a good idea to not only publish RFC 4960 and = let people figure what changed and why, but document this. That is why we have RFC 4460. We also thought = that it is a good idea to just have a single specification for implementing the base protocol. If we would = have made RFC 4460 a PS updating RFC 2960, and implementer would have to read two RFCs. That is why we decided that = it is simpler to publish RFC 4460 as an informational RFC, and then publish RFC 4960 as a PS updating RFC = 2960. As you see from the numbers, working on RFC 4460 took a while, but once that was there, publishing RFC 4960 = was straight forward. Just do the editorial work described in RFC 4460 and some polishing of text we missed when = working in the diff way... Since this plan worked well, the implementers of SCTP (which were also = at that time) are used to it, we though it is a good way to handle the errata in RFC 4960. >=20 > I note without suggesting a change that if the material in Section 3 = was presented in this order >=20 > 3.n.1 Description of the Problem >=20 >=20 > 3.n.3. Solution Description >=20 > 3.n.2. Text Changes to the Document >=20 > --------- > Old text: > --------- >=20 > --------- > New text: > --------- >=20 > to allow readers to see the solution description before reading the = detailed text changes, that would likely be easier to parse ... That is definitely doable and I'm willing to do that change. However, = this document right now uses the same structure as RFC 4460 and I would prefer to keep the consistency. >=20 > I'm reading this text from the Abstract=20 >=20 > Because some text is changed several times the last delta in the > text is the one which should be applied. In addition to the delta = a > description of the problem and the details of the solution are also > provided. >=20 > as saying that the deltas are cumulative, so you should apply the last = change to specific text, but this text from Section 1=20 >=20 > Note that when reading this document one must use care to assure = that > a field or item is not updated further on within the document. = Each > section should be applied in sequence to the original [RFC4960] = since > this document is a historical record of the sequential changes that > have been found necessary at various inter-op events and through > discussion on the list. >=20 > seems to say that you should apply multiple deltas to the same text = sequentially. IIUC, the text actually does provide cumulative text = deltas, so using the phrasing from the Abstract in both places would be = helpful to the reader. OK. Changed to Note that when reading this document one must use care to assure that a field or item is not updated further on within the document. Since this document is a historical record of the sequential changes that have been found necessary at various inter-op events and through discussion on the list, the last delta in the text is the one which should be applied. in = https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac3= 82ef3f6b434 >=20 > This is a nit, but why is "Inconsistent" capitalized in this text? >=20 > The handling of the 'Path.Max.Retrans' parameter is described in > Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. Because I (or some autocorrection function of my editor) made a mistake. Fixed in: = https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7= ed1f90502a9 >=20 > = https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-t= svwg-rfc4960-errata-05.txt reports a few problems with references. I = THINK this is a side effect of updating (for example) [RFC2434] to be = [RFC5226], and then updating [RFC5226] to be [RFC8126]. If this was my = draft, I'd put a note to the RFC Editor that obsoleted RFCs are used in = "OLD TEXT" sections, and should have the obsoleting RFCs in the "NEW = TEXT" sections, so multiple reviewers won't ask you about the IDNIT = reporting multiple times. After updating the document to reduce IDNITs warnings regarding too long = lines in = https://github.com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a32= ecdd00626d5 and cleaning up the references in = https://github.com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc4= 7766256606e I added the now true Note to the RFC Editor in = https://github.com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732e= c8a5208de57 >=20 > I'm probably due for an eye exam, but I'm not seeing any difference = between=20 >=20 > --------- > Old text: (Section 1.6) > --------- >=20 > Transmission Sequence Numbers wrap around when they reach 2**32 - = 1. > That is, the next TSN a DATA chunk MUST use after transmitting TSN = =3D > 2*32 - 1 is TSN =3D 0. >=20 > and >=20 > --------- > New text: (Section 1.6) > --------- >=20 > Transmission Sequence Numbers wrap around when they reach 2**32 - = 1. > That is, the next TSN a DATA chunk MUST use after transmitting TSN = =3D > 2**32 - 1 is TSN =3D 0. >=20 > What am I missing? The difference between "2*32" and "2**32" (the second occurrence in the = OLD and NEW text)... Whether this should trigger an eye exam or not is left to the reader. >=20 > In this text,=20 >=20 > Move the sample code related to CRC32c computation and its > explanation from the end of Appendix C to the end of Appendix B. >=20 > I'm pretty sure I can figure out what text/code actually moves from = Appendix C to Appendix B, but I am figuring that out myself. Perhaps it = would be clearer if you said something like "all of Appendix C starting = with this sentence to the end of Appendix B". >=20 > The following non-normative sample code is taken from an = open-source > CRC generator [WILLIAMS93], using the "mirroring" technique and > yielding a lookup table for SCTP CRC32c with 256 entries, each 32 > bits wide. >=20 > (If I guessed wrong, that's likely because the fix says "code and its = explanation", which sounds like "everything following the beginning of = the code", but the explanation comes before the code) You guessed perfectly right and I added the suggested text: = https://github.com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c5153= 4ede667111d >=20 > If I'm following closely, the errata described as=20 >=20 > Section 7.2.2 of [RFC4960] is unclear about the order of adjustments > applied to partial_bytes_acked and cwnd in the congestion avoidance > phase. >=20 > is actually clear about the order - assuming that you read left to = right, it's just clearly wrong :-) I see. But there is no explicit statement that you have to do it in that = order.=20 What about: Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance phase. which is committed in = https://github.com/sctplab/rfc4960bis/commit/9fa55976e242ff1e5125637336321= 887a2f57e80 >=20 > At the risk of asking a technical question ;-) >=20 > The counter SHOULD be reset each time a DATA chunk sent to that peer > endpoint is acknowledged (by the reception of a SACK). When a > HEARTBEAT ACK is received from the peer endpoint, the counter = SHOULD > also be reset. The receiver of the HEARTBEAT ACK MAY choose not to > clear the counter if there is outstanding data on the association. > This allows for handling the possible difference in reachability > based on DATA chunks and HEARTBEAT chunks. >=20 > why is not clearing the counter if there is outstanding data on the = association a good idea? (this was "shall", but is now "SHOULD") You are correct. It should be a MUST. Changed in: = https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e35= 39637f9dafe >=20 > I have a similar (MUST vs. SHOULD) question about=20 >=20 > Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT > SHOULD clear the error counter of the destination transport address > to which the HEARTBEAT was sent, and mark the destination transport > address as active if it is not so marked. >=20 > Why would not clearing the error counter be a good idea? You are right. The "should" should be changed to a "MUST", not a = "SHOULD. Done in: = https://github.com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c5= a67a1b6faeb >=20 > Section 3.21 has multiple occurrences of something like=20 >=20 > o partial flag - if this returned flag is set to 1, then this > Receive contains a partial delivery of the whole message. When > ^ this "Receive" is capitalized >=20 > this flag is set, the stream id and Stream Sequence Number MUST > accompany this receive. When this flag is set to 0, it = indicates > ^ this "receive" is not capitalized >=20 > that no more deliveries will be received for this Stream = Sequence > Number. >=20 > Is that intentional? No. This is even not changed by this documents, but also inconsistent in = RFC 4960. I also improved the consistency of the spelling: However, I improved the text: = https://github.com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6f= ae72eaf1751 --Apple-Mail=_EA57E5B4-C6EE-47A7-9779-C94E1E09EA7F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODA1MjAxNjUzMzdaMCMGCSqGSIb3DQEJBDEWBBR0Km+TYz7mgLbaFdbI Fi4WRJ9bsTCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQA8I0XW4vDJxam71RjL7b6EWSqmvSOjJ3+r oai9mN0O/UK0xAFt4z54y2zfjlnaEGO5lM48Xrg4URbHjMzBbsd9E28FKkoSK0/YBiShtmIcaDzs 02Zj+wUDqCPJlBrZYuDVtLhSo7HMoWQG64LxYU4DFT4qLg0LNN5l2ydSVRb+QEJknfXc3ZWQuKDS Hb22ppFefACi72/FLFQozWEu7V2nLC3ATXLEiMZy4qzpmhJ6ETAIPCtqBaUQXJRNODTrkYQdvIzj m6kiooneamCnI82EvSPgtP6ekIyOTdvIJSDUoACl40BFSU2cAAb71OxXOKYE+YjFUCv0MZmtHehS 5LaCAAAAAAAA --Apple-Mail=_EA57E5B4-C6EE-47A7-9779-C94E1E09EA7F-- From nobody Mon May 21 06:55:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA92A1270AC; Mon, 21 May 2018 06:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPhDNUvgJ-le; Mon, 21 May 2018 06:55:34 -0700 (PDT) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF42127076; Mon, 21 May 2018 06:55:34 -0700 (PDT) Received: by mail-yw0-x241.google.com with SMTP id p144-v6so4493926ywg.7; Mon, 21 May 2018 06:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azIcmbmQEalwE2ITWzJxJLutWd4sVbcD8TrrU5l54G8=; b=fcbYanJMA3X3G45z7y/71B+qicZj4NU3+y1HKpFE4GN530nlLyDciBmNZKGwD8caZe XTTPfr64EZ6wgpT287eNLJqVV5dokJhrmZAenzTmqgacAtBoDjjs6auUABrszOvzwZAB VcWwfoK15eNJ1G7vP6C7hLCFsuaXAefV94pMI4bOxqn1elQWoI0MY7R+AyLLD0NgAB8J W9+bGV0525O2Wxa7D27a8aL1xiuaFHJaUqVexpsrwGYb1+ovt+F+78Rr2R4JXxjQd+2P DZc2rFCroEFCr0Y+ljiz9fg8TwMspZMl7JNb/NvxeHYmVEwkBgdEBJ07H1q9uNEnqprO CHpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azIcmbmQEalwE2ITWzJxJLutWd4sVbcD8TrrU5l54G8=; b=chenjwtiV3YYy4iENz+kCW5o+0LFP1gFgKKPVjn2Jl2pcT5B+6hCZFUsH/jAlMmAMD 7tUcQgpKGtifRlbFhzn0dLnkN5pD21hW3G1WxhWNQdiz8pK+G8aSF/C36jNY2zMNg+uZ hUS0gjbxSrQlsGPMjAYP6kwCZdylGrDHz0KXKJBSrO6XIcWlo0yMCHs09l/nzX954wcw 4AdAIVsy1OLgMvOXbVFPM0rQsPU0rmSyVfr+w/enmqkRVu5rlIlfSbX/7JYFfzHtC37H xaOFcy35VlRnx/JcdPa8P48ntPY/O4bCw4gqNq5aeHA7xTl94vauVI2tJVu6EswDGJoI IyIg== X-Gm-Message-State: ALKqPweZ0bg5Jxss95uaMeK3uRiaxHbsFDLyWPEjDVkYkIqk/eEKiY9m +eXrhqnlOjE7jdr0oEIledxDqN8suDgc6Im6ynw= X-Google-Smtp-Source: AB8JxZrXPLL32RXlzxPq8OTXMgg4DwKjpXnkKlN1mYQZcLv2y2Qhxf8AVDg/R+U6vVh9A+BL+H7lyu+Xy4Q1A/D/9Bc= X-Received: by 2002:a0d:f444:: with SMTP id d65-v6mr4139646ywf.279.1526910933141; Mon, 21 May 2018 06:55:33 -0700 (PDT) MIME-Version: 1.0 References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> In-Reply-To: <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> From: Spencer Dawkins at IETF Date: Mon, 21 May 2018 08:55:20 -0500 Message-ID: To: Michael Tuexen Cc: draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org, G Fairhurst Content-Type: multipart/alternative; boundary="000000000000c60d62056cb7a79c" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 13:55:38 -0000 --000000000000c60d62056cb7a79c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Gorry the Shepherd, On Sun, May 20, 2018 at 11:53 AM Michael Tuexen wrote: > > > > On 11. May 2018, at 22:12, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Dear Authors, > > > > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst > wrote: > > Gorry Fairhurst has requested publication of > draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of the TSVW= G > working group. > > > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ > > > > Thanks for doing this work (and even more so, for being willing to > provide an updated RFC to implementers, at some point in the future). > > > > I've completed AD evaluation for this draft, and have comments, but > almost all of them are requests for clarifications. > > > > I'd like to work through them with you before requesting Last Call. > Please let me know if you have questions. > Hi Spencer, > > thanks for the review. I'll provide feedback inline. > > Please note that I was also notified recently about a paragraph which > should > have been removed when moving from RFC 2960 to RFC 4960, but the removal > was > missed and the text is still there. I have received this not via any > mailing > list but via direct e-mail conversation. The fix is included as > > https://github.com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283= ab5e82d4fc9c > > You can see the current version in the git repository of the document in > > http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2F= raw.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvw= g-rfc4960-errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&Submit=3DS= ubmit > > If you want additional changes, please let me know. If you are fine with > the current > version in the git repo, I can submit it anytime... > Michael's responses (whether they resulted in changes or in explanations to the evaluating AD) work for me. Thanks to Michael for the quick response. Please invite Michael to submit a new version, when you think that's the right thing to do. I would appreciate it if you could add a few words reflecting Michael's response on Why This Is Informational to the shepherd write-up, perhaps under (1) or (2)/Working Group Summary, where it will be copied into the IESG ballot, so that we won't be explaining this 14 more times during IESG evaluation ;-) Spencer > Best regards > Michael > > > > Thanks! > > > > Spencer > > > > A high-order bit here ... > > > > I'm not sure why this draft isn't standards-track, and I wonder if > there's a reason it doesn't UPDATE RFC 4960, unless that's a side effect = of > being an Informational draft that would update a standards-track RFC. > > > > I'm thinking that this draft has achieved WG consensus, and if it's > published after Last Call, it would have IETF consensus, and it's been > reviewed by implementers. We've certainly published Proposed Standards th= at > didn't measure up to that level of document quality. > > > > I'm not objecting strongly to publishing as Informational, but I am > saying that I expect other ADs to ask that question during IESG Evaluatio= n, > and I'd like to understand the thinking before someone asks =E2=80=A6 > That is actually a good question and it would be a possible way forward. > > When being in the process updating RFC 2960 to RFC 4960 we were in the > same situation. At that time we wrote > RFC 4460. We thought it is a good idea to not only publish RFC 4960 and > let people figure what changed and > why, but document this. That is why we have RFC 4460. We also thought tha= t > it is a good idea to just have a > single specification for implementing the base protocol. If we would have > made RFC 4460 a PS updating RFC 2960, > and implementer would have to read two RFCs. That is why we decided that > it is simpler to publish RFC 4460 as > an informational RFC, and then publish RFC 4960 as a PS updating RFC 2960= . > As you see from the numbers, working > on RFC 4460 took a while, but once that was there, publishing RFC 4960 wa= s > straight forward. Just do the editorial > work described in RFC 4460 and some polishing of text we missed when > working in the diff way... > > Since this plan worked well, the implementers of SCTP (which were also at > that time) are used to it, we though > it is a good way to handle the errata in RFC 4960. > > > > I note without suggesting a change that if the material in Section 3 wa= s > presented in this order > > > > 3.n.1 Description of the Problem > > > > > > 3.n.3. Solution Description > > > > 3.n.2. Text Changes to the Document > > > > --------- > > Old text: > > --------- > > > > --------- > > New text: > > --------- > > > > to allow readers to see the solution description before reading the > detailed text changes, that would likely be easier to parse ... > That is definitely doable and I'm willing to do that change. However, thi= s > document right now uses the > same structure as RFC 4460 and I would prefer to keep the consistency. > > > > I'm reading this text from the Abstract > > > > Because some text is changed several times the last delta in the > > text is the one which should be applied. In addition to the delta a > > description of the problem and the details of the solution are also > > provided. > > > > as saying that the deltas are cumulative, so you should apply the last > change to specific text, but this text from Section 1 > > > > Note that when reading this document one must use care to assure that > > a field or item is not updated further on within the document. Each > > section should be applied in sequence to the original [RFC4960] sinc= e > > this document is a historical record of the sequential changes that > > have been found necessary at various inter-op events and through > > discussion on the list. > > > > seems to say that you should apply multiple deltas to the same text > sequentially. IIUC, the text actually does provide cumulative text deltas= , > so using the phrasing from the Abstract in both places would be helpful t= o > the reader. > OK. Changed to > > Note that when reading this document one must use care to assure that > a field or item is not updated further on within the document. Since > this document is a historical record of the sequential changes that > have been found necessary at various inter-op events and through > discussion on the list, the last delta in the text is the one which > should be applied. > > in > https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac= 382ef3f6b434 > > > > > This is a nit, but why is "Inconsistent" capitalized in this text? > > > > The handling of the 'Path.Max.Retrans' parameter is described in > > Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. > Because I (or some autocorrection function of my editor) made a mistake. > Fixed in: > https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a= 7ed1f90502a9 > > > > > https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-= tsvwg-rfc4960-errata-05.txt > reports a few problems with references. I THINK this is a side effect of > updating (for example) [RFC2434] to be [RFC5226], and then updating > [RFC5226] to be [RFC8126]. If this was my draft, I'd put a note to the RF= C > Editor that obsoleted RFCs are used in "OLD TEXT" sections, and should ha= ve > the obsoleting RFCs in the "NEW TEXT" sections, so multiple reviewers won= 't > ask you about the IDNIT reporting multiple times. > After updating the document to reduce IDNITs warnings regarding too long > lines in > > https://github.com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a3= 2ecdd00626d5 > and cleaning up the references in > > https://github.com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc= 47766256606e > I added the now true Note to the RFC Editor in > > https://github.com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732= ec8a5208de57 > > > > I'm probably due for an eye exam, but I'm not seeing any difference > between > > > > --------- > > Old text: (Section 1.6) > > --------- > > > > Transmission Sequence Numbers wrap around when they reach 2**32 - 1. > > That is, the next TSN a DATA chunk MUST use after transmitting TSN = =3D > > 2*32 - 1 is TSN =3D 0. > > > > and > > > > --------- > > New text: (Section 1.6) > > --------- > > > > Transmission Sequence Numbers wrap around when they reach 2**32 - 1. > > That is, the next TSN a DATA chunk MUST use after transmitting TSN = =3D > > 2**32 - 1 is TSN =3D 0. > > > > What am I missing? > The difference between "2*32" and "2**32" (the second occurrence in the > OLD and NEW text)... > Whether this should trigger an eye exam or not is left to the reader. > > > > In this text, > > > > Move the sample code related to CRC32c computation and its > > explanation from the end of Appendix C to the end of Appendix B. > > > > I'm pretty sure I can figure out what text/code actually moves from > Appendix C to Appendix B, but I am figuring that out myself. Perhaps it > would be clearer if you said something like "all of Appendix C starting > with this sentence to the end of Appendix B". > > > > The following non-normative sample code is taken from an open-source > > CRC generator [WILLIAMS93], using the "mirroring" technique and > > yielding a lookup table for SCTP CRC32c with 256 entries, each 32 > > bits wide. > > > > (If I guessed wrong, that's likely because the fix says "code and its > explanation", which sounds like "everything following the beginning of th= e > code", but the explanation comes before the code) > You guessed perfectly right and I added the suggested text: > > https://github.com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c515= 34ede667111d > > > > If I'm following closely, the errata described as > > > > Section 7.2.2 of [RFC4960] is unclear about the order of adjustments > > applied to partial_bytes_acked and cwnd in the congestion avoidance > > phase. > > > > is actually clear about the order - assuming that you read left to > right, it's just clearly wrong :-) > I see. But there is no explicit statement that you have to do it in that > order. > > What about: > > Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments > applied to partial_bytes_acked and cwnd in the congestion avoidance > phase. > which is committed in > > https://github.com/sctplab/rfc4960bis/commit/9fa55976e242ff1e512563733632= 1887a2f57e80 > > > > At the risk of asking a technical question ;-) > > > > The counter SHOULD be reset each time a DATA chunk sent to that peer > > endpoint is acknowledged (by the reception of a SACK). When a > > HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD > > also be reset. The receiver of the HEARTBEAT ACK MAY choose not to > > clear the counter if there is outstanding data on the association. > > This allows for handling the possible difference in reachability > > based on DATA chunks and HEARTBEAT chunks. > > > > why is not clearing the counter if there is outstanding data on the > association a good idea? (this was "shall", but is now "SHOULD") > You are correct. It should be a MUST. > Changed in: > https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e3= 539637f9dafe > > > > I have a similar (MUST vs. SHOULD) question about > > > > Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT > > SHOULD clear the error counter of the destination transport address > > to which the HEARTBEAT was sent, and mark the destination transport > > address as active if it is not so marked. > > > > Why would not clearing the error counter be a good idea? > You are right. The "should" should be changed to a "MUST", not a "SHOULD. > Done in: > > https://github.com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c= 5a67a1b6faeb > > > > Section 3.21 has multiple occurrences of something like > > > > o partial flag - if this returned flag is set to 1, then this > > Receive contains a partial delivery of the whole message. When > > ^ this "Receive" is capitalized > > > > this flag is set, the stream id and Stream Sequence Number MUST > > accompany this receive. When this flag is set to 0, it indicates > > ^ this "receive" is not capitalized > > > > that no more deliveries will be received for this Stream Sequence > > Number. > > > > Is that intentional? > No. This is even not changed by this documents, but also inconsistent in > RFC 4960. > I also improved the consistency of the spelling: > However, I improved the text: > > https://github.com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6= fae72eaf1751 > > > > --000000000000c60d62056cb7a79c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Gorry the Shepherd,

On Sun, May 20, 2018 at 11:53 AM Michael Tuexen <tuexen@fh-muenster.de> wrote:


> On 11. May 2018, at 22:12, Spencer Dawkins at IETF <spencerdawkins.ietf@gma= il.com> wrote:
>
> Dear Authors,
>
> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote= :
> Gorry Fairhurst has requested publication of draft-ietf-tsvwg-rfc4960-= errata-05 as Informational on behalf of the TSVWG working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errat= a/
>
> Thanks for doing this work (and even more so, for being willing to pro= vide an updated RFC to implementers, at some point in the future).
>
> I've completed AD evaluation for this draft, and have comments, bu= t almost all of them are requests for clarifications.
>
> I'd like to work through them with you before requesting Last Call= . Please let me know if you have questions.
Hi Spencer,

thanks for the review. I'll provide feedback inline.

Please note that I was also notified recently about a paragraph which shoul= d
have been removed when moving from RFC 2960 to RFC 4960, but the removal wa= s
missed and the text is still there. I have received this not via any mailin= g
list but via direct e-mail conversation. The fix is included as
https://github.= com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283ab5e82d4fc9c<= br>
You can see the current version in the git repository of the document in http:= //xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2Fraw= .githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-r= fc4960-errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&S= ubmit=3DSubmit

If you want additional changes, please let me know. If you are fine with th= e current
version in the git repo, I can submit it anytime...
Michael's responses (whether they resulted in changes or i= n explanations to the evaluating AD) work for me. Thanks to Michael for the= quick response.

Please invite Michael to submit a= new version, when you think that's the right thing to do.
I would appreciate it if you could add a few words reflecting = Michael's response on Why This Is Informational to the shepherd write-u= p, perhaps under (1) or (2)/Working Group Summary, where it will be copied = into the IESG ballot, so that we won't be explaining this 14 more times= during IESG evaluation ;-)

Spencer
=C2= =A0
Best regards
Michael
>
> Thanks!
>
> Spencer
>
> A high-order bit here ...
>
> I'm not sure why this draft isn't standards-track, and I wonde= r if there's a reason it doesn't UPDATE RFC 4960, unless that's= a side effect of being an Informational draft that would update a standard= s-track RFC.
>
> I'm thinking that this draft has achieved WG consensus, and if it&= #39;s published after Last Call, it would have IETF consensus, and it's= been reviewed by implementers. We've certainly published Proposed Stan= dards that didn't measure up to that level of document quality.
>
> I'm not objecting strongly to publishing as Informational, but I a= m saying that I expect other ADs to ask that question during IESG Evaluatio= n, and I'd like to understand the thinking before someone asks =E2=80= =A6
That is actually a good question and it would be a possible way forward.
When being in the process updating RFC 2960 to RFC 4960 we were in the same= situation. At that time we wrote
RFC 4460. We thought it is a good idea to not only publish RFC 4960 and let= people figure what changed and
why, but document this. That is why we have RFC 4460. We also thought that = it is a good idea to just have a
single specification for implementing the base protocol. If we would have m= ade RFC 4460 a PS updating RFC 2960,
and implementer would have to read two RFCs. That is why we decided that it= is simpler to publish RFC 4460 as
an informational RFC, and then publish RFC 4960 as a PS updating RFC 2960. = As you see from the numbers, working
on RFC 4460 took a while, but once that was there, publishing RFC 4960 was = straight forward. Just do the editorial
work described in RFC 4460 and some polishing of text we missed when workin= g in the diff way...

Since this plan worked well, the implementers of SCTP (which were also at t= hat time) are used to it, we though
it is a good way to handle the errata in RFC 4960.
>
> I note without suggesting a change that if the material in Section 3 w= as presented in this order
>
> 3.n.1=C2=A0 =C2=A0Description of the Problem
>
>
> 3.n.3.=C2=A0 Solution Description
>
> 3.n.2.=C2=A0 Text Changes to the Document
>
>=C2=A0 =C2=A0 ---------
>=C2=A0 =C2=A0 Old text:
>=C2=A0 =C2=A0 ---------
>
>=C2=A0 =C2=A0 ---------
>=C2=A0 =C2=A0 New text:
>=C2=A0 =C2=A0 ---------
>
> to allow readers to see the solution description before reading the de= tailed text changes, that would likely be easier to parse ...
That is definitely doable and I'm willing to do that change. However, t= his document right now uses the
same structure as RFC 4460 and I would prefer to keep the consistency.
>
> I'm reading this text from the Abstract
>
>=C2=A0 =C2=A0 Because some text is changed several times the last delta= in the
>=C2=A0 =C2=A0 text is the one which should be applied.=C2=A0 In additio= n to the delta a
>=C2=A0 =C2=A0 description of the problem and the details of the solutio= n are also
>=C2=A0 =C2=A0 provided.
>
> as saying that the deltas are cumulative, so you should apply the last= change to specific text, but this text from Section 1
>
>=C2=A0 =C2=A0Note that when reading this document one must use care to = assure that
>=C2=A0 =C2=A0 a field or item is not updated further on within the docu= ment.=C2=A0 Each
>=C2=A0 =C2=A0 section should be applied in sequence to the original [RF= C4960] since
>=C2=A0 =C2=A0 this document is a historical record of the sequential ch= anges that
>=C2=A0 =C2=A0 have been found necessary at various inter-op events and = through
>=C2=A0 =C2=A0 discussion on the list.
>
> seems to say that you should apply multiple deltas to the same text se= quentially. IIUC, the text actually does provide cumulative text deltas, so= using the phrasing from the Abstract in both places would be helpful to th= e reader.
OK. Changed to

=C2=A0 =C2=A0Note that when reading this document one must use care to assu= re that
=C2=A0 =C2=A0a field or item is not updated further on within the document.= =C2=A0 Since
=C2=A0 =C2=A0this document is a historical record of the sequential changes= that
=C2=A0 =C2=A0have been found necessary at various inter-op events and throu= gh
=C2=A0 =C2=A0discussion on the list, the last delta in the text is the one = which
=C2=A0 =C2=A0should be applied.

in https://gith= ub.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac382ef3f6b434

>
> This is a nit, but why is "Inconsistent" capitalized in this= text?
>
>=C2=A0 =C2=A0The handling of the 'Path.Max.Retrans' parameter i= s described in
>=C2=A0 =C2=A0 Section 8.2 and Section 8.3 of [RFC4960] in an Inconsiste= nt way.
Because I (or some autocorrection function of my editor) made a mistake. Fixed in:
https= ://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7ed1f90= 502a9
>
> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ie= tf-tsvwg-rfc4960-errata-05.txt reports a few problems with references. = I THINK this is a side effect of updating (for example) [RFC2434] to be [RF= C5226], and then updating [RFC5226] to be [RFC8126]. If this was my draft, = I'd put a note to the RFC Editor that obsoleted RFCs are used in "= OLD TEXT" sections, and should have the obsoleting RFCs in the "N= EW TEXT" sections, so multiple reviewers won't ask you about the I= DNIT reporting multiple times.
After updating the document to reduce IDNITs warnings regarding too long li= nes in
https://github.= com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a32ecdd00626d5<= br> and cleaning up the references in
https://github.= com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc47766256606e<= br> I added the now true Note to the RFC Editor in
https://github.= com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732ec8a5208de57<= br> >
> I'm probably due for an eye exam, but I'm not seeing any diffe= rence between
>
>=C2=A0 =C2=A0---------
>=C2=A0 =C2=A0 Old text: (Section 1.6)
>=C2=A0 =C2=A0 ---------
>
>=C2=A0 =C2=A0 Transmission Sequence Numbers wrap around when they reach= 2**32 - 1.
>=C2=A0 =C2=A0 That is, the next TSN a DATA chunk MUST use after transmi= tting TSN =3D
>=C2=A0 =C2=A0 2*32 - 1 is TSN =3D 0.
>
> and
>
>=C2=A0 =C2=A0 ---------
>=C2=A0 =C2=A0 New text: (Section 1.6)
>=C2=A0 =C2=A0 ---------
>
>=C2=A0 =C2=A0 Transmission Sequence Numbers wrap around when they reach= 2**32 - 1.
>=C2=A0 =C2=A0 That is, the next TSN a DATA chunk MUST use after transmi= tting TSN =3D
>=C2=A0 =C2=A0 2**32 - 1 is TSN =3D 0.
>
> What am I missing?
The difference between "2*32" and "2**32" (the second o= ccurrence in the OLD and NEW text)...
Whether this should trigger an eye exam or not is left to the reader.
>
> In this text,
>
>=C2=A0 =C2=A0Move the sample code related to CRC32c computation and its=
>=C2=A0 =C2=A0 explanation from the end of Appendix C to the end of Appe= ndix B.
>
> I'm pretty sure I can figure out what text/code actually moves fro= m Appendix C to Appendix B, but I am figuring that out myself. Perhaps it w= ould be clearer if you said something like "all of Appendix C starting= with this sentence to the end of Appendix B".
>
>=C2=A0 =C2=A0 The following non-normative sample code is taken from an = open-source
>=C2=A0 =C2=A0 CRC generator [WILLIAMS93], using the "mirroring&quo= t; technique and
>=C2=A0 =C2=A0 yielding a lookup table for SCTP CRC32c with 256 entries,= each 32
>=C2=A0 =C2=A0 bits wide.
>
> (If I guessed wrong, that's likely because the fix says "code= and its explanation", which sounds like "everything following th= e beginning of the code", but the explanation comes before the code) You guessed perfectly right and I added the suggested text:
https://github.= com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c51534ede667111d<= br> >
> If I'm following closely, the errata described as
>
>=C2=A0 =C2=A0Section 7.2.2 of [RFC4960] is unclear about the order of a= djustments
>=C2=A0 =C2=A0 applied to partial_bytes_acked and cwnd in the congestion= avoidance
>=C2=A0 =C2=A0 phase.
>
> is actually clear about the order - assuming that you read left to rig= ht, it's just clearly wrong :-)
I see. But there is no explicit statement that you have to do it in that or= der.

What about:

Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance
phase.
which is committed in
https://github.= com/sctplab/rfc4960bis/commit/9fa55976e242ff1e5125637336321887a2f57e80<= br> >
> At the risk of asking a technical question ;-)
>
>=C2=A0 =C2=A0The counter SHOULD be reset each time a DATA chunk sent to= that peer
>=C2=A0 =C2=A0 endpoint is acknowledged (by the reception of a SACK). Wh= en a
>=C2=A0 =C2=A0 HEARTBEAT ACK is received from the peer endpoint, the cou= nter SHOULD
>=C2=A0 =C2=A0 also be reset. The receiver of the HEARTBEAT ACK MAY choo= se not to
>=C2=A0 =C2=A0 clear the counter if there is outstanding data on the ass= ociation.
>=C2=A0 =C2=A0 This allows for handling the possible difference in reach= ability
>=C2=A0 =C2=A0 based on DATA chunks and HEARTBEAT chunks.
>
> why is not clearing the counter if there is outstanding data on the as= sociation a good idea? (this was "shall", but is now "SHOULD= ")
You are correct. It should be a MUST.
Changed in: htt= ps://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e353963= 7f9dafe
>
> I have a similar (MUST vs. SHOULD) question about
>
>=C2=A0 =C2=A0Upon the receipt of the HEARTBEAT ACK, the sender of the H= EARTBEAT
>=C2=A0 =C2=A0 SHOULD clear the error counter of the destination transpo= rt address
>=C2=A0 =C2=A0 to which the HEARTBEAT was sent, and mark the destination= transport
>=C2=A0 =C2=A0 address as active if it is not so marked.
>
> Why would not clearing the error counter be a good idea?
You are right. The "should" should be changed to a "MUST&quo= t;, not a "SHOULD. Done in:
https://github.= com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c5a67a1b6faeb<= br> >
> Section 3.21 has multiple occurrences of something like
>
>=C2=A0 =C2=A0o=C2=A0 partial flag - if this returned flag is set to 1, = then this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Receive contains a partial delivery of the w= hole message.=C2=A0 When
>=C2=A0 =C2=A0 =C2=A0 =C2=A0^ this "Receive" is capitalized >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this flag is set, the stream id and Stream S= equence Number MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accompany this receive.=C2=A0 When this flag= is set to 0, it indicates
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^ this "receive" is not capitalized
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that no more deliveries will be received for= this Stream Sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Number.
>
> Is that intentional?
No. This is even not changed by this documents, but also inconsistent in RF= C 4960.
I also improved the consistency of the spelling:
However, I improved the text:
https://github.= com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6fae72eaf1751<= br>


--000000000000c60d62056cb7a79c-- From nobody Mon May 21 08:22:13 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEB912E895; Mon, 21 May 2018 08:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no 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 LG3N3LTRIAm8; Mon, 21 May 2018 08:22:06 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id A75F21274D2; Mon, 21 May 2018 08:22:04 -0700 (PDT) Received: from [137.50.183.77] (oa-edu-183-77.wireless.abdn.ac.uk [137.50.183.77]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B24311B00067; Mon, 21 May 2018 16:22:03 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-83B553CB-B491-441C-A5A0-75A0CB9D1F69 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Mon, 21 May 2018 16:22:03 +0100 Cc: Michael Tuexen , draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> To: Spencer Dawkins at IETF Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 15:22:12 -0000 --Apple-Mail-83B553CB-B491-441C-A5A0-75A0CB9D1F69 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I will do Gorry=20 > On 21 May 2018, at 14:55, Spencer Dawkins at IETF wrote: >=20 > Hi, Gorry the Shepherd, >=20 >> On Sun, May 20, 2018 at 11:53 AM Michael Tuexen w= rote: >>=20 >>=20 >> > On 11. May 2018, at 22:12, Spencer Dawkins at IETF wrote: >> >=20 >> > Dear Authors, >> >=20 >> > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst = wrote: >> > Gorry Fairhurst has requested publication of draft-ietf-tsvwg-rfc4960-e= rrata-05 as Informational on behalf of the TSVWG working group. >> >=20 >> > Please verify the document's state at https://datatracker.ietf.org/doc/= draft-ietf-tsvwg-rfc4960-errata/ >> >=20 >> > Thanks for doing this work (and even more so, for being willing to prov= ide an updated RFC to implementers, at some point in the future).=20 >> >=20 >> > I've completed AD evaluation for this draft, and have comments, but alm= ost all of them are requests for clarifications.=20 >> >=20 >> > I'd like to work through them with you before requesting Last Call. Ple= ase let me know if you have questions. >> Hi Spencer, >>=20 >> thanks for the review. I'll provide feedback inline. >>=20 >> Please note that I was also notified recently about a paragraph which sho= uld >> have been removed when moving from RFC 2960 to RFC 4960, but the removal w= as >> missed and the text is still there. I have received this not via any mail= ing >> list but via direct e-mail conversation. The fix is included as >> https://github.com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283= ab5e82d4fc9c >>=20 >> You can see the current version in the git repository of the document in >> http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2Fra= w.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-r= fc4960-errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&Submit=3DSubmi= t >>=20 >> If you want additional changes, please let me know. If you are fine with t= he current >> version in the git repo, I can submit it anytime... >=20 > Michael's responses (whether they resulted in changes or in explanations t= o the evaluating AD) work for me. Thanks to Michael for the quick response. >=20 > Please invite Michael to submit a new version, when you think that's the r= ight thing to do. >=20 > I would appreciate it if you could add a few words reflecting Michael's re= sponse on Why This Is Informational to the shepherd write-up, perhaps under (= 1) or (2)/Working Group Summary, where it will be copied into the IESG ballo= t, so that we won't be explaining this 14 more times during IESG evaluation ;= -) >=20 > Spencer > =20 >> Best regards >> Michael >> >=20 >> > Thanks! >> >=20 >> > Spencer=20 >> >=20 >> > A high-order bit here ...=20 >> >=20 >> > I'm not sure why this draft isn't standards-track, and I wonder if ther= e's a reason it doesn't UPDATE RFC 4960, unless that's a side effect of bein= g an Informational draft that would update a standards-track RFC.=20 >> >=20 >> > I'm thinking that this draft has achieved WG consensus, and if it's pub= lished after Last Call, it would have IETF consensus, and it's been reviewed= by implementers. We've certainly published Proposed Standards that didn't m= easure up to that level of document quality. >> >=20 >> > I'm not objecting strongly to publishing as Informational, but I am say= ing that I expect other ADs to ask that question during IESG Evaluation, and= I'd like to understand the thinking before someone asks =E2=80=A6 >> That is actually a good question and it would be a possible way forward. >>=20 >> When being in the process updating RFC 2960 to RFC 4960 we were in the sa= me situation. At that time we wrote >> RFC 4460. We thought it is a good idea to not only publish RFC 4960 and l= et people figure what changed and >> why, but document this. That is why we have RFC 4460. We also thought tha= t it is a good idea to just have a >> single specification for implementing the base protocol. If we would have= made RFC 4460 a PS updating RFC 2960, >> and implementer would have to read two RFCs. That is why we decided that i= t is simpler to publish RFC 4460 as >> an informational RFC, and then publish RFC 4960 as a PS updating RFC 2960= . As you see from the numbers, working >> on RFC 4460 took a while, but once that was there, publishing RFC 4960 wa= s straight forward. Just do the editorial >> work described in RFC 4460 and some polishing of text we missed when work= ing in the diff way... >>=20 >> Since this plan worked well, the implementers of SCTP (which were also at= that time) are used to it, we though >> it is a good way to handle the errata in RFC 4960. >> >=20 >> > I note without suggesting a change that if the material in Section 3 wa= s presented in this order >> >=20 >> > 3.n.1 Description of the Problem >> >=20 >> >=20 >> > 3.n.3. Solution Description >> >=20 >> > 3.n.2. Text Changes to the Document >> >=20 >> > --------- >> > Old text: >> > --------- >> >=20 >> > --------- >> > New text: >> > --------- >> >=20 >> > to allow readers to see the solution description before reading the det= ailed text changes, that would likely be easier to parse ... >> That is definitely doable and I'm willing to do that change. However, thi= s document right now uses the >> same structure as RFC 4460 and I would prefer to keep the consistency. >> >=20 >> > I'm reading this text from the Abstract=20 >> >=20 >> > Because some text is changed several times the last delta in the >> > text is the one which should be applied. In addition to the delta a= >> > description of the problem and the details of the solution are also >> > provided. >> >=20 >> > as saying that the deltas are cumulative, so you should apply the last c= hange to specific text, but this text from Section 1=20 >> >=20 >> > Note that when reading this document one must use care to assure that= >> > a field or item is not updated further on within the document. Each= >> > section should be applied in sequence to the original [RFC4960] sinc= e >> > this document is a historical record of the sequential changes that >> > have been found necessary at various inter-op events and through >> > discussion on the list. >> >=20 >> > seems to say that you should apply multiple deltas to the same text seq= uentially. IIUC, the text actually does provide cumulative text deltas, so u= sing the phrasing from the Abstract in both places would be helpful to the r= eader. >> OK. Changed to >>=20 >> Note that when reading this document one must use care to assure that >> a field or item is not updated further on within the document. Since >> this document is a historical record of the sequential changes that >> have been found necessary at various inter-op events and through >> discussion on the list, the last delta in the text is the one which >> should be applied. >>=20 >> in https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf= 9ac382ef3f6b434 >>=20 >> >=20 >> > This is a nit, but why is "Inconsistent" capitalized in this text? >> >=20 >> > The handling of the 'Path.Max.Retrans' parameter is described in >> > Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. >> Because I (or some autocorrection function of my editor) made a mistake. >> Fixed in: https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f844= 43e1a4d52a7ed1f90502a9 >> >=20 >> > https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-iet= f-tsvwg-rfc4960-errata-05.txt reports a few problems with references. I THIN= K this is a side effect of updating (for example) [RFC2434] to be [RFC5226],= and then updating [RFC5226] to be [RFC8126]. If this was my draft, I'd put a= note to the RFC Editor that obsoleted RFCs are used in "OLD TEXT" sections,= and should have the obsoleting RFCs in the "NEW TEXT" sections, so multiple= reviewers won't ask you about the IDNIT reporting multiple times. >> After updating the document to reduce IDNITs warnings regarding too long l= ines in >> https://github.com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a3= 2ecdd00626d5 >> and cleaning up the references in >> https://github.com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc= 47766256606e >> I added the now true Note to the RFC Editor in >> https://github.com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732= ec8a5208de57 >> >=20 >> > I'm probably due for an eye exam, but I'm not seeing any difference bet= ween=20 >> >=20 >> > --------- >> > Old text: (Section 1.6) >> > --------- >> >=20 >> > Transmission Sequence Numbers wrap around when they reach 2**32 - 1.= >> > That is, the next TSN a DATA chunk MUST use after transmitting TSN =3D= >> > 2*32 - 1 is TSN =3D 0. >> >=20 >> > and >> >=20 >> > --------- >> > New text: (Section 1.6) >> > --------- >> >=20 >> > Transmission Sequence Numbers wrap around when they reach 2**32 - 1.= >> > That is, the next TSN a DATA chunk MUST use after transmitting TSN =3D= >> > 2**32 - 1 is TSN =3D 0. >> >=20 >> > What am I missing? >> The difference between "2*32" and "2**32" (the second occurrence in the O= LD and NEW text)... >> Whether this should trigger an eye exam or not is left to the reader. >> >=20 >> > In this text,=20 >> >=20 >> > Move the sample code related to CRC32c computation and its >> > explanation from the end of Appendix C to the end of Appendix B. >> >=20 >> > I'm pretty sure I can figure out what text/code actually moves from App= endix C to Appendix B, but I am figuring that out myself. Perhaps it would b= e clearer if you said something like "all of Appendix C starting with this s= entence to the end of Appendix B". >> >=20 >> > The following non-normative sample code is taken from an open-source= >> > CRC generator [WILLIAMS93], using the "mirroring" technique and >> > yielding a lookup table for SCTP CRC32c with 256 entries, each 32 >> > bits wide. >> >=20 >> > (If I guessed wrong, that's likely because the fix says "code and its e= xplanation", which sounds like "everything following the beginning of the co= de", but the explanation comes before the code) >> You guessed perfectly right and I added the suggested text: >> https://github.com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c515= 34ede667111d >> >=20 >> > If I'm following closely, the errata described as=20 >> >=20 >> > Section 7.2.2 of [RFC4960] is unclear about the order of adjustments >> > applied to partial_bytes_acked and cwnd in the congestion avoidance >> > phase. >> >=20 >> > is actually clear about the order - assuming that you read left to righ= t, it's just clearly wrong :-) >> I see. But there is no explicit statement that you have to do it in that o= rder.=20 >>=20 >> What about: >>=20 >> Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments >> applied to partial_bytes_acked and cwnd in the congestion avoidance >> phase. >> which is committed in >> https://github.com/sctplab/rfc4960bis/commit/9fa55976e242ff1e512563733632= 1887a2f57e80 >> >=20 >> > At the risk of asking a technical question ;-) >> >=20 >> > The counter SHOULD be reset each time a DATA chunk sent to that peer >> > endpoint is acknowledged (by the reception of a SACK). When a >> > HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD= >> > also be reset. The receiver of the HEARTBEAT ACK MAY choose not to >> > clear the counter if there is outstanding data on the association. >> > This allows for handling the possible difference in reachability >> > based on DATA chunks and HEARTBEAT chunks. >> >=20 >> > why is not clearing the counter if there is outstanding data on the ass= ociation a good idea? (this was "shall", but is now "SHOULD") >> You are correct. It should be a MUST. >> Changed in: https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1= 180b7d0363e3539637f9dafe >> >=20 >> > I have a similar (MUST vs. SHOULD) question about=20 >> >=20 >> > Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT >> > SHOULD clear the error counter of the destination transport address >> > to which the HEARTBEAT was sent, and mark the destination transport >> > address as active if it is not so marked. >> >=20 >> > Why would not clearing the error counter be a good idea? >> You are right. The "should" should be changed to a "MUST", not a "SHOULD.= Done in: >> https://github.com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c= 5a67a1b6faeb >> >=20 >> > Section 3.21 has multiple occurrences of something like=20 >> >=20 >> > o partial flag - if this returned flag is set to 1, then this >> > Receive contains a partial delivery of the whole message. When >> > ^ this "Receive" is capitalized >> >=20 >> > this flag is set, the stream id and Stream Sequence Number MUST >> > accompany this receive. When this flag is set to 0, it indicates= >> > ^ this "receive" is not capitalized >> >=20 >> > that no more deliveries will be received for this Stream Sequence= >> > Number. >> >=20 >> > Is that intentional? >> No. This is even not changed by this documents, but also inconsistent in R= FC 4960. >> I also improved the consistency of the spelling: >> However, I improved the text: >> https://github.com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6= fae72eaf1751 >>=20 >>=20 >>=20 --Apple-Mail-83B553CB-B491-441C-A5A0-75A0CB9D1F69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I will do

Gorry 

On 21 May 2018, at 14:55, Spencer Dawkins a= t IETF <spencerdawkins.i= etf@gmail.com> wrote:

Hi, Gorry the Shepherd,

On Sun, May 20, 2018 at 11:53 AM Michael Tuexen <tuexen@fh-muenster.de> wrote:


> On 11. May 2018, at 22:12, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail= .com> wrote:
>
> Dear Authors,
>
> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:<= br> > Gorry Fairhurst has requested publication of draft-ietf-tsvwg-rfc4960-e= rrata-05 as Informational on behalf of the TSVWG working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/<= br> >
> Thanks for doing this work (and even more so, for being willing to prov= ide an updated RFC to implementers, at some point in the future).
>
> I've completed AD evaluation for this draft, and have comments, but alm= ost all of them are requests for clarifications.
>
> I'd like to work through them with you before requesting Last Call. Ple= ase let me know if you have questions.
Hi Spencer,

thanks for the review. I'll provide feedback inline.

Please note that I was also notified recently about a paragraph which should=
have been removed when moving from RFC 2960 to RFC 4960, but the removal was=
missed and the text is still there. I have received this not via any mailing=
list but via direct e-mail conversation. The fix is included as
https://github.co= m/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283ab5e82d4fc9c
=
You can see the current version in the git repository of the document in
= http://xml= 2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2Fraw.githu= busercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-rfc4960-= errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&Submit=3D= Submit

If you want additional changes, please let me know. If you are fine with the= current
version in the git repo, I can submit it anytime...
Michael's responses (whether they resulted in changes or in expl= anations to the evaluating AD) work for me. Thanks to Michael for the quick r= esponse.

Please invite Michael to submit a new vers= ion, when you think that's the right thing to do.

I= would appreciate it if you could add a few words reflecting Michael's respo= nse on Why This Is Informational to the shepherd write-up, perhaps under (1)= or (2)/Working Group Summary, where it will be copied into the IESG ballot,= so that we won't be explaining this 14 more times during IESG evaluation ;-= )

Spencer
 
Best regards
Michael
>
> Thanks!
>
> Spencer
>
> A high-order bit here ...
>
> I'm not sure why this draft isn't standards-track, and I wonder if ther= e's a reason it doesn't UPDATE RFC 4960, unless that's a side effect of bein= g an Informational draft that would update a standards-track RFC.
>
> I'm thinking that this draft has achieved WG consensus, and if it's pub= lished after Last Call, it would have IETF consensus, and it's been reviewed= by implementers. We've certainly published Proposed Standards that didn't m= easure up to that level of document quality.
>
> I'm not objecting strongly to publishing as Informational, but I am say= ing that I expect other ADs to ask that question during IESG Evaluation, and= I'd like to understand the thinking before someone asks =E2=80=A6
That is actually a good question and it would be a possible way forward.
=
When being in the process updating RFC 2960 to RFC 4960 we were in the same s= ituation. At that time we wrote
RFC 4460. We thought it is a good idea to not only publish RFC 4960 and let p= eople figure what changed and
why, but document this. That is why we have RFC 4460. We also thought that i= t is a good idea to just have a
single specification for implementing the base protocol. If we would have ma= de RFC 4460 a PS updating RFC 2960,
and implementer would have to read two RFCs. That is why we decided that it i= s simpler to publish RFC 4460 as
an informational RFC, and then publish RFC 4960 as a PS updating RFC 2960. A= s you see from the numbers, working
on RFC 4460 took a while, but once that was there, publishing RFC 4960 was s= traight forward. Just do the editorial
work described in RFC 4460 and some polishing of text we missed when working= in the diff way...

Since this plan worked well, the implementers of SCTP (which were also at th= at time) are used to it, we though
it is a good way to handle the errata in RFC 4960.
>
> I note without suggesting a change that if the material in Section 3 wa= s presented in this order
>
> 3.n.1   Description of the Problem
>
>
> 3.n.3.  Solution Description
>
> 3.n.2.  Text Changes to the Document
>
>    ---------
>    Old text:
>    ---------
>
>    ---------
>    New text:
>    ---------
>
> to allow readers to see the solution description before reading the det= ailed text changes, that would likely be easier to parse ...
That is definitely doable and I'm willing to do that change. However, this d= ocument right now uses the
same structure as RFC 4460 and I would prefer to keep the consistency.
>
> I'm reading this text from the Abstract
>
>    Because some text is changed several times the last delta i= n the
>    text is the one which should be applied.  In addition= to the delta a
>    description of the problem and the details of the solution= are also
>    provided.
>
> as saying that the deltas are cumulative, so you should apply the last c= hange to specific text, but this text from Section 1
>
>   Note that when reading this document one must use care to a= ssure that
>    a field or item is not updated further on within the docum= ent.  Each
>    section should be applied in sequence to the original [RFC= 4960] since
>    this document is a historical record of the sequential cha= nges that
>    have been found necessary at various inter-op events and t= hrough
>    discussion on the list.
>
> seems to say that you should apply multiple deltas to the same text seq= uentially. IIUC, the text actually does provide cumulative text deltas, so u= sing the phrasing from the Abstract in both places would be helpful to the r= eader.
OK. Changed to

   Note that when reading this document one must use care to assur= e that
   a field or item is not updated further on within the document.&= nbsp; Since
   this document is a historical record of the sequential changes t= hat
   have been found necessary at various inter-op events and throug= h
   discussion on the list, the last delta in the text is the one w= hich
   should be applied.

in https://github= .com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac382ef3f6b434<= br>
>
> This is a nit, but why is "Inconsistent" capitalized in this text?
>
>   The handling of the 'Path.Max.Retrans' parameter is describ= ed in
>    Section 8.2 and Section 8.3 of [RFC4960] in an Inconsisten= t way.
Because I (or some autocorrection function of my editor) made a mistake.
= Fixed in: https:/= /github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7ed1f90502= a9
>
> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-= tsvwg-rfc4960-errata-05.txt reports a few problems with references. I TH= INK this is a side effect of updating (for example) [RFC2434] to be [RFC5226= ], and then updating [RFC5226] to be [RFC8126]. If this was my draft, I'd pu= t a note to the RFC Editor that obsoleted RFCs are used in "OLD TEXT" sectio= ns, and should have the obsoleting RFCs in the "NEW TEXT" sections, so multi= ple reviewers won't ask you about the IDNIT reporting multiple times.
After updating the document to reduce IDNITs warnings regarding too long lin= es in
https://github.co= m/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a32ecdd00626d5
= and cleaning up the references in
https://github.co= m/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc47766256606e
= I added the now true Note to the RFC Editor in
https://github.co= m/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732ec8a5208de57
= >
> I'm probably due for an eye exam, but I'm not seeing any difference bet= ween
>
>   ---------
>    Old text: (Section 1.6)
>    ---------
>
>    Transmission Sequence Numbers wrap around when they reach 2= **32 - 1.
>    That is, the next TSN a DATA chunk MUST use after transmit= ting TSN =3D
>    2*32 - 1 is TSN =3D 0.
>
> and
>
>    ---------
>    New text: (Section 1.6)
>    ---------
>
>    Transmission Sequence Numbers wrap around when they reach 2= **32 - 1.
>    That is, the next TSN a DATA chunk MUST use after transmit= ting TSN =3D
>    2**32 - 1 is TSN =3D 0.
>
> What am I missing?
The difference between "2*32" and "2**32" (the second occurrence in the OLD a= nd NEW text)...
Whether this should trigger an eye exam or not is left to the reader.
>
> In this text,
>
>   Move the sample code related to CRC32c computation and its<= br> >    explanation from the end of Appendix C to the end of Appen= dix B.
>
> I'm pretty sure I can figure out what text/code actually moves from App= endix C to Appendix B, but I am figuring that out myself. Perhaps it would b= e clearer if you said something like "all of Appendix C starting with this s= entence to the end of Appendix B".
>
>    The following non-normative sample code is taken from an o= pen-source
>    CRC generator [WILLIAMS93], using the "mirroring" techniqu= e and
>    yielding a lookup table for SCTP CRC32c with 256 entries, e= ach 32
>    bits wide.
>
> (If I guessed wrong, that's likely because the fix says "code and its e= xplanation", which sounds like "everything following the beginning of the co= de", but the explanation comes before the code)
You guessed perfectly right and I added the suggested text:
https://github.co= m/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c51534ede667111d
= >
> If I'm following closely, the errata described as
>
>   Section 7.2.2 of [RFC4960] is unclear about the order of ad= justments
>    applied to partial_bytes_acked and cwnd in the congestion a= voidance
>    phase.
>
> is actually clear about the order - assuming that you read left to righ= t, it's just clearly wrong :-)
I see. But there is no explicit statement that you have to do it in that ord= er.

What about:

Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments
= applied to partial_bytes_acked and cwnd in the congestion avoidance
phase.
which is committed in
https://github.co= m/sctplab/rfc4960bis/commit/9fa55976e242ff1e5125637336321887a2f57e80
= >
> At the risk of asking a technical question ;-)
>
>   The counter SHOULD be reset each time a DATA chunk sent to t= hat peer
>    endpoint is acknowledged (by the reception of a SACK). Whe= n a
>    HEARTBEAT ACK is received from the peer endpoint, the coun= ter SHOULD
>    also be reset. The receiver of the HEARTBEAT ACK MAY choos= e not to
>    clear the counter if there is outstanding data on the asso= ciation.
>    This allows for handling the possible difference in reacha= bility
>    based on DATA chunks and HEARTBEAT chunks.
>
> why is not clearing the counter if there is outstanding data on the ass= ociation a good idea? (this was "shall", but is now "SHOULD")
You are correct. It should be a MUST.
Changed in: https= ://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e3539637f9= dafe
>
> I have a similar (MUST vs. SHOULD) question about
>
>   Upon the receipt of the HEARTBEAT ACK, the sender of the HE= ARTBEAT
>    SHOULD clear the error counter of the destination transpor= t address
>    to which the HEARTBEAT was sent, and mark the destination t= ransport
>    address as active if it is not so marked.
>
> Why would not clearing the error counter be a good idea?
You are right. The "should" should be changed to a "MUST", not a "SHOULD. Do= ne in:
https://github.co= m/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c5a67a1b6faeb
= >
> Section 3.21 has multiple occurrences of something like
>
>   o  partial flag - if this returned flag is set to 1, t= hen this
>       Receive contains a partial delivery of the wh= ole message.  When
>       ^ this "Receive" is capitalized
>
>       this flag is set, the stream id and Stream Se= quence Number MUST
>       accompany this receive.  When this flag i= s set to 0, it indicates
>                    &n= bsp; ^ this "receive" is not capitalized
>
>       that no more deliveries will be received for t= his Stream Sequence
>       Number.
>
> Is that intentional?
No. This is even not changed by this documents, but also inconsistent in RFC= 4960.
I also improved the consistency of the spelling:
However, I improved the text:
https://github.co= m/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6fae72eaf1751
=


= --Apple-Mail-83B553CB-B491-441C-A5A0-75A0CB9D1F69-- From nobody Mon May 21 09:08:13 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0312778E; Mon, 21 May 2018 09:08:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152691889200.23089.5162587872274464880@ietfa.amsl.com> Date: Mon, 21 May 2018 09:08:12 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4960-errata-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 16:08:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : RFC 4960 Errata and Issues Authors : Randall R. Stewart Michael Tuexen Maksim Proshin Filename : draft-ietf-tsvwg-rfc4960-errata-06.txt Pages : 89 Date : 2018-05-21 Abstract: This document is a compilation of issues found since the publication of RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time ordered way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc4960-errata-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-errata-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 21 09:19:07 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64A4128959; Mon, 21 May 2018 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcvLZ54czll3; Mon, 21 May 2018 09:19:01 -0700 (PDT) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E75D12778E; Mon, 21 May 2018 09:19:01 -0700 (PDT) Received: by mail-yw0-x243.google.com with SMTP id r202-v6so4643664ywg.10; Mon, 21 May 2018 09:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IH+JaCKwisgn252YGEpvjxLZP9svVw9yDwQ3IRsU+a8=; b=Ivkvgi21uTIwc3VHfy+lugWKPdRIYLZx2hLQDFF5ArtUXbCrmYEIceCRT3k2Xw+x9/ eiDE1i1WTvuGZKps+Az7+uNpF3Wo0rjKBvgtiqBhi0hFaAtXA3jS5AHQnBNcOy7fHHmc l3TXzamiIe+gQ52a2ACkTwJVcjNTjTKkvqTLNoFcvSzvEvmiNZWtomQkJqHSfXEyaD1H hSt7r0auPdUWcP0W2p1phaLUvzdR0l+YKrWuRG22nu0anZ+EvjVWSyhQnR/c40wx4vtE SlO2ONCRYpPq3qBe3QVtfY++OVwpkGCuT/fgC5br0PzCnbE0tD02qhGUdHYw/D80ueHY lioA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IH+JaCKwisgn252YGEpvjxLZP9svVw9yDwQ3IRsU+a8=; b=rzosmFUWGl4buFt/ABcJAKcuhoafnxYMyVm6qyKHyNGxTjw/nlgJfn8IVVDTJvK3Ru Et1IWH41ovf6Z5gWom3zwDe1BLsa55Xbg9faOF+55ucgHzw1yWlFAFFbVDlnyuhVrxIm kkeT/N+pXx8cLbzx+ptGTSyxpKPi6Gz55VqJUdids88jQbrmM5jp4OoqpPwFmfciOWHy XLflZCwHLDAzRNsZObu2QLXCp0uXRIMyhdGTvnkLJ3FH1NtX/H0bdF7BmRFTbeb7jgXW L5aYniL1YwwyAOboVF9Ew5fjONxttmydwbw2IqRG0O1wJ13Yk+/KBy2NtfgmLKx4IN0B rm7A== X-Gm-Message-State: ALKqPwdfz7Xz52YFtivT8jwMKkjMui3okJvrSPdJWylc49fl6BYn2gkm pwHj/m7SM0bWzcuvHNAAMxSyxt1N8lYLIaOxdoA= X-Google-Smtp-Source: AB8JxZr2C3Dr/G681XzJTHZL5MlbUb/JP0mN77X6/tbwWbugQ62GQHxgfFnVJMQVmgvwLv7AbmGjICzTGpFaYw9/61U= X-Received: by 2002:a0d:ed06:: with SMTP id w6-v6mr9976003ywe.467.1526919539965; Mon, 21 May 2018 09:18:59 -0700 (PDT) MIME-Version: 1.0 References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 21 May 2018 11:18:46 -0500 Message-ID: To: G Fairhurst Cc: Michael Tuexen , draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000c7c5c3056cb9a8b1" Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 16:19:05 -0000 --000000000000c7c5c3056cb9a8b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Gorry, On Mon, May 21, 2018 at 10:22 AM Gorry (erg) wrote: > I will do > Just to confirm, I'll be happy to request Last Call on -06 as submitted. Let me know when you think we're ready for that. Thanks! Spencer > Gorry > > On 21 May 2018, at 14:55, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Gorry the Shepherd, > > On Sun, May 20, 2018 at 11:53 AM Michael Tuexen > wrote: > >> >> >> > On 11. May 2018, at 22:12, Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> > >> > Dear Authors, >> > >> > On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst >> wrote: >> > Gorry Fairhurst has requested publication of >> draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of the TSV= WG >> working group. >> > >> > Please verify the document's state at >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ >> > >> > Thanks for doing this work (and even more so, for being willing to >> provide an updated RFC to implementers, at some point in the future). >> > >> > I've completed AD evaluation for this draft, and have comments, but >> almost all of them are requests for clarifications. >> > >> > I'd like to work through them with you before requesting Last Call. >> Please let me know if you have questions. >> Hi Spencer, >> >> thanks for the review. I'll provide feedback inline. >> >> Please note that I was also notified recently about a paragraph which >> should >> have been removed when moving from RFC 2960 to RFC 4960, but the removal >> was >> missed and the text is still there. I have received this not via any >> mailing >> list but via direct e-mail conversation. The fix is included as >> >> https://github.com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f28= 3ab5e82d4fc9c >> >> You can see the current version in the git repository of the document in >> >> http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2= Fraw.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsv= wg-rfc4960-errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&Submit=3D= Submit >> >> If you want additional changes, please let me know. If you are fine with >> the current >> version in the git repo, I can submit it anytime... >> > > Michael's responses (whether they resulted in changes or in explanations > to the evaluating AD) work for me. Thanks to Michael for the quick respon= se. > > Please invite Michael to submit a new version, when you think that's the > right thing to do. > > I would appreciate it if you could add a few words reflecting Michael's > response on Why This Is Informational to the shepherd write-up, perhaps > under (1) or (2)/Working Group Summary, where it will be copied into the > IESG ballot, so that we won't be explaining this 14 more times during IES= G > evaluation ;-) > > Spencer > > >> Best regards >> Michael >> > >> > Thanks! >> > >> > Spencer >> > >> > A high-order bit here ... >> > >> > I'm not sure why this draft isn't standards-track, and I wonder if >> there's a reason it doesn't UPDATE RFC 4960, unless that's a side effect= of >> being an Informational draft that would update a standards-track RFC. >> > >> > I'm thinking that this draft has achieved WG consensus, and if it's >> published after Last Call, it would have IETF consensus, and it's been >> reviewed by implementers. We've certainly published Proposed Standards t= hat >> didn't measure up to that level of document quality. >> > >> > I'm not objecting strongly to publishing as Informational, but I am >> saying that I expect other ADs to ask that question during IESG Evaluati= on, >> and I'd like to understand the thinking before someone asks =E2=80=A6 >> That is actually a good question and it would be a possible way forward. >> >> When being in the process updating RFC 2960 to RFC 4960 we were in the >> same situation. At that time we wrote >> RFC 4460. We thought it is a good idea to not only publish RFC 4960 and >> let people figure what changed and >> why, but document this. That is why we have RFC 4460. We also thought >> that it is a good idea to just have a >> single specification for implementing the base protocol. If we would hav= e >> made RFC 4460 a PS updating RFC 2960, >> and implementer would have to read two RFCs. That is why we decided that >> it is simpler to publish RFC 4460 as >> an informational RFC, and then publish RFC 4960 as a PS updating RFC >> 2960. As you see from the numbers, working >> on RFC 4460 took a while, but once that was there, publishing RFC 4960 >> was straight forward. Just do the editorial >> work described in RFC 4460 and some polishing of text we missed when >> working in the diff way... >> >> Since this plan worked well, the implementers of SCTP (which were also a= t >> that time) are used to it, we though >> it is a good way to handle the errata in RFC 4960. >> > >> > I note without suggesting a change that if the material in Section 3 >> was presented in this order >> > >> > 3.n.1 Description of the Problem >> > >> > >> > 3.n.3. Solution Description >> > >> > 3.n.2. Text Changes to the Document >> > >> > --------- >> > Old text: >> > --------- >> > >> > --------- >> > New text: >> > --------- >> > >> > to allow readers to see the solution description before reading the >> detailed text changes, that would likely be easier to parse ... >> That is definitely doable and I'm willing to do that change. However, >> this document right now uses the >> same structure as RFC 4460 and I would prefer to keep the consistency. >> > >> > I'm reading this text from the Abstract >> > >> > Because some text is changed several times the last delta in the >> > text is the one which should be applied. In addition to the delta = a >> > description of the problem and the details of the solution are also >> > provided. >> > >> > as saying that the deltas are cumulative, so you should apply the last >> change to specific text, but this text from Section 1 >> > >> > Note that when reading this document one must use care to assure tha= t >> > a field or item is not updated further on within the document. Eac= h >> > section should be applied in sequence to the original [RFC4960] sin= ce >> > this document is a historical record of the sequential changes that >> > have been found necessary at various inter-op events and through >> > discussion on the list. >> > >> > seems to say that you should apply multiple deltas to the same text >> sequentially. IIUC, the text actually does provide cumulative text delta= s, >> so using the phrasing from the Abstract in both places would be helpful = to >> the reader. >> OK. Changed to >> >> Note that when reading this document one must use care to assure that >> a field or item is not updated further on within the document. Since >> this document is a historical record of the sequential changes that >> have been found necessary at various inter-op events and through >> discussion on the list, the last delta in the text is the one which >> should be applied. >> >> in >> https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9a= c382ef3f6b434 >> >> > >> > This is a nit, but why is "Inconsistent" capitalized in this text? >> > >> > The handling of the 'Path.Max.Retrans' parameter is described in >> > Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. >> Because I (or some autocorrection function of my editor) made a mistake. >> Fixed in: >> https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52= a7ed1f90502a9 >> > >> > >> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf= -tsvwg-rfc4960-errata-05.txt >> reports a few problems with references. I THINK this is a side effect of >> updating (for example) [RFC2434] to be [RFC5226], and then updating >> [RFC5226] to be [RFC8126]. If this was my draft, I'd put a note to the R= FC >> Editor that obsoleted RFCs are used in "OLD TEXT" sections, and should h= ave >> the obsoleting RFCs in the "NEW TEXT" sections, so multiple reviewers wo= n't >> ask you about the IDNIT reporting multiple times. >> After updating the document to reduce IDNITs warnings regarding too long >> lines in >> >> https://github.com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a= 32ecdd00626d5 >> and cleaning up the references in >> >> https://github.com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398df= c47766256606e >> I added the now true Note to the RFC Editor in >> >> https://github.com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e73= 2ec8a5208de57 >> > >> > I'm probably due for an eye exam, but I'm not seeing any difference >> between >> > >> > --------- >> > Old text: (Section 1.6) >> > --------- >> > >> > Transmission Sequence Numbers wrap around when they reach 2**32 - 1= . >> > That is, the next TSN a DATA chunk MUST use after transmitting TSN = =3D >> > 2*32 - 1 is TSN =3D 0. >> > >> > and >> > >> > --------- >> > New text: (Section 1.6) >> > --------- >> > >> > Transmission Sequence Numbers wrap around when they reach 2**32 - 1= . >> > That is, the next TSN a DATA chunk MUST use after transmitting TSN = =3D >> > 2**32 - 1 is TSN =3D 0. >> > >> > What am I missing? >> The difference between "2*32" and "2**32" (the second occurrence in the >> OLD and NEW text)... >> Whether this should trigger an eye exam or not is left to the reader. >> > >> > In this text, >> > >> > Move the sample code related to CRC32c computation and its >> > explanation from the end of Appendix C to the end of Appendix B. >> > >> > I'm pretty sure I can figure out what text/code actually moves from >> Appendix C to Appendix B, but I am figuring that out myself. Perhaps it >> would be clearer if you said something like "all of Appendix C starting >> with this sentence to the end of Appendix B". >> > >> > The following non-normative sample code is taken from an open-sourc= e >> > CRC generator [WILLIAMS93], using the "mirroring" technique and >> > yielding a lookup table for SCTP CRC32c with 256 entries, each 32 >> > bits wide. >> > >> > (If I guessed wrong, that's likely because the fix says "code and its >> explanation", which sounds like "everything following the beginning of t= he >> code", but the explanation comes before the code) >> You guessed perfectly right and I added the suggested text: >> >> https://github.com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c51= 534ede667111d >> > >> > If I'm following closely, the errata described as >> > >> > Section 7.2.2 of [RFC4960] is unclear about the order of adjustments >> > applied to partial_bytes_acked and cwnd in the congestion avoidance >> > phase. >> > >> > is actually clear about the order - assuming that you read left to >> right, it's just clearly wrong :-) >> I see. But there is no explicit statement that you have to do it in that >> order. >> >> What about: >> >> Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments >> applied to partial_bytes_acked and cwnd in the congestion avoidance >> phase. >> which is committed in >> >> https://github.com/sctplab/rfc4960bis/commit/9fa55976e242ff1e51256373363= 21887a2f57e80 >> > >> > At the risk of asking a technical question ;-) >> > >> > The counter SHOULD be reset each time a DATA chunk sent to that peer >> > endpoint is acknowledged (by the reception of a SACK). When a >> > HEARTBEAT ACK is received from the peer endpoint, the counter SHOUL= D >> > also be reset. The receiver of the HEARTBEAT ACK MAY choose not to >> > clear the counter if there is outstanding data on the association. >> > This allows for handling the possible difference in reachability >> > based on DATA chunks and HEARTBEAT chunks. >> > >> > why is not clearing the counter if there is outstanding data on the >> association a good idea? (this was "shall", but is now "SHOULD") >> You are correct. It should be a MUST. >> Changed in: >> https://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e= 3539637f9dafe >> > >> > I have a similar (MUST vs. SHOULD) question about >> > >> > Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT >> > SHOULD clear the error counter of the destination transport address >> > to which the HEARTBEAT was sent, and mark the destination transport >> > address as active if it is not so marked. >> > >> > Why would not clearing the error counter be a good idea? >> You are right. The "should" should be changed to a "MUST", not a "SHOULD= . >> Done in: >> >> https://github.com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12= c5a67a1b6faeb >> > >> > Section 3.21 has multiple occurrences of something like >> > >> > o partial flag - if this returned flag is set to 1, then this >> > Receive contains a partial delivery of the whole message. When >> > ^ this "Receive" is capitalized >> > >> > this flag is set, the stream id and Stream Sequence Number MUST >> > accompany this receive. When this flag is set to 0, it indicate= s >> > ^ this "receive" is not capitalized >> > >> > that no more deliveries will be received for this Stream Sequenc= e >> > Number. >> > >> > Is that intentional? >> No. This is even not changed by this documents, but also inconsistent in >> RFC 4960. >> I also improved the consistency of the spelling: >> However, I improved the text: >> >> https://github.com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc= 6fae72eaf1751 >> >> >> >> --000000000000c7c5c3056cb9a8b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Gorry,

On Mon, May 21, 2018 at 10:22 AM Gorry (erg) <gorry@erg.abdn.ac.uk> wrote:
I will do
=

Just to confirm, I'll be happy to requ= est Last Call on -06 as submitted. Let me know when you think we're rea= dy for that.

Thanks!

Spen= cer
=C2=A0
=
Gorry=C2=A0

On 21 May 2018, at 14:55, Spencer Dawkin= s at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Gorry the Shepherd,

On Sun, May 20, 2018 at 11:53 AM Mich= ael Tuexen <t= uexen@fh-muenster.de> wrote:


> On 11. May 2018, at 22:12, Spencer Dawkins at IETF <spencerdawkins.ietf@gma= il.com> wrote:
>
> Dear Authors,
>
> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote= :
> Gorry Fairhurst has requested publication of draft-ietf-tsvwg-rfc4960-= errata-05 as Informational on behalf of the TSVWG working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errat= a/
>
> Thanks for doing this work (and even more so, for being willing to pro= vide an updated RFC to implementers, at some point in the future).
>
> I've completed AD evaluation for this draft, and have comments, bu= t almost all of them are requests for clarifications.
>
> I'd like to work through them with you before requesting Last Call= . Please let me know if you have questions.
Hi Spencer,

thanks for the review. I'll provide feedback inline.

Please note that I was also notified recently about a paragraph which shoul= d
have been removed when moving from RFC 2960 to RFC 4960, but the removal wa= s
missed and the text is still there. I have received this not via any mailin= g
list but via direct e-mail conversation. The fix is included as
https://github.= com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283ab5e82d4fc9c<= br>
You can see the current version in the git repository of the document in http:= //xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A%2F%2Fraw= .githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-r= fc4960-errata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&S= ubmit=3DSubmit

If you want additional changes, please let me know. If you are fine with th= e current
version in the git repo, I can submit it anytime...
Michael's responses (whether they resulted in changes or i= n explanations to the evaluating AD) work for me. Thanks to Michael for the= quick response.

Please invite Michael to submit a= new version, when you think that's the right thing to do.
I would appreciate it if you could add a few words reflecting = Michael's response on Why This Is Informational to the shepherd write-u= p, perhaps under (1) or (2)/Working Group Summary, where it will be copied = into the IESG ballot, so that we won't be explaining this 14 more times= during IESG evaluation ;-)

Spencer
=C2= =A0
Best regards
Michael
>
> Thanks!
>
> Spencer
>
> A high-order bit here ...
>
> I'm not sure why this draft isn't standards-track, and I wonde= r if there's a reason it doesn't UPDATE RFC 4960, unless that's= a side effect of being an Informational draft that would update a standard= s-track RFC.
>
> I'm thinking that this draft has achieved WG consensus, and if it&= #39;s published after Last Call, it would have IETF consensus, and it's= been reviewed by implementers. We've certainly published Proposed Stan= dards that didn't measure up to that level of document quality.
>
> I'm not objecting strongly to publishing as Informational, but I a= m saying that I expect other ADs to ask that question during IESG Evaluatio= n, and I'd like to understand the thinking before someone asks =E2=80= =A6
That is actually a good question and it would be a possible way forward.
When being in the process updating RFC 2960 to RFC 4960 we were in the same= situation. At that time we wrote
RFC 4460. We thought it is a good idea to not only publish RFC 4960 and let= people figure what changed and
why, but document this. That is why we have RFC 4460. We also thought that = it is a good idea to just have a
single specification for implementing the base protocol. If we would have m= ade RFC 4460 a PS updating RFC 2960,
and implementer would have to read two RFCs. That is why we decided that it= is simpler to publish RFC 4460 as
an informational RFC, and then publish RFC 4960 as a PS updating RFC 2960. = As you see from the numbers, working
on RFC 4460 took a while, but once that was there, publishing RFC 4960 was = straight forward. Just do the editorial
work described in RFC 4460 and some polishing of text we missed when workin= g in the diff way...

Since this plan worked well, the implementers of SCTP (which were also at t= hat time) are used to it, we though
it is a good way to handle the errata in RFC 4960.
>
> I note without suggesting a change that if the material in Section 3 w= as presented in this order
>
> 3.n.1=C2=A0 =C2=A0Description of the Problem
>
>
> 3.n.3.=C2=A0 Solution Description
>
> 3.n.2.=C2=A0 Text Changes to the Document
>
>=C2=A0 =C2=A0 ---------
>=C2=A0 =C2=A0 Old text:
>=C2=A0 =C2=A0 ---------
>
>=C2=A0 =C2=A0 ---------
>=C2=A0 =C2=A0 New text:
>=C2=A0 =C2=A0 ---------
>
> to allow readers to see the solution description before reading the de= tailed text changes, that would likely be easier to parse ...
That is definitely doable and I'm willing to do that change. However, t= his document right now uses the
same structure as RFC 4460 and I would prefer to keep the consistency.
>
> I'm reading this text from the Abstract
>
>=C2=A0 =C2=A0 Because some text is changed several times the last delta= in the
>=C2=A0 =C2=A0 text is the one which should be applied.=C2=A0 In additio= n to the delta a
>=C2=A0 =C2=A0 description of the problem and the details of the solutio= n are also
>=C2=A0 =C2=A0 provided.
>
> as saying that the deltas are cumulative, so you should apply the last= change to specific text, but this text from Section 1
>
>=C2=A0 =C2=A0Note that when reading this document one must use care to = assure that
>=C2=A0 =C2=A0 a field or item is not updated further on within the docu= ment.=C2=A0 Each
>=C2=A0 =C2=A0 section should be applied in sequence to the original [RF= C4960] since
>=C2=A0 =C2=A0 this document is a historical record of the sequential ch= anges that
>=C2=A0 =C2=A0 have been found necessary at various inter-op events and = through
>=C2=A0 =C2=A0 discussion on the list.
>
> seems to say that you should apply multiple deltas to the same text se= quentially. IIUC, the text actually does provide cumulative text deltas, so= using the phrasing from the Abstract in both places would be helpful to th= e reader.
OK. Changed to

=C2=A0 =C2=A0Note that when reading this document one must use care to assu= re that
=C2=A0 =C2=A0a field or item is not updated further on within the document.= =C2=A0 Since
=C2=A0 =C2=A0this document is a historical record of the sequential changes= that
=C2=A0 =C2=A0have been found necessary at various inter-op events and throu= gh
=C2=A0 =C2=A0discussion on the list, the last delta in the text is the one = which
=C2=A0 =C2=A0should be applied.

in https://gith= ub.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac382ef3f6b434

>
> This is a nit, but why is "Inconsistent" capitalized in this= text?
>
>=C2=A0 =C2=A0The handling of the 'Path.Max.Retrans' parameter i= s described in
>=C2=A0 =C2=A0 Section 8.2 and Section 8.3 of [RFC4960] in an Inconsiste= nt way.
Because I (or some autocorrection function of my editor) made a mistake. Fixed in:
https= ://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7ed1f90= 502a9
>
> https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ie= tf-tsvwg-rfc4960-errata-05.txt reports a few problems with references. = I THINK this is a side effect of updating (for example) [RFC2434] to be [RF= C5226], and then updating [RFC5226] to be [RFC8126]. If this was my draft, = I'd put a note to the RFC Editor that obsoleted RFCs are used in "= OLD TEXT" sections, and should have the obsoleting RFCs in the "N= EW TEXT" sections, so multiple reviewers won't ask you about the I= DNIT reporting multiple times.
After updating the document to reduce IDNITs warnings regarding too long li= nes in
https://github.= com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a32ecdd00626d5<= br> and cleaning up the references in
https://github.= com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc47766256606e<= br> I added the now true Note to the RFC Editor in
https://github.= com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732ec8a5208de57<= br> >
> I'm probably due for an eye exam, but I'm not seeing any diffe= rence between
>
>=C2=A0 =C2=A0---------
>=C2=A0 =C2=A0 Old text: (Section 1.6)
>=C2=A0 =C2=A0 ---------
>
>=C2=A0 =C2=A0 Transmission Sequence Numbers wrap around when they reach= 2**32 - 1.
>=C2=A0 =C2=A0 That is, the next TSN a DATA chunk MUST use after transmi= tting TSN =3D
>=C2=A0 =C2=A0 2*32 - 1 is TSN =3D 0.
>
> and
>
>=C2=A0 =C2=A0 ---------
>=C2=A0 =C2=A0 New text: (Section 1.6)
>=C2=A0 =C2=A0 ---------
>
>=C2=A0 =C2=A0 Transmission Sequence Numbers wrap around when they reach= 2**32 - 1.
>=C2=A0 =C2=A0 That is, the next TSN a DATA chunk MUST use after transmi= tting TSN =3D
>=C2=A0 =C2=A0 2**32 - 1 is TSN =3D 0.
>
> What am I missing?
The difference between "2*32" and "2**32" (the second o= ccurrence in the OLD and NEW text)...
Whether this should trigger an eye exam or not is left to the reader.
>
> In this text,
>
>=C2=A0 =C2=A0Move the sample code related to CRC32c computation and its=
>=C2=A0 =C2=A0 explanation from the end of Appendix C to the end of Appe= ndix B.
>
> I'm pretty sure I can figure out what text/code actually moves fro= m Appendix C to Appendix B, but I am figuring that out myself. Perhaps it w= ould be clearer if you said something like "all of Appendix C starting= with this sentence to the end of Appendix B".
>
>=C2=A0 =C2=A0 The following non-normative sample code is taken from an = open-source
>=C2=A0 =C2=A0 CRC generator [WILLIAMS93], using the "mirroring&quo= t; technique and
>=C2=A0 =C2=A0 yielding a lookup table for SCTP CRC32c with 256 entries,= each 32
>=C2=A0 =C2=A0 bits wide.
>
> (If I guessed wrong, that's likely because the fix says "code= and its explanation", which sounds like "everything following th= e beginning of the code", but the explanation comes before the code) You guessed perfectly right and I added the suggested text:
https://github.= com/sctplab/rfc4960bis/commit/62674932f28950cf249cdfb2c51534ede667111d<= br> >
> If I'm following closely, the errata described as
>
>=C2=A0 =C2=A0Section 7.2.2 of [RFC4960] is unclear about the order of a= djustments
>=C2=A0 =C2=A0 applied to partial_bytes_acked and cwnd in the congestion= avoidance
>=C2=A0 =C2=A0 phase.
>
> is actually clear about the order - assuming that you read left to rig= ht, it's just clearly wrong :-)
I see. But there is no explicit statement that you have to do it in that or= der.

What about:

Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance
phase.
which is committed in
https://github.= com/sctplab/rfc4960bis/commit/9fa55976e242ff1e5125637336321887a2f57e80<= br> >
> At the risk of asking a technical question ;-)
>
>=C2=A0 =C2=A0The counter SHOULD be reset each time a DATA chunk sent to= that peer
>=C2=A0 =C2=A0 endpoint is acknowledged (by the reception of a SACK). Wh= en a
>=C2=A0 =C2=A0 HEARTBEAT ACK is received from the peer endpoint, the cou= nter SHOULD
>=C2=A0 =C2=A0 also be reset. The receiver of the HEARTBEAT ACK MAY choo= se not to
>=C2=A0 =C2=A0 clear the counter if there is outstanding data on the ass= ociation.
>=C2=A0 =C2=A0 This allows for handling the possible difference in reach= ability
>=C2=A0 =C2=A0 based on DATA chunks and HEARTBEAT chunks.
>
> why is not clearing the counter if there is outstanding data on the as= sociation a good idea? (this was "shall", but is now "SHOULD= ")
You are correct. It should be a MUST.
Changed in: htt= ps://github.com/sctplab/rfc4960bis/commit/8ad403dd7e8102d1180b7d0363e353963= 7f9dafe
>
> I have a similar (MUST vs. SHOULD) question about
>
>=C2=A0 =C2=A0Upon the receipt of the HEARTBEAT ACK, the sender of the H= EARTBEAT
>=C2=A0 =C2=A0 SHOULD clear the error counter of the destination transpo= rt address
>=C2=A0 =C2=A0 to which the HEARTBEAT was sent, and mark the destination= transport
>=C2=A0 =C2=A0 address as active if it is not so marked.
>
> Why would not clearing the error counter be a good idea?
You are right. The "should" should be changed to a "MUST&quo= t;, not a "SHOULD. Done in:
https://github.= com/sctplab/rfc4960bis/commit/89446608b675e4d22cb4fe12a12c5a67a1b6faeb<= br> >
> Section 3.21 has multiple occurrences of something like
>
>=C2=A0 =C2=A0o=C2=A0 partial flag - if this returned flag is set to 1, = then this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Receive contains a partial delivery of the w= hole message.=C2=A0 When
>=C2=A0 =C2=A0 =C2=A0 =C2=A0^ this "Receive" is capitalized >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this flag is set, the stream id and Stream S= equence Number MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0accompany this receive.=C2=A0 When this flag= is set to 0, it indicates
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^ this "receive" is not capitalized
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that no more deliveries will be received for= this Stream Sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Number.
>
> Is that intentional?
No. This is even not changed by this documents, but also inconsistent in RF= C 4960.
I also improved the consistency of the spelling:
However, I improved the text:
https://github.= com/sctplab/rfc4960bis/commit/2e8adee110f3527bc3372c2f0dc6fae72eaf1751<= br>


--000000000000c7c5c3056cb9a8b1-- From nobody Mon May 21 10:00:05 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7799A12AF83; Mon, 21 May 2018 10:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 WwGvbLBb9Mem; Mon, 21 May 2018 09:59:58 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id CB183129C56; Mon, 21 May 2018 09:59:57 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 0FB361B0015C; Mon, 21 May 2018 17:59:20 +0100 (BST) Message-ID: <5B02FAE6.2040908@erg.abdn.ac.uk> Date: Mon, 21 May 2018 17:59:18 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Spencer Dawkins at IETF CC: Michael Tuexen , draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs , tsvwg@ietf.org References: <152403424429.31950.1069432147680033860.idtracker@ietfa.amsl.com> <28C5B00A-3721-4137-8BEF-E9A013F42856@fh-muenster.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-rfc4960-errata-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 17:00:04 -0000 Hi, Please go ahead with the process Spencer! I can now confirm I have read the update and made a small change to the wrietup to reflect the WG's process of publishing an errata prior to working on the PS update, Gorry On 21/05/2018, 17:18, Spencer Dawkins at IETF wrote: > Hi, Gorry, > > On Mon, May 21, 2018 at 10:22 AM Gorry (erg) wrote: > >> I will do >> > Just to confirm, I'll be happy to request Last Call on -06 as submitted. > Let me know when you think we're ready for that. > > Thanks! > > Spencer > > >> Gorry >> >> On 21 May 2018, at 14:55, Spencer Dawkins at IETF< >> spencerdawkins.ietf@gmail.com> wrote: >> >> Hi, Gorry the Shepherd, >> >> On Sun, May 20, 2018 at 11:53 AM Michael Tuexen >> wrote: >> >>> >>>> On 11. May 2018, at 22:12, Spencer Dawkins at IETF< >>> spencerdawkins.ietf@gmail.com> wrote: >>>> Dear Authors, >>>> >>>> On Wed, Apr 18, 2018 at 1:50 AM, Gorry Fairhurst >>> wrote: >>>> Gorry Fairhurst has requested publication of >>> draft-ietf-tsvwg-rfc4960-errata-05 as Informational on behalf of the TSVWG >>> working group. >>>> Please verify the document's state at >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ >>>> Thanks for doing this work (and even more so, for being willing to >>> provide an updated RFC to implementers, at some point in the future). >>>> I've completed AD evaluation for this draft, and have comments, but >>> almost all of them are requests for clarifications. >>>> I'd like to work through them with you before requesting Last Call. >>> Please let me know if you have questions. >>> Hi Spencer, >>> >>> thanks for the review. I'll provide feedback inline. >>> >>> Please note that I was also notified recently about a paragraph which >>> should >>> have been removed when moving from RFC 2960 to RFC 4960, but the removal >>> was >>> missed and the text is still there. I have received this not via any >>> mailing >>> list but via direct e-mail conversation. The fix is included as >>> >>> https://github.com/sctplab/rfc4960bis/commit/27c8609a1d57d990fc439ea5f283ab5e82d4fc9c >>> >>> You can see the current version in the git repository of the document in >>> >>> http://xml2rfc.ietf.org/cgi-bin/xml2rfc.cgi?input=&url=https%3A%2F%2Fraw.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-rfc4960-errata.xml&modeAsFormat=html%2Fascii&type=towindow&Submit=Submit >>> >>> If you want additional changes, please let me know. If you are fine with >>> the current >>> version in the git repo, I can submit it anytime... >>> >> Michael's responses (whether they resulted in changes or in explanations >> to the evaluating AD) work for me. Thanks to Michael for the quick response. >> >> Please invite Michael to submit a new version, when you think that's the >> right thing to do. >> >> I would appreciate it if you could add a few words reflecting Michael's >> response on Why This Is Informational to the shepherd write-up, perhaps >> under (1) or (2)/Working Group Summary, where it will be copied into the >> IESG ballot, so that we won't be explaining this 14 more times during IESG >> evaluation ;-) >> >> Spencer >> >> >>> Best regards >>> Michael >>>> Thanks! >>>> >>>> Spencer >>>> >>>> A high-order bit here ... >>>> >>>> I'm not sure why this draft isn't standards-track, and I wonder if >>> there's a reason it doesn't UPDATE RFC 4960, unless that's a side effect of >>> being an Informational draft that would update a standards-track RFC. >>>> I'm thinking that this draft has achieved WG consensus, and if it's >>> published after Last Call, it would have IETF consensus, and it's been >>> reviewed by implementers. We've certainly published Proposed Standards that >>> didn't measure up to that level of document quality. >>>> I'm not objecting strongly to publishing as Informational, but I am >>> saying that I expect other ADs to ask that question during IESG Evaluation, >>> and I'd like to understand the thinking before someone asks … >>> That is actually a good question and it would be a possible way forward. >>> >>> When being in the process updating RFC 2960 to RFC 4960 we were in the >>> same situation. At that time we wrote >>> RFC 4460. We thought it is a good idea to not only publish RFC 4960 and >>> let people figure what changed and >>> why, but document this. That is why we have RFC 4460. We also thought >>> that it is a good idea to just have a >>> single specification for implementing the base protocol. If we would have >>> made RFC 4460 a PS updating RFC 2960, >>> and implementer would have to read two RFCs. That is why we decided that >>> it is simpler to publish RFC 4460 as >>> an informational RFC, and then publish RFC 4960 as a PS updating RFC >>> 2960. As you see from the numbers, working >>> on RFC 4460 took a while, but once that was there, publishing RFC 4960 >>> was straight forward. Just do the editorial >>> work described in RFC 4460 and some polishing of text we missed when >>> working in the diff way... >>> >>> Since this plan worked well, the implementers of SCTP (which were also at >>> that time) are used to it, we though >>> it is a good way to handle the errata in RFC 4960. >>>> I note without suggesting a change that if the material in Section 3 >>> was presented in this order >>>> 3.n.1 Description of the Problem >>>> >>>> >>>> 3.n.3. Solution Description >>>> >>>> 3.n.2. Text Changes to the Document >>>> >>>> --------- >>>> Old text: >>>> --------- >>>> >>>> --------- >>>> New text: >>>> --------- >>>> >>>> to allow readers to see the solution description before reading the >>> detailed text changes, that would likely be easier to parse ... >>> That is definitely doable and I'm willing to do that change. However, >>> this document right now uses the >>> same structure as RFC 4460 and I would prefer to keep the consistency. >>>> I'm reading this text from the Abstract >>>> >>>> Because some text is changed several times the last delta in the >>>> text is the one which should be applied. In addition to the delta a >>>> description of the problem and the details of the solution are also >>>> provided. >>>> >>>> as saying that the deltas are cumulative, so you should apply the last >>> change to specific text, but this text from Section 1 >>>> Note that when reading this document one must use care to assure that >>>> a field or item is not updated further on within the document. Each >>>> section should be applied in sequence to the original [RFC4960] since >>>> this document is a historical record of the sequential changes that >>>> have been found necessary at various inter-op events and through >>>> discussion on the list. >>>> >>>> seems to say that you should apply multiple deltas to the same text >>> sequentially. IIUC, the text actually does provide cumulative text deltas, >>> so using the phrasing from the Abstract in both places would be helpful to >>> the reader. >>> OK. Changed to >>> >>> Note that when reading this document one must use care to assure that >>> a field or item is not updated further on within the document. Since >>> this document is a historical record of the sequential changes that >>> have been found necessary at various inter-op events and through >>> discussion on the list, the last delta in the text is the one which >>> should be applied. >>> >>> in >>> https://github.com/sctplab/rfc4960bis/commit/b713055804f0ff26da9bb07bf9ac382ef3f6b434 >>> >>>> This is a nit, but why is "Inconsistent" capitalized in this text? >>>> >>>> The handling of the 'Path.Max.Retrans' parameter is described in >>>> Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. >>> Because I (or some autocorrection function of my editor) made a mistake. >>> Fixed in: >>> https://github.com/sctplab/rfc4960bis/commit/12525d23e2ad49f84443e1a4d52a7ed1f90502a9 >>>> >>> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-tsvwg-rfc4960-errata-05.txt >>> reports a few problems with references. I THINK this is a side effect of >>> updating (for example) [RFC2434] to be [RFC5226], and then updating >>> [RFC5226] to be [RFC8126]. If this was my draft, I'd put a note to the RFC >>> Editor that obsoleted RFCs are used in "OLD TEXT" sections, and should have >>> the obsoleting RFCs in the "NEW TEXT" sections, so multiple reviewers won't >>> ask you about the IDNIT reporting multiple times. >>> After updating the document to reduce IDNITs warnings regarding too long >>> lines in >>> >>> https://github.com/sctplab/rfc4960bis/commit/8c2afb32018d7886c7540fb804a32ecdd00626d5 >>> and cleaning up the references in >>> >>> https://github.com/sctplab/rfc4960bis/commit/84700f46033b5f0a833a13398dfc47766256606e >>> I added the now true Note to the RFC Editor in >>> >>> https://github.com/sctplab/rfc4960bis/commit/a8e60e5b230ad24cd79bb807e732ec8a5208de57 >>>> I'm probably due for an eye exam, but I'm not seeing any difference >>> between >>>> --------- >>>> Old text: (Section 1.6) >>>> --------- >>>> >>>> Transmission Sequence Numbers wrap around when they reach 2**32 - 1 From nobody Mon May 21 10:32:23 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE0612D7E2; Mon, 21 May 2018 10:32:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs@ietf.org, Gorry Fairhurst , spencerdawkins.ietf@gmail.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152692394111.23632.5771148379542425606.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2018 10:32:21 -0700 Archived-At: Subject: [tsvwg] Last Call: (RFC 4960 Errata and Issues) to Informational RFC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 17:32:21 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'RFC 4960 Errata and Issues' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-06-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document is a compilation of issues found since the publication of RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time ordered way. The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one which should be applied. In addition to the delta a description of the problem and the details of the solution are also provided. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 22 01:31:10 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84F512EACD for ; Tue, 22 May 2018 01:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 p8h2OCLsUkuU for ; Tue, 22 May 2018 01:30:51 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 863A712E76A for ; Tue, 22 May 2018 01:30:51 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 31AC81B001AA; Tue, 22 May 2018 09:30:17 +0100 (BST) Message-ID: <5B03D519.9050709@erg.abdn.ac.uk> Date: Tue, 22 May 2018 09:30:17 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org, Joe Touch References: <152334654802.13452.17469061242049682843.idtracker@ietfa.amsl.com> <5ACC6E04.8070107@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 08:31:08 -0000 Thanks Joe for your comments. See our editorial notes below, but please have a look at our revised ID. New text introduced, this was a mistake in revising the abstract, we think it is in scope to discuss the benefits/drawbacks of integrity protection also: the title and abstract focus on transport header confidentiality; this begs the need for sections 3.1, 3.2, and parts of 3.4 which have nothing to do with *transport header* confidentiality -- the doc reports in other ways to address transport encryption in general; that’s a much larger issue to include, with entirely different implications Para rephrased. We do agree with this statement and have stated this publically when presenting this draft -- the doc speaks of ossification as if it is only harmful; that same ossification provides the stability on which other upper layer protocols often rely, so having a “stable” (ossified) protocol could be considered an advantage too (beyond merely allowing in-network devices to predict their location) I agree with your disagreement -- I disagree that encryption of transport headers would prevent ossification; they could similarly be ossified by being the only ones supported using encryption at the endpoints This is true, I'd love to find text we can all agree upon that says how we should do things in the future: but I am also aware of a wide range of intense feelings and operational practice in our community ... from those who have reacted to privacy concerns, some countries push for net neutrality, others on a digital divide with concerns over cost; etc etc. I think an important outcome of the document is to capture what is being done, wording has been updated -- the doc focuses on the impact of transport header encryption on a number of “features” that have emerged, but fails to address whether those “features” are desirable (i.e., just because we CAN do certain things, and HAVE DONE certain things, is independent of whether we should continue to design protocols to support those things) It states: "Using encryption to provide confidentiality of the transport layer brings some well-known privacy and security benefits and can therefore help reduce ossification of the transport layer.", we also added text -- the intro fails to address the valid privacy motivations for obscuring transport information, esp. given transport protocols are themselves meaningful ONLY at the endpoints e.g., I could easily modify two hosts to exchange packets that look like UDP but are actually TCP this is akin to port renumbering at the endpoints fundamentally, in the Internet, transport headers have meaning ONLY at the two endpoints engaging in a given communication, so we really are “living on borrowed time” to assume that in-network devices can - or should - be able to interpret them at all, even when they appear not to be encrypted. I do NOT agree of nearly anything in section 2.1, especially as it is then used to justify the remainder of section 2 this entire section reads a lot like “the government needs to track your every move so we can build better roads for you”; it’s quite creepy. Text was updated-- section 3 omits discussions of encrypted tunnels (IPsec or otherwise), all of which obscure access to transport headers As far as I know TCP-AO-ENC is still an individual submission, I don't know of operational use. -- sec 3.2 (if retained, and I hope it is not), should include tcp-ao-enc (yes, still a draft, but relevant to the discussion if retained) Added reference to TCPcrypt: draft-ietf-tcpinc-tcpcryp -- sec 3 omits TCPcrypt too (not sure where to put it because I haven’t cared to track how it has (d)evolved). Changed the wording introducing transport to "The transport layer provides end-to-end interactions between endpoints (processes) using an Internet path." -- not sure I agree that the transport layer is the first end-to-end interaction across the Internet; the same is true for the IP layer (esp, e.g., IPv6 Destination Options, among other things). This was not an intention -- finally, this doc seems oblivious to the reality that encryption is coming, like it or not - esp across the backbone, and that this has been the case for a while now (with VPNs). Best wishes, Colin and Gorry On 11/05/2018, 05:20, Joe Touch wrote: > Hi, Gorry, et al., > > I disagree with the tone and focus of this document. > > It appears to give many reasons why hiding transport info from on-path observers is bad - bad for the network, bad for operators, and bad for everyone. > > It reads like an Orwellian propaganda brochure on how Big Brother is only here to help - won’t you leave the cameras on? > > The doc fails to recognize: > - the fact that encryption (via tunneling, esp) is already undermining a lot of this sort of “help” > - the fact that users can - and should - find a lot of what passes for “help” quite a bit creepy > - the fact that transport protocols were never intended to have any meaning anywhere but the endpoints > and that, in fact, that’s the only place where they do have meaning anyway > > If this doc goes forward, I sincerely hope there will be a more balanced presentation of the CONS of the kind of on-path snooping of traffic that this document largely presents as beneficial. > > Joe > > ——— > > Some details follow: > > - the title and abstract focus on transport header confidentiality; this begs the need for sections 3.1, 3.2, and parts of 3.4 - which have nothing to do with *transport header* confidentiality > - the doc reports in other ways to address transport encryption in general; that’s a much larger issue to include, with entirely different implications > > - the doc speaks of ossification as if it is only harmful; that same ossification provides the stability on which other upper layer protocols often rely, so having a “stable” (ossified) protocol could be considered an advantage too (beyond merely allowing in-network devices to predict their location) > - I disagree that encryption of transport headers would prevent ossification; they could similarly be ossified by being the only ones supported using encryption at the endpoints > > - the doc focuses on the impact of transport header encryption on a number of “features” that have emerged, but fails to address whether those “features” are desirable (i.e., just because we CAN do certain things, and HAVE DONE certain things, is independent of whether we should continue to design protocols to support those things) > > - the intro fails to address the valid privacy motivations for obscuring transport information, esp. given transport protocols are themselves meaningful ONLY at the endpoints > e.g., I could easily modify two hosts to exchange packets that look like UDP but are actually TCP > this is akin to port renumbering at the endpoints > fundamentally, in the Internet, transport headers have meaning ONLY at the two endpoints engaging in a given communication, so we really are “living on borrowed time” to assume that in-network devices can - or should - be able to interpret them at all, even when they appear not to be encrypted > > - I do NOT agree of nearly anything in section 2.1, especially as it is then used to justify the remainder of section 2 > this entire section reads a lot like “the government needs to track your every move so we can build better roads for you”; it’s quite creepy. > > - section 3 omits discussions of encrypted tunnels (IPsec or otherwise), all of which obscure access to transport headers > > - sec 3.2 (if retained, and I hope it is not), should include tcp-ao-enc (yes, still a draft, but relevant to the discussion if retained) > > - sec 3 omits TCPcrypt too (not sure where to put it because I haven’t cared to track how it has (d)evolved). > > - not sure I agree that the transport layer is the first end-to-end interaction across the Internet; the same is true for the IP layer (esp, e.g., IPv6 Destination Options, among other things). > > - finally, this doc seems oblivious to the reality that encryption is coming, like it or not - esp across the backbone, and that this has been the case for a while now (with VPNs) > > ---- > > From nobody Wed May 23 11:41:41 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C33612E957; Wed, 23 May 2018 11:41:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg To: Cc: draft-ietf-tsvwg-iana-dscp-registry.all@ietf.org, ietf@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152710087741.26946.16536512145385148907@ietfa.amsl.com> Date: Wed, 23 May 2018 11:41:17 -0700 Archived-At: Subject: [tsvwg] Genart last call review of draft-ietf-tsvwg-iana-dscp-registry-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 18:41:27 -0000 Reviewer: Christer Holmberg Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tsvwg-iana-dscp-registry-05 Reviewer: Christer Holmberg Review Date: 2018-05-23 IETF LC End Date: 2018-05-25 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and almost ready for publication. I have one minor editorial comment that I'd like the authors to address. Major issues: None Minor issues: None Nits/editorial comments: The Abstract says: "This update to RFC2474 changes the IANA assignment method..." ...and the Introduction says: "To allow the IETF to utilise Pool 3 codepoints, this document requests IANA to to manage Pool 3 assignments for DSCP values in Pool 3 via the Standards Action policy [RFC8126]. This assignment method requires publication of a Standards Track or Best Current Practice RFC." I suggest to replace "method" with "policy". From nobody Thu May 24 04:33:12 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02A12D942; Thu, 24 May 2018 04:33:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152716159035.29984.11565444206655227065@ietfa.amsl.com> Date: Thu, 24 May 2018 04:33:10 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 11:33:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME Authors : Vincent Roca Belkacem Teibi Filename : draft-ietf-tsvwg-rlc-fec-scheme-05.txt Pages : 34 Date : 2018-05-24 Abstract: This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over GF(2) (binary case), a second one for RLC over GF(2^^8), both of them with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real-time flows in terms of reduced FEC- related latency while often providing improved packet erasure recovery capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 24 05:02:07 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF712E876 for ; Thu, 24 May 2018 05:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4ci7pdphMyE7 for ; Thu, 24 May 2018 05:01:57 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 473C112DA16 for ; Thu, 24 May 2018 05:01:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,436,1520895600"; d="scan'208,217";a="266274782" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2018 14:01:54 +0200 From: Vincent Roca Message-Id: <122FCFAB-12CD-4CD1-8775-C707ECA96E2A@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_AB39FCFB-EB43-43D5-8265-3BAB53AFD8ED" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 24 May 2018 14:01:54 +0200 In-Reply-To: <152716159035.29984.11565444206655227065@ietfa.amsl.com> Cc: Vincent Roca , Belkacem Teibi To: tsvwg@ietf.org, nwcrg@irtf.org References: <152716159035.29984.11565444206655227065@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 12:02:06 -0000 --Apple-Mail=_AB39FCFB-EB43-43D5-8265-3BAB53AFD8ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, We have just posted a new version of our RLC FEC Schemes I-D, motivated = by the use of a new PRNG. As already mentioned, the Park Miller Linear Congruential Generator has = several flaws. This was not an issue in RFC5170 because of the way it was used (many = random values obtained from the same seed). With the current document, we use it = differently (many seeds that will often be chosen in sequence) and these limits became = obvious. After a few hesitations, we moved to a brand new PRNG: the Tiny Mersenne = Twister,=20 32-bit version. This is a compact version of a renown PRNG: the Mersenne = Twister, now=20 widely used (see https://en.wikipedia.org/wiki/Mersenne_Twister = ) and with provable = quality (it passes several key tests of the domain). We have the feeling the = Tiny version is also=20 quite popular, although more recent. The compact version (TinyMT32) has been designed by the same authors and = comes with a reference C-language software, using a BSD license. = http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT/index.html = https://github.com/MersenneTwister-Lab/TinyMT = In fact this PRNG is defined by this implementation, version 1.1 = (2015/4/24). Therefore: - we switched to this PRNG in the I-D as well as in our reference RLC = codec; - using seed 0 is now authorised and the I-D has been updated = accordingly (no need to keep an unnecessary restriction); - we added Annex A that reproduces a sub-set of the TinyMT32 reference = software (see the I-D for differences with the original, mostly of editorial = nature); In terms of speed, there is no significant difference between Park = Miller LCG and TinyMT32 (it may even be slightly faster). In terms of PRNG quality, we get rid = of our issues :-) I=E2=80=99m now going to contact TinyMT32 authors to let them know of = this initiative. The remaining of the I-D remains mostly unchanged WRT version -04. Cheers, Vincent and Belkacem > Le 24 mai 2018 =C3=A0 13:33, internet-drafts@ietf.org a =C3=A9crit : >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Area Working Group WG of = the IETF. >=20 > Title : Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Schemes for FECFRAME > Authors : Vincent Roca > Belkacem Teibi > Filename : draft-ietf-tsvwg-rlc-fec-scheme-05.txt > Pages : 34 > Date : 2018-05-24 >=20 > Abstract: > This document describes two fully-specified Forward Erasure > Correction (FEC) Schemes for Sliding Window Random Linear Codes > (RLC), one for RLC over GF(2) (binary case), a second one for RLC > over GF(2^^8), both of them with the possibility of controlling the > code density. They can protect arbitrary media streams along the > lines defined by FECFRAME extended to sliding window FEC codes. > These sliding window FEC codes rely on an encoding window that = slides > over the source symbols, generating new repair symbols whenever > needed. Compared to block FEC codes, these sliding window FEC codes > offer key advantages with real-time flows in terms of reduced FEC- > related latency while often providing improved packet erasure > recovery capabilities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rlc-fec-scheme-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --Apple-Mail=_AB39FCFB-EB43-43D5-8265-3BAB53AFD8ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all,

We have just = posted a new version of our RLC FEC Schemes I-D, motivated by the = use
of a new PRNG.

As already mentioned, the Park Miller = Linear Congruential Generator has several flaws.
This= was not an issue in RFC5170 because of the way it was used (many random = values
obtained from the same seed). With the = current document, we use it differently (many
seeds = that will often be chosen in sequence) and these limits became = obvious.

After = a few hesitations, we moved to a brand new PRNG: the Tiny Mersenne Twister, 
32-bit version. This is a compact = version of a renown PRNG: the Mersenne Twister, now 
widely used (see https://en.wikipedia.org/wiki/Mersenne_Twister) and with = provable quality
(it passes several key tests of = the domain). We have the feeling the Tiny version is = also 
quite popular, although more = recent.

The = compact version (TinyMT32) has been designed by the same authors and = comes with
a reference C-language software, using a = BSD license.
In fact this PRNG is defined by this implementation, version = 1.1 (2015/4/24).

Therefore:
- we switched to this PRNG in = the I-D as well as in our reference RLC codec;
- = using seed 0 is now authorised and the I-D has been updated accordingly = (no need to
  keep an unnecessary = restriction);
- we added Annex A that reproduces a = sub-set of the TinyMT32 reference software (see
  the I-D for differences with the original, mostly of = editorial nature);

In terms of speed, there is no significant difference between = Park Miller LCG and TinyMT32
(it may even be = slightly faster). In terms of PRNG quality, we get rid of our issues = :-)
I=E2=80=99m now going to contact TinyMT32 = authors to let them know of this initiative.

The remaining of the I-D remains mostly = unchanged WRT version -04.

Cheers,

  Vincent and Belkacem


Le 24 mai 2018 =C3=A0 13:33, internet-drafts@ietf.org a =C3=A9crit :


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Transport Area Working Group WG of the IETF.

       Title =           : Sliding = Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes = for FECFRAME
=        Authors =         : Vincent Roca
=             &n= bsp;           &nbs= p;Belkacem Teibi
Filename =        : = draft-ietf-tsvwg-rlc-fec-scheme-05.txt
Pages =           : 34
= Date =            : = 2018-05-24

Abstract:
=   This document describes two fully-specified Forward = Erasure
  Correction (FEC) Schemes for Sliding = Window Random Linear Codes
  (RLC), one for RLC = over GF(2) (binary case), a second one for RLC
=   over GF(2^^8), both of them with the possibility of = controlling the
  code density.  They can = protect arbitrary media streams along the
=   lines defined by FECFRAME extended to sliding window FEC = codes.
  These sliding window FEC codes rely on = an encoding window that slides
  over the = source symbols, generating new repair symbols whenever
=   needed.  Compared to block FEC codes, these sliding = window FEC codes
  offer key advantages with = real-time flows in terms of reduced FEC-
=   related latency while often providing improved packet = erasure
  recovery capabilities.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-schem= e/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-05<= br = class=3D"">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-= scheme-05

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rlc-fec-sc= heme-05


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


= --Apple-Mail=_AB39FCFB-EB43-43D5-8265-3BAB53AFD8ED-- From nobody Thu May 24 05:44:51 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55B12E858; Thu, 24 May 2018 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk4ax_OlixoM; Thu, 24 May 2018 05:44:47 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382D712E865; Thu, 24 May 2018 05:44:44 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id i13-v6so530294ybl.4; Thu, 24 May 2018 05:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F5BvsS8gYAUBQHC2Lfmc9/LiqqN+6EBr7FBt/q4eNuc=; b=rXf49IBPn2251XhLKYWOZeP0cYHwNcNnPp0/se1yb4zzcVJC3WOi5B6shw6k29k351 +A+8aZm05mTaVF1r0wicevlq3/JnzgAhlsBI0Ar5UPGZpv8UDqepjWplttkb7EBQty3o C480EPo9WDfJNBZMwTYFyH0OR3y6Xn5geVfkId2kXxUphWc/YsD4/53g8m+lbL36Tezx pXizv24hvwfcHUZmhyZpNO6aLUyGJBvpGAqGQEPGfegJaV1rALv5jQLHWRtvuImmoCUM 9h8SZM/VTeZSjOQl5nA6DldffoJeMQvB52HOpP5hP8zy3960F6CaAig10OBcT4gIqhGa O29A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F5BvsS8gYAUBQHC2Lfmc9/LiqqN+6EBr7FBt/q4eNuc=; b=r23Mo3dnrfHfMznvkF4Z26KXMkCNa8VW/9Nw9bneze8u4sO31c8UKeczhKViG2thHq JZ8eBVKqhNQz0qGAN0km51UPaCzYzILQSdWxBBowca11/FLr0cf+Md49oxbF+mgSonZA QRr7qo8qVUtNmiJS3Q6BsgzK/BD3vMXQP2OALeTHRd6XEPpJ6vbM9GmTm24wG7cJ0Zt1 bdHZtuvS3LHz6BpPBRZ2ZJfPJXV+eZPq8qKvja82MCFIRz3EyLGw6/ZiqBlBxC1+zhsx Qouw2tReldiVnKa4viwhDnR1IuvYE8kf+9Ft5fr+figbrDRwKQihQr8cEMs7ho5pTZFl ssDw== X-Gm-Message-State: ALKqPwdCbtQvRjsRB7ArHPbKGzo4vplW1zKH/DxhRjzdKG7yis6cl6qN OyCGYdhLbCc85kQY9B5WrPHIeq6lC4zQpbSXB9U= X-Google-Smtp-Source: AB8JxZrwKCwQTD/C38V+MNKEcPW91orvPU/CtHijQMzyjajvZ/TKqG17GE13ol1fOqYoblHCIeXG8T14dWx9IjC2Hu0= X-Received: by 2002:a25:6a55:: with SMTP id f82-v6mr3947586ybc.235.1527165883299; Thu, 24 May 2018 05:44:43 -0700 (PDT) MIME-Version: 1.0 References: <152710087741.26946.16536512145385148907@ietfa.amsl.com> In-Reply-To: <152710087741.26946.16536512145385148907@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 24 May 2018 07:44:29 -0500 Message-ID: To: Christer Holmberg Cc: gen-art , draft-ietf-tsvwg-iana-dscp-registry.all@ietf.org, IETF list , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000fcbcfb056cf303e8" Archived-At: Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-iana-dscp-registry-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 12:44:50 -0000 --000000000000fcbcfb056cf303e8 Content-Type: text/plain; charset="UTF-8" Hi, Christer, On Wed, May 23, 2018 at 1:41 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Reviewer: Christer Holmberg > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-tsvwg-iana-dscp-registry-05 > Reviewer: Christer Holmberg > Review Date: 2018-05-23 > IETF LC End Date: 2018-05-25 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is well written, and almost ready for publication. I > have > one minor editorial comment that I'd like the authors to address. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > The Abstract says: > > "This update to RFC2474 changes the IANA assignment method..." > > ...and the Introduction says: > > "To allow the IETF to utilise Pool 3 codepoints, this document > requests IANA to to manage Pool 3 assignments for DSCP values in Pool > 3 via the Standards Action policy [RFC8126]. This assignment method > requires publication of a Standards Track or Best Current Practice > RFC." > > I suggest to replace "method" with "policy". > I think that's right. https://tools.ietf.org/html/rfc8126#section-4 does call these "assignment policies". Gorry, if you agree, could you make that change? Thanks, Spencer --000000000000fcbcfb056cf303e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Christer,

On Wed, May 23, 2018 at 1:41 PM Christer Holmberg <christer.holmberg@ericsson.com>= ; wrote:
Reviewe= r: Christer Holmberg
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-tsvwg-iana-dscp-registry-05
Reviewer: Christer Holmberg
Review Date: 2018-05-23
IETF LC End Date: 2018-05-25
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well written, and almost ready for publication. I = have
one minor editorial comment that I'd like the authors to address.

Major issues: None

Minor issues: None

Nits/editorial comments:

The Abstract says:

"This update to RFC2474 changes the IANA assignment method..."
...and the Introduction says:

=C2=A0"To allow the IETF to utilise Pool 3 codepoints, this document =C2=A0 =C2=A0requests IANA to to manage Pool 3 assignments for DSCP values = in Pool
=C2=A0 =C2=A03 via the Standards Action policy [RFC8126].=C2=A0 This assign= ment method
=C2=A0 =C2=A0requires publication of a Standards Track or Best Current Prac= tice
=C2=A0 =C2=A0RFC."

I suggest to replace "method" with "policy".

I think that's right.=C2=A0https://tools.ietf.org/html/rfc8126= #section-4 does call these "assignment policies".
<= br>
Gorry, if you agree, could you make that change?=C2=A0
<= div>
Thanks,

Spencer
--000000000000fcbcfb056cf303e8-- From nobody Thu May 24 06:11:00 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB76D12E876; Thu, 24 May 2018 06:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QIHY8xQLox4y; Thu, 24 May 2018 06:10:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02D12DA4A; Thu, 24 May 2018 06:10:41 -0700 (PDT) Received: from [137.50.183.77] (oa-edu-183-77.wireless.abdn.ac.uk [137.50.183.77]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8DA9E1B001E2; Thu, 24 May 2018 14:10:40 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-7BEAC292-FBBF-4DD3-BD85-E617CFF1B66E Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Thu, 24 May 2018 14:10:40 +0100 Cc: Christer Holmberg , gen-art , draft-ietf-tsvwg-iana-dscp-registry.all@ietf.org, IETF list , tsvwg@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <152710087741.26946.16536512145385148907@ietfa.amsl.com> To: Spencer Dawkins at IETF Archived-At: Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-iana-dscp-registry-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 13:10:44 -0000 --Apple-Mail-7BEAC292-FBBF-4DD3-BD85-E617CFF1B66E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Happy to make this change - thanks for noting this. Gorry=20 > On 24 May 2018, at 13:44, Spencer Dawkins at IETF wrote: >=20 > Hi, Christer, >=20 >> On Wed, May 23, 2018 at 1:41 PM Christer Holmberg wrote: >> Reviewer: Christer Holmberg >> Review result: Almost Ready >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-tsvwg-iana-dscp-registry-05 >> Reviewer: Christer Holmberg >> Review Date: 2018-05-23 >> IETF LC End Date: 2018-05-25 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: The document is well written, and almost ready for publication. I= have >> one minor editorial comment that I'd like the authors to address. >>=20 >> Major issues: None >>=20 >> Minor issues: None >>=20 >> Nits/editorial comments: >>=20 >> The Abstract says: >>=20 >> "This update to RFC2474 changes the IANA assignment method..." >>=20 >> ...and the Introduction says: >>=20 >> "To allow the IETF to utilise Pool 3 codepoints, this document >> requests IANA to to manage Pool 3 assignments for DSCP values in Pool >> 3 via the Standards Action policy [RFC8126]. This assignment method >> requires publication of a Standards Track or Best Current Practice >> RFC." >>=20 >> I suggest to replace "method" with "policy". >=20 > I think that's right. https://tools.ietf.org/html/rfc8126#section-4 does c= all these "assignment policies". >=20 > Gorry, if you agree, could you make that change?=20 >=20 > Thanks, >=20 > Spencer --Apple-Mail-7BEAC292-FBBF-4DD3-BD85-E617CFF1B66E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Happy to make this change - thanks for noting this.

Gorry 

On 24 May 2018, at 13:44, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Christer,

On Wed, May 23, 2018 at 1:41 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Reviewer: Christer Holmberg
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-tsvwg-iana-dscp-registry-05
Reviewer: Christer Holmberg
Review Date: 2018-05-23
IETF LC End Date: 2018-05-25
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well written, and almost ready for publication. I have
one minor editorial comment that I'd like the authors to address.

Major issues: None

Minor issues: None

Nits/editorial comments:

The Abstract says:

"This update to RFC2474 changes the IANA assignment method..."

...and the Introduction says:

 "To allow the IETF to utilise Pool 3 codepoints, this document
   requests IANA to to manage Pool 3 assignments for DSCP values in Pool
   3 via the Standards Action policy [RFC8126].  This assignment method
   requires publication of a Standards Track or Best Current Practice
   RFC."

I suggest to replace "method" with "policy".

I think that's right. https://tools.ietf.org/html/rfc8126#section-4 does call these "assignment policies".

Gorry, if you agree, could you make that change? 

Thanks,

Spencer
--Apple-Mail-7BEAC292-FBBF-4DD3-BD85-E617CFF1B66E-- From nobody Thu May 24 11:09:42 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108012EADE for ; Thu, 24 May 2018 11:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 bYBRc_xl8kAo for ; Thu, 24 May 2018 11:09:39 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AD312EAD6 for ; Thu, 24 May 2018 11:09:39 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B8980E7800 for ; Thu, 24 May 2018 14:09:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=oq2 rmzLAdFN+67toRG2zHOnMvYc=; b=kY9gCD5o+uIBb0l53GKAo4t/jjCaUjsqKfA qajbyto9iGd28+GXjYFqBrodsOJaGQcR3ZuQCyqgRUOMGhZPK95H7/D8mkERm7QP b9Hn3271vv204mQmPNeXs/gNftu8VpXRtI5O/YWEGxhqFXRsZbK3oulxjP8jeogv DaoBdf1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= iqtfU6Qrd6bXVV+KMN2IEB/4N2sw/N4omh+6yDNS2VG7lGw6JT/q6uWt2UGGCxbH sM6HFhl4J3u7ADYcKAaVFiMR1HIRCQxFIb4F5s6CU9iuCGjQlcgBs5pUvBsFLeZU aonGHkZYNRBCNGxRlIhw0xMiLnnwk5Tz0mLb/DMuQ04= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B0568E77FE for ; Thu, 24 May 2018 14:09:36 -0400 (EDT) Received: from mail-oi0-f41.google.com (unknown [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 414B0E77FB for ; Thu, 24 May 2018 14:09:36 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id l1-v6so2302745oii.1 for ; Thu, 24 May 2018 11:09:36 -0700 (PDT) X-Gm-Message-State: ALKqPwcX3+9zsGNywankcfTRBvoCCnZDVec9n2Myb+iHPGFtXr4XLo+S BBLkx+xuDf1kPC31OCNYryxruwF5LoSayaDR0nY= X-Google-Smtp-Source: AB8JxZoHSayz4QH9tg2m7AQVrAX8vIe1Wk/fxikhE4gK/YsNbNiOrbclwQPawcqvPUmYwE2OLPzu22oFxkyLvhax7eE= X-Received: by 2002:aca:917:: with SMTP id 23-v6mr4630277oij.119.1527185375638; Thu, 24 May 2018 11:09:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:88c6:0:0:0:0:0 with HTTP; Thu, 24 May 2018 11:09:15 -0700 (PDT) From: "C. M. Heard" Date: Thu, 24 May 2018 11:09:15 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Tom Jones Cc: Joe Touch , tsvwg Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 9E1985E2-5F7D-11E8-8776-44CE1968708C-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 18:09:41 -0000 On Fri, May 11, 2018 at 3:07 AM, Tom Jones wrote: > On Sun, May 06, 2018 at 10:23:54AM -0700, C. M. Heard wrote: >> Section 5.5, LITE option: the following instruction >> >> 3. Swap all four bytes of the LITE option with the first 4 bytes of >> the LITE data area (Figure 11). >> >> >> works only if the LITE data area is at least four bytes long. However, the >> option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one >> simply moves the option to the start of the LITE data area and moves the >> displaced LITE bytes just past the end of the relocated LITE option. This >> operation is then reversed on the receive side. In effect, one is swapping >> the locations of the LITE option and the initial segment of the LITE data >> area of length min(4, LITE offset). > > A UDP Lite region greater than 0 must be a minimum of 8 octets. > > A Checksum Coverage of zero indicates that the entire UDP-Lite > packet is covered by the checksum. This means that the value of > the Checksum Coverage field MUST be either 0 or at least 8. > > So only the 0 coverage case must be considered by this document. This is a misreading of RFC 3828. In UDP-Lite, if the value of the Checksum Coverage field is non-zero, then the number of UDP payload bytes covered by the checksum is 8 less than that value. So UDP-Lite allows for any number of payload bytes from 0 to (MAXIMUM_UDP_DATAGRAM_SIZE - 8) to be covered by the UDP checksum. The same range is allowed for the number of payload bytes that are **not** covered by the UDP checksum. The objective for udp-options should IMHO be to provide the exact same flexibility (modulo reduction of the upper bound by the length of the UDP options trailer). In UDP (protocol 17), even when augmented by UDP options, the minimum value of UDP Length is 8, full stop; a value from 0 through 7 is simply an error (see page 6 of the draft). The special meaning of the value 0 defined in RFC 3828 does not apply. But other than that, the meaning of UDP Length field in the udp-options draft and the Checksum Coverage field in RFC 3828 are (essentially) the same. So we do need to deal with LIE data lengths from 0 through 3. Mike Heard From nobody Thu May 24 11:33:43 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A212D80E for ; Thu, 24 May 2018 11:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 moafd26S72_C for ; Thu, 24 May 2018 11:33:39 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 AC1EA127444 for ; Thu, 24 May 2018 11:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2oi9TvI8B/pE8MgaG7hes1aX9pLaFhli18xJnyVv04o=; b=0lTZ0GGrcl1GRrig7MOmqbAyu RD9s4EeX2139YC1VoDFF9idIBUmGhxwu82myMV6pTXWaiCwn8b8epKjokDCKfyKLph4O9aB9Wxu0b MJacAMjwV/s56Yf1L77iIHhxgxE7tlBFiqldkZWvuyxild1tgvr9P12mFwk6f29Lft+U0H525gKoL QWM8KRdJ9w/JOkqnAPBK46e4ILzceoOB8RqlQ5Um379WtBWIZgPNztwniuWlkT1dMYpj/EVfk/vzL qV+IbHkzb7Wa+cL1/1Z7CWbv+1sdFVH+D9wbJ7oTVa8QyIK2YTyDB/X+iZ07DDuNhhFy4N9ygLp7g WQB0cuStg==; Received: from [::1] (port=36900 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLv3O-003LIh-Vo; Thu, 24 May 2018 14:33:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_65c9c1440433a2339579155f2e66f843" Date: Thu, 24 May 2018 11:33:34 -0700 From: Joe Touch To: "C. M. Heard" Cc: Tom Jones , tsvwg In-Reply-To: References: Message-ID: <143e3d8b4d675e2830a561e5a95fef37@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 18:33:42 -0000 --=_65c9c1440433a2339579155f2e66f843 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-24 11:09, C. M. Heard wrote: > ... > So we do need to deal with LIE data lengths from 0 through 3. Agreed, but I don't think it needs to change what's in the existing doc all that much. For 4 or more, do what's in the doc. For 0-3, then "slide" the LITE option before the LITE data, e.g.: the lite header = [L I T E] lite data = caps, e.g., U V W X Y Z or a subset thereof other options = a b c d e ... before transmitting: lite data len: lite area and options: ------------------------------------------ 0 bytes [L I T E] a b c d e ... 1 byte U [L I T E] a b c d e ... 2 bytes U V [L I T E] a b c d e ... 3 bytes U V W [L I T E] a b c d e ... 4 bytes U V W X [L I T E] a b c d e ... 5 bytes U V W X Y [L I T E] a b c d e ... 6 bytes U V W X Y Z [L I T E] a b c d e ... after transmitting 0 bytes [L I T E] a b c d e ... 1 byte [L I T E] U a b c d e ... 2 bytes [L I T E] U V a b c d e ... 3 bytes [L I T E] U V W a b c d e ... 4 bytes [L I T E] U V W X a b c d e ... 5 bytes [L I T E] Y U V W X a b c d e ... ^ 6 bytes [L I T E] Y Z U V W X a b c d e ... ^ ^ The issue is highlighted with the carets (^). For 3 bytes or less, "SLIDE" For 4 bytes, SLIDE is the same as SWAP For more than 4 bytes, SWAP is more efficient than SLIDE (avoids a long copy of the data) I don't think it's bad to have a special case for 3 or fewer bytes. Joe --=_65c9c1440433a2339579155f2e66f843 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-05-24 11:09, C. M. Heard wrote:

= =2E..
So we do need to deal with LIE data lengths from 0 through 3.
=  
= Agreed, but I don't think it needs to change what's in the existing doc all= that much.
=  
= For 4 or more, do what's in the doc.
=  
= For 0-3, then "slide" the LITE option before the LITE data, e.g.:
=  
= the lite header =3D [L I T E]
= lite data =3D caps, e.g., U V W X Y Z or a subset thereof
= other options =3D a b c d e ...
=  
= before transmitting:
=         lite data len:    lite area and optio= ns:
=        ------------------------------------------
=               0 bytes     = ;[L I T E] a b c d e ...
=               1 byte      = ;U [L I T E] a b c d e ...
=               2 bytes     U V&= nbsp;[L I T E] a b c d e ...
=               3 bytes     U V = W [L I T E] a b c d e ...
=               4 bytes     U V = W X [L I T E] a b c d e ... 
=               5 bytes     U V = W X Y [L I T E] a b c d e ... 
=               6 bytes    = ; U V W X Y Z [L I T E] a b c d e ...
=  
= after transmitting
=               0 bytes     [L I= T E] a b c d e ...
=               1 byte      = ;[L I T E] U a b c d e ...
=               2 bytes     [L I= T E] U V a b c d e ...
=               3 bytes     [L I= T E] U V W a b c d e ...
=               4 bytes     [L I= T E] U V W X a b c d e ...
=               5 bytes     = ;[L I T E] Y U V W X a b c d e ... 
=                    =                 ^
=               6 bytes    = ; [L I T E] Y Z U V W X a b c d e ...
=                    =                 ^ ^
=  
= The issue is highlighted with the carets (^). 
=  
= For 3 bytes or less, "SLIDE"
= For 4 bytes, SLIDE is the same as SWAP
= For more than 4 bytes, SWAP is more efficient than SLIDE (avoids a lo= ng copy of the data)
=  
= I don't think it's bad to have a special case for 3 or fewer bytes.
=
Joe
--=_65c9c1440433a2339579155f2e66f843-- From nobody Thu May 24 11:39:48 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55FB12E8B1 for ; Thu, 24 May 2018 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 sbGcF6FnNp8p for ; Thu, 24 May 2018 11:39:44 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 4F44A12E898 for ; Thu, 24 May 2018 11:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X0PzU/+SVCIF39JqC/0sBEM7KfttSSjToQJHwuHV950=; b=WCyWVMusfZ4LpfCY7DApdErfZ pWnr1yFnGKJGi7+4+eG5EAaYao3usott1v/IuVF9aniXsT2kql4VcAOJM8ThxirWtqGV7I1jK0ljo V2jj9fP1Nj2EkhmbMVWHqdFOwWGO5wG8jz6lDGrh6nWBSN1CFNZjzpun6T7dP0IMGXtSiWhPE+pxv UYV8OqAA1R7kKXeQH6TZkeQCi2G4ELN05KP2p7Y/JuB7r9DxVqpV0U3qLcfKgmtqSs7ndCBBdphux 5QiS2eAwnpF03jHNfHkpzwZDACAh3Bnoot03AH0lMiLc/5I6mcjFJEfaR8nG2PGrS9LhykHPQsiTH 3C1MliwGg==; Received: from [::1] (port=60158 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLv9L-003QFZ-5v; Thu, 24 May 2018 14:39:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_715c089cbe902dd26b0a66ccaa906569" Date: Thu, 24 May 2018 11:39:43 -0700 From: Joe Touch To: "C. M. Heard" Cc: tsvwg In-Reply-To: References: Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 18:39:47 -0000 --=_715c089cbe902dd26b0a66ccaa906569 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi, Mike, On 2018-05-06 10:23, C. M. Heard wrote: > Greetings, > > Some issues came to my attention during a recent off-list discussion with someone from the DNS community. > > Section 5.4, Alternate Checksum (ACS): since the option area is not included in the ACS, the following text seems out of place: > > When ACS is computed, its checksum (CRC) area is zeroed. No other > options are zeroed before computing ACS. > > All that is needed is to stuff the remainder of the standard polynomial long division in the ACS checksum area. Agreed. I need to check on that text throughout. > There are also some issues that need to nailed down for clarity. the usual way that the specified polynomial is used is to invert the first 16 bits of data and transmit the complement of the resulting polynomial division. If that is not done here, it would probably be good to say so. Also, it is necessary to specify whether the data polynomial is constructed as if the bytes are transmitted most significant bit first or least significant bit first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be 0x11021, but that fact is not needed, and I recommend omitting it). Agreed. > Section 5.5, LITE option: the following instruction > > 3. Swap all four bytes of the LITE option with the first 4 bytes of > the LITE data area (Figure 11). > > works only if the LITE data area is at least four bytes long. However, the option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one simply moves the option to the start of the LITE data area and moves the displaced LITE bytes just past the end of the relocated LITE option. This operation is then reversed on the receive side. In effect, one is swapping the locations of the LITE option and the initial segment of the LITE data area of length min(4, LITE offset). Agreed - I needed a whiteboard to see what you're doing here, but yes - SLIDE if Len < 4 and SWAP otherwise. Thanks - I'll add that. > Note that being able to use the LITE option with a length of zero is important for option negotiation. Agreed and worth pointing out when adding the text for the exception case. > Section 5,8, FRAG option: it appears to me that the length of the the terminal FRAG option is 10 bytes, not 12. This isn't stated, but the inference I make is that the the checksum is the standard UDP checksum, computed as if the datagram were sent unfragmented, but not including the pseudo-header (to avoid issues created by NAT). If this isn't what was intended, then the intent needs to be clearly spelled out. I note that if the alternate checksum as defined in Section 5.4 does not admit the use of the value zero to indicate that it is not present. I'll check but the intent is exactly as you inferred - and I need to double check the size as well. > Section 5.8.1, Coupling FRAG with LITE: if the comments above about the checksum field in the terminal FRAG option are correct, some text should be added here that the final checksum in the reconstituted UDP header is not taken directly from the terminal fragment, but is adjusted to include the UDP pseudo-header. Agreed. > Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over from a previous incarnation of the draft? > > UDP options support a similar service to UDP-Lite by terminating the > UDP options with an EOL option. The additional data not covered by > the UDP checksum follows that EOL option, and is passed to the user > separately. The difference is that UDP-Lite provides the un- > checksummed user data to the application by default, whereas UDP > options can provide the same capability only for endpoints that are > negotiated in advance (i.e., by default, UDP options would silently > discard this non-checksummed data). Additionally, in UDP-Lite the > checksummed and non-checksummed payload components are adjacent, > whereas in UDP options they are separated by the option area - > which, minimally, must consist of at least one EOL option. > > It seems to me that this should be rewritten, because the service in question is now provided by the LITE option. This text is exactly explaining the difference between our LITE and "UDP-Lite". I can clarify this, e.g.,: The UDP option LITE option supports a similar service to UDP-Lite.... Is there some part of this explanation of the differences that isn't accurate? > I'm hoping that there is still enough interest in this draft to push it to completion. As am I... Joe > Thanks and regards, > > Mike Heard --=_715c089cbe902dd26b0a66ccaa906569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi, Mike,

On 2018-05-06 10:23, C. M. Heard wrote:

Greetings,
 
Some issues came to my attention during a recent off-list discussion w= ith someone from the DNS community.
 
Section 5.4, Alternate Checksum (ACS): since the option area is not in= cluded in the ACS, the following text seems out of place:
 
   When A=
CS is computed, its checksum (CRC) area is zeroed. No other
   options are zeroed before computing ACS.
 
All that is needed is to stuff the remainder of the standard polynomia= l long division in the ACS checksum area.
 
Agreed. I need to check on that text throughout.
 
There are also some issues that need to nailed down for clarity. the u= sual way that the specified polynomial is used is to invert the first 16 bi= ts of data and transmit the complement of the resulting polynomial division= =2E If that is not done here, it would probably be good to say so. Also, it= is necessary to specify whether the data polynomial is constructed as if t= he bytes are transmitted most significant bit first or least significant bi= t first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be 0x11021, but that= fact is not needed, and I recommend omitting it).
 
Agreed.
 
Section 5.5, LITE option: the following instruction
 
   3. Swa=
p all four bytes of the LITE option with the first 4 bytes of
      the LITE data area (Figure 11).
 
works only if the LITE data area is at least four bytes long. However,= the option will work just fine with 0, 1, 2, or 3 bytes of LITE data if on= e simply moves the option to the start of the LITE data area and moves the = displaced LITE bytes just past the end of the relocated LITE option. This o= peration is then reversed on the receive side. In effect, one is swapping t= he locations of the LITE option and the initial segment of the LITE data ar= ea of length min(4, LITE offset).
 
Agreed - I needed a whiteboard to see what you're doing he= re, but yes - SLIDE if Len < 4 and SWAP otherwise. Thanks - I'll add tha= t.
 
 
Note that being able to use the LITE option with a length of zero is i= mportant for option negotiation.
 
Agreed and worth pointing out when adding the text for the exception c= ase.
 
 
Section 5,8, FRAG option: it appears to me that the length of the the = terminal FRAG option is 10 bytes, not 12. This isn't stated, but the infere= nce I make is that the the checksum is the standard UDP checksum, computed = as if the datagram were sent unfragmented, but not including the pseudo-hea= der (to avoid issues created by NAT). If this isn't what was intended, then= the intent needs to be clearly spelled out. I note that if the alternate c= hecksum as defined in Section 5.4 does not admit the use of the value zero = to indicate that it is not present.
 
I'll check but the intent is exactly as you inferred - and I need to d= ouble check the size as well.
 
Section 5.8.1, Coupling FRAG with LITE: if the comments above about the che= cksum field in the terminal FRAG option are correct, some text should be ad= ded here that the final checksum in the reconstituted UDP header is not tak= en directly from the terminal fragment, but is adjusted to include the UDP = pseudo-header.
 
Agreed.
 
Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over f= rom a previous incarnation of the draft?
 
   UDP op=
tions support a similar service to UDP-Lite by terminating the
   UDP options with an EOL option. The additional data not covered by
   the UDP checksum follows that EOL option, and is passed to the user
   separately. The difference is that UDP-Lite provides the un-
   checksummed user data to the application by default, whereas UDP
   options can provide the same capability only for endpoints that are
   negotiated in advance (i.e., by default, UDP options would silently
   discard this non-checksummed data). Additionally, in UDP-Lite the
   checksummed and non-checksummed payload components are adjacent,
   whereas in UDP options they are separated by the option area -
   which, minimally, must consist of at least one EOL option.
 
It seems to me that this should be rewritten, because the service in q= uestion is now provided by the LITE option.
 
 
This text is exactly explaining the difference between our LITE and "U= DP-Lite". I can clarify this, e.g.,:
 
    The UDP option LITE option supports a similar service to= UDP-Lite....
 
Is there some part of this explanation of the differences that isn't a= ccurate?
 
 
I'm hoping that there is still enough interest in this draft to push i= t to completion.
 
 
As am I...
 
Joe
 
 
Thanks and regards,
 
Mike Heard
--=_715c089cbe902dd26b0a66ccaa906569-- From nobody Thu May 24 11:43:51 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7F12E8B1 for ; Thu, 24 May 2018 11:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 4GRXxoh0Uhmd for ; Thu, 24 May 2018 11:43:48 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C5DDE12E898 for ; Thu, 24 May 2018 11:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:To: From:Date:Content-Type:MIME-Version:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l3JVncDEzpkQ1oGcZ+CNk1I2ENYKfCTX0Ut/r8dEODw=; b=hSmidyWmg84fzI8d30w1CWo7t PfH/Ka8UQdwb7LJ3i46LT39aacptO3CzouyAUe4SJFYngAosf9uBZbUoT+r98+t3wJ6xr/dsH8gpg yNPxmjONnCM39OZoybn1soCz4SsT4a1oBwFd1yL5Ddn8vxiD+Gzc8y2wNMy0RCeJl34z1/J5rnu3O GPfq5t4/W9JqVeE/bYUhO09wQor5bKI0TjMNO2FlWjibq2fylKaX/BMYwJTs24UKCHcxLknOQYlhx ZyJ2E/uoJjreRqfpyLD040zB0Fqk6NzBjrKYrkpton/C7gUkWgh1bXBhHyc8NDIneHppHdCTKwW0i 5aBuCzYqw==; Received: from [::1] (port=60584 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLvDH-003TSi-Pj; Thu, 24 May 2018 14:43:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d216fe0e4f5177dd46538c07a6457c56" Date: Thu, 24 May 2018 11:43:47 -0700 From: Joe Touch To: tsvwg In-Reply-To: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 18:43:51 -0000 --=_d216fe0e4f5177dd46538c07a6457c56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi, all, I didn't see any comments on the following - it would be useful to hear from anyone on the list regarding the issues below so we can run a rev on the doc and pin these things down. So far I've heard from only two parties - I'd appreciate both them and anyone else providing a very brief list of positions on these... Thanks, Joe On 2018-03-04 14:39, Joe Touch wrote: > Hi, all, > > IMO, we would benefit popping up a level to the list of issues and summarizing our views. > > Here's my attempt to do that. > > Joe > > ------ > > Some assumptions: > a) overhead is useful to minimize (efficiency and may reduce or avoid fragmentation) > b) LITE capability must be preserved > c) LITE+FRAG capability must be preserved > d) this solution is not expected to outperform TCP (i.e., this is not an opportunity to redesign transport from scratch) > > - TLV vs fixed header > motivated (AFAICT) by the desire to enable hardware optimization and/or to detect error/misuses of spare area > no clear hardware benefit (given the option area "floats" relative to the UDP header, > which floats relative to the IPv6 header TLV chain, and given it may not be word aligned) > no clear benefit regarding packet errors or other spare area uses > (both require either CS works or TLV chain parses, neither of which is likely for random errors or other misuses) > fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting LITE/LITE+FRAG) > > - Optional CS vs. mandatory > motivated (AFAICT) by the desire to avoid processing packets with errors (accidental or by others misusing the extra space) > optional is needed to correlate to lack of UDP checksum (for some types of tunnels, e.g.) > mandatory also implies fixed (above), which incurs 2-6 bytes of overhead > > - option-area checksum details > size > 8 if TLV, 16 if fixed; no clear problem with either choice > algorithm > no clear issue with using minor mods (foldover for 8 bit, invert or not) > there are known dangers to using the complement of the sum > (such that the sum and data zero-out), as noted by the Partridge paper in the 90s. > > - EOL vs option length field > length would have to be 2 bytes; EOL is an optional one byte (not needed if no spare area remains) > EOL thus saves up to 2 bytes when not needed (and it should generally not be needed at all) > allowing EOL (i.e., allowing remaining unused spare area) implies that processing needs to stop at some point, > either based on a counter or the data seen (and given that a CS loads data into a register anyway, there's no clear performance win to either approach) > EOL itself is patterned after the TCP option of the same name > and yes, leaving the spare area available for future use by other protocol extensions is intended here > > - does CS end when EOL is seen? > yes, as currently specified > as noted above, leaving the spare are for future standards is a goal > > My conclusion is that all the choices above either fail to improve the situation vs. our current proposal or increase overhead (or both). I don't yet see a reason why any of them warrant a change vs. the existing approach. --=_d216fe0e4f5177dd46538c07a6457c56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi, all,

I didn't see any comments on the following - it would be useful to hear = from anyone on the list regarding the issues below so we can run a rev on t= he doc and pin these things down.

So far I've heard from only two parties - I'd appreciate both them and a= nyone else providing a very brief list of positions on these...

Thanks,
Joe

 


On 2018-03-04 14:39, Joe Touch wrote:

Hi, all,
 
IMO, we would benefit popping up a level to= the list of issues and summarizing our views.
 
Here's my attempt to do that.
 
Joe
 
———
 
Some assumptions:
a) overhead is useful to minimize (efficiency and m= ay reduce or avoid fragmentation)
b) LITE capability must be preserved
c) LITE+FRAG capability must be preserved
d) this solution is not expected to outperform TCP = (i.e., this is not an opportunity to redesign transport from scratch)
 
- TLV vs fixed header
motivated (AFAICT) by the desire to enable hardware= optimization and/or to detect error/misuses of spare area
no clear hardware benefit (given the option area "f= loats" relative to the UDP header, 
which floats relative to the IPv6 header TLV chain,= and given it may not be word aligned)
no clear benefit regarding packet errors or other s= pare area uses 
(both require either CS works or TLV chain parses, = neither of which is likely for random errors or other misuses)
fixed wastes at least 2 bytes if CS isn't used, (ma= ybe 4-6 if supporting LITE/LITE+FRAG)
 
- Optional CS vs. mandatory
motivated (AFAICT) by the desire to avoid processin= g packets with errors (accidental or by others misusing the extra space)
optional is needed to correlate to lack of UDP chec= ksum (for some types of tunnels, e.g.)
mandatory also implies fixed (above), which incurs = 2-6 bytes of overhead
 
- option-area checksum details
size
8 if TLV, 16 if fixed; no clear problem with either= choice
algorithm
no clear issue with using minor mods (foldover for = 8 bit, invert or not)
there are known dangers to using the complement of = the sum 
(such that the sum and data zero-out), as noted by = the Partridge paper in the 90s.
 
- EOL vs option length field
length would have to be 2 bytes; EOL is an optional= one byte (not needed if no spare area remains)
EOL thus saves up to 2 bytes when not needed (and i= t should generally not be needed at all)
allowing EOL (i.e., allowing remaining unused spare= area) implies that processing needs to stop at some point, 
either based on a counter or the data seen (and giv= en that a CS loads data into a register anyway, there's no clear performanc= e win to either approach)
EOL itself is patterned after the TCP option of the= same name
and yes, leaving the spare area available for futur= e use by other protocol extensions is intended here
 
- does CS end when EOL is seen?
yes, as currently specified
as noted above, leaving the spare are for future st= andards is a goal
 
My conclusion is that all the choices above= either fail to improve the situation vs. our current proposal or increase = overhead (or both). I don't yet see a reason why any of them warrant a chan= ge vs. the existing approach.
 
--=_d216fe0e4f5177dd46538c07a6457c56-- From nobody Thu May 24 12:52:38 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1319D129C56 for ; Thu, 24 May 2018 12:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 SacbUKU4R4sC for ; Thu, 24 May 2018 12:52:33 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8D21275F4 for ; Thu, 24 May 2018 12:52:33 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id c198-v6so2295585qkg.12 for ; Thu, 24 May 2018 12:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6gqVQKRrKr4r6HDqLwpXl5YiIuNC2hT3kuKpOYF9g9M=; b=SCuCj0USBtAMYrM0hnSIIII9fsMXEM8Dw2PL6bFf0lRmKHUL1LxGGVQyCGRqP9qv9i 4jknXeuapjbif+ZzkfAA1tGFIUzhkL0RiXjjvS/e9EyNUhkoVLrdgkFDDzBWz6EqCxhd sA6zcON07vd9izX08kQ7EfD7Ac1TulcJ7JdgCWYZTr/DmX1idzkSr58gdhdWv8ud1PuT 1gmaigicBkMKgB/KxTgO0UBn1YH7Vn9XpKjaSjZ8JQgrWqXHojbchhobhP/UgywpY++H kSZ8TaOm9kO4NfLqyoV8U4GBJZTGPZ0UYuX+Vw5ulYCrZ5TEMrom6OsV4m2/xbDFvwac o18A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6gqVQKRrKr4r6HDqLwpXl5YiIuNC2hT3kuKpOYF9g9M=; b=ulkZFrs+8FIjltUMJyyCmz6MJfWCompiunRhtReqg9PGGUqDfxBwTZfQDIvHjCUqln 5bn//CX+giXw5OBN+AVzigJKC8r+hOfcs+BZaLo/cYOfl6Etb9k0XLK0WZNz5sa5Sel0 YSEDPRXfptvs/RQhmkD0VYpiT28yXERflwftmBljzGv09NDQyWIfB/f4BFoFIa4RKmlV MAkiCcfSbJ141EH3eFOFG1LhCPj834yWAfOc2BI2Z5bAZCMXV1p2F7lxFKJweCajXBTa JpsgrVWcKnJ6edz6nYeUpW2d9NlAuTIgXT5Dywh/v9ofBQ/gf38fMVqpJ1sYVKapY488 vEhQ== X-Gm-Message-State: ALKqPwezTBXT+1mI5SJ72n+tCdlC4dU7cdfCtpU+pjgerKc312c2KhB0 bTVPcw5RF7LltbP/fReU6m/sXeraMpNc4flz2LvD5Q== X-Google-Smtp-Source: ADUXVKJQukzCK3MrK1gMCDajGxTctbOKAB2WDVuXA9kZRkW90BLLjVuZ9V7fwlYwpG7xt/XLgm8ktSX9dh18tYkvh2s= X-Received: by 2002:a37:7dc1:: with SMTP id y184-v6mr7791873qkc.311.1527191552319; Thu, 24 May 2018 12:52:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:3042:0:0:0:0:0 with HTTP; Thu, 24 May 2018 12:52:31 -0700 (PDT) In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> From: Tom Herbert Date: Thu, 24 May 2018 12:52:31 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 19:52:36 -0000 On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: > Hi, all, > > I didn't see any comments on the following - it would be useful to hear f= rom > anyone on the list regarding the issues below so we can run a rev on the = doc > and pin these things down. > > So far I've heard from only two parties - I'd appreciate both them and > anyone else providing a very brief list of positions on these... > Joe, One of the problems with TLVs in a datapath protocol is that they can too easily be used for DOS attack. This is especially true in the case that unkown TLV types are be ignored by a receiver and there is no reasonable protocol limit to the number of TLVs can be put into a packet. Both of these conditions seem to be true for the UDP options. The attack is simple, just fill up a packet with tiny TLVs with unknown types to the receiver. A mitigation is described in the draft: ">> Required options MUST come before other options. Each required option MUST NOT occur more than once (if they are repeated in a received segment, all except the first MUST be silently ignored)." and "Implementations concerned with the potential for this vulnerability MAY implement only the required options" The first question I have to this is what are "required options". I don't see where this is defined. Also, required is ambiguous. I assume the intent is that these are options that a receiver is required to implement-- but that could have other meanings, like options that a sender is required to send. This needs to be clarified. Also, if required options must appear first then that raises another question: what happens if a packet is received where required options follow non-required options. How does the receiver deal with this? I'll assume for sake of argument that the options specified in the draft are required options in that sense that a receiver must understand these. So then my next question is how can any new required options be added. Say that type 9 is defined as new security option that is considered a required option. How will deployed devices know that this is a required option (as opposed to one that isn't required and can be ignored)? Seems like the proper way to deal with would be to steal a bit from the type field that indicates the receive behavior if the type in unknown-- either ignore TLV or drop packet. This is similar to high order two bits of IPv6 option types (an option to send an ICMP error might also be useful here). But, even if the required options are handled, DOS is still a problem if an implementation wants to process even one non required option. In that case it always needs to parse all the TLVs (i.e. it doesn't know where in the TLV list the option is that it's looking for). So this presents the implementor with an unpleasant tradeoff, implementing any non-required options may mean allowing exposure to DOS attack. BTW, this DOS attack issue comes up in other context. For DO and HBH options we added text to draft-ietf-6man-rfc6434-bis-08 that allows configurable limits on number of options (regardless of whether the options are "required"). If the limit is exceeded the packet is dropped. In Linux the default is to allow up to eight options, that's approximately based on the number of implemented options plus five. Tom > Thanks, > Joe > > > > > On 2018-03-04 14:39, Joe Touch wrote: > > Hi, all, > > IMO, we would benefit popping up a level to the list of issues and > summarizing our views. > > Here's my attempt to do that. > > Joe > > =E2=80=94=E2=80=94=E2=80=94 > > Some assumptions: > a) overhead is useful to minimize (efficiency and may reduce or avoid > fragmentation) > b) LITE capability must be preserved > c) LITE+FRAG capability must be preserved > d) this solution is not expected to outperform TCP (i.e., this is not an > opportunity to redesign transport from scratch) > > - TLV vs fixed header > motivated (AFAICT) by the desire to enable hardware optimization and/or t= o > detect error/misuses of spare area > no clear hardware benefit (given the option area "floats" relative to the > UDP header, > which floats relative to the IPv6 header TLV chain, and given it may not = be > word aligned) > no clear benefit regarding packet errors or other spare area uses > (both require either CS works or TLV chain parses, neither of which is > likely for random errors or other misuses) > fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting > LITE/LITE+FRAG) > > - Optional CS vs. mandatory > motivated (AFAICT) by the desire to avoid processing packets with errors > (accidental or by others misusing the extra space) > optional is needed to correlate to lack of UDP checksum (for some types o= f > tunnels, e.g.) > mandatory also implies fixed (above), which incurs 2-6 bytes of overhead > > - option-area checksum details > size > 8 if TLV, 16 if fixed; no clear problem with either choice > algorithm > no clear issue with using minor mods (foldover for 8 bit, invert or not) > there are known dangers to using the complement of the sum > (such that the sum and data zero-out), as noted by the Partridge paper in > the 90s. > > - EOL vs option length field > length would have to be 2 bytes; EOL is an optional one byte (not needed = if > no spare area remains) > EOL thus saves up to 2 bytes when not needed (and it should generally not= be > needed at all) > allowing EOL (i.e., allowing remaining unused spare area) implies that > processing needs to stop at some point, > either based on a counter or the data seen (and given that a CS loads dat= a > into a register anyway, there's no clear performance win to either approa= ch) > EOL itself is patterned after the TCP option of the same name > and yes, leaving the spare area available for future use by other protoco= l > extensions is intended here > > - does CS end when EOL is seen? > yes, as currently specified > as noted above, leaving the spare are for future standards is a goal > > My conclusion is that all the choices above either fail to improve the > situation vs. our current proposal or increase overhead (or both). I don'= t > yet see a reason why any of them warrant a change vs. the existing approa= ch. > From nobody Thu May 24 14:08:57 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C503C12D7FC for ; Thu, 24 May 2018 14:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 yNhdMwwQ6ka8 for ; Thu, 24 May 2018 14:08:52 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DA58712D77D for ; Thu, 24 May 2018 14:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9if+s6v9K8dt9bn83wxrM41JHnzTJOcjNl/ICqMrSaY=; b=dCy40riwpbDc1cNmZNwTtIRUM KEEJN2sTNPKri1t5013F/qdnVqOEmCi4eu4sM9Filr5fR0vretJsQzYroK2yQlsgNaHRon3qwESzK S8FL2w6vojy526LMLpDZxtJfrsjZ8hXqWrBe8Hofd97TuTjc58LsB0tWjNc8PzGieMhHVCWnrpdmz VAJOkRRVp6pk4uS4pR7RSIju8185/QcowKXNsAfTQ65ds2qHqSau0iTd6gtWsAg4lEgCRps1J1EUT LFdySB7Lj1Sd30F0oCxMx0zsks3gEVarGt+91tZGmAIWrnflHP2ufEfL13QMvJoVYy6L1iS8GsGoH ZehDe26sw==; Received: from [::1] (port=41698 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fLxTb-001Haz-R5; Thu, 24 May 2018 17:08:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0aeb13fe1c994921a0e03f574b9fde26" Date: Thu, 24 May 2018 14:08:47 -0700 From: Joe Touch To: Tom Herbert Cc: tsvwg In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 21:08:56 -0000 --=_0aeb13fe1c994921a0e03f574b9fde26 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Tom, We've had the TLV discussion on other lists. What I'm wondering here is why UDP options would need to be different than TCP options - which are TLV exactly to allow the flexibility of future evolution that have enabled quite a few TCP features beyond the fixed header. It would be useful to hear from others on this point as well. Some clarifications: - required options are those with a star (*) in sec 5; we can adjust that list prior to final publication vs. the ones currently indicated - "required' means 'required to implement' only; all options are optional to use in general (they may be expected on a given association, but that doesn't mandate order) Joe On 2018-05-24 12:52, Tom Herbert wrote: > On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: > >> Hi, all, >> >> I didn't see any comments on the following - it would be useful to hear from >> anyone on the list regarding the issues below so we can run a rev on the doc >> and pin these things down. >> >> So far I've heard from only two parties - I'd appreciate both them and >> anyone else providing a very brief list of positions on these... > Joe, > > One of the problems with TLVs in a datapath protocol is that they can > too easily be used for DOS attack. This is especially true in the case > that unkown TLV types are be ignored by a receiver and there is no > reasonable protocol limit to the number of TLVs can be put into a > packet. Both of these conditions seem to be true for the UDP options. > The attack is simple, just fill up a packet with tiny TLVs with > unknown types to the receiver. > > A mitigation is described in the draft: > > ">> Required options MUST come before other options. Each required > option MUST NOT occur more than once (if they are repeated in a > received segment, all except the first MUST be silently ignored)." > > and > > "Implementations concerned with the potential for this vulnerability > MAY implement only the required options" > > The first question I have to this is what are "required options". I > don't see where this is defined. Also, required is ambiguous. I assume > the intent is that these are options that a receiver is required to > implement-- but that could have other meanings, like options that a > sender is required to send. This needs to be clarified. Also, if > required options must appear first then that raises another question: > what happens if a packet is received where required options follow > non-required options. How does the receiver deal with this? > > I'll assume for sake of argument that the options specified in the > draft are required options in that sense that a receiver must > understand these. So then my next question is how can any new required > options be added. Say that type 9 is defined as new security option > that is considered a required option. How will deployed devices know > that this is a required option (as opposed to one that isn't required > and can be ignored)? Seems like the proper way to deal with would be > to steal a bit from the type field that indicates the receive behavior > if the type in unknown-- either ignore TLV or drop packet. This is > similar to high order two bits of IPv6 option types (an option to send > an ICMP error might also be useful here). > > But, even if the required options are handled, DOS is still a problem > if an implementation wants to process even one non required option. In > that case it always needs to parse all the TLVs (i.e. it doesn't know > where in the TLV list the option is that it's looking for). So this > presents the implementor with an unpleasant tradeoff, implementing any > non-required options may mean allowing exposure to DOS attack. > > BTW, this DOS attack issue comes up in other context. For DO and HBH > options we added text to draft-ietf-6man-rfc6434-bis-08 that allows > configurable limits on number of options (regardless of whether the > options are "required"). If the limit is exceeded the packet is > dropped. In Linux the default is to allow up to eight options, that's > approximately based on the number of implemented options plus five. > > Tom > >> Thanks, >> Joe >> >> On 2018-03-04 14:39, Joe Touch wrote: >> >> Hi, all, >> >> IMO, we would benefit popping up a level to the list of issues and >> summarizing our views. >> >> Here's my attempt to do that. >> >> Joe >> >> ------ >> >> Some assumptions: >> a) overhead is useful to minimize (efficiency and may reduce or avoid >> fragmentation) >> b) LITE capability must be preserved >> c) LITE+FRAG capability must be preserved >> d) this solution is not expected to outperform TCP (i.e., this is not an >> opportunity to redesign transport from scratch) >> >> - TLV vs fixed header >> motivated (AFAICT) by the desire to enable hardware optimization and/or to >> detect error/misuses of spare area >> no clear hardware benefit (given the option area "floats" relative to the >> UDP header, >> which floats relative to the IPv6 header TLV chain, and given it may not be >> word aligned) >> no clear benefit regarding packet errors or other spare area uses >> (both require either CS works or TLV chain parses, neither of which is >> likely for random errors or other misuses) >> fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting >> LITE/LITE+FRAG) >> >> - Optional CS vs. mandatory >> motivated (AFAICT) by the desire to avoid processing packets with errors >> (accidental or by others misusing the extra space) >> optional is needed to correlate to lack of UDP checksum (for some types of >> tunnels, e.g.) >> mandatory also implies fixed (above), which incurs 2-6 bytes of overhead >> >> - option-area checksum details >> size >> 8 if TLV, 16 if fixed; no clear problem with either choice >> algorithm >> no clear issue with using minor mods (foldover for 8 bit, invert or not) >> there are known dangers to using the complement of the sum >> (such that the sum and data zero-out), as noted by the Partridge paper in >> the 90s. >> >> - EOL vs option length field >> length would have to be 2 bytes; EOL is an optional one byte (not needed if >> no spare area remains) >> EOL thus saves up to 2 bytes when not needed (and it should generally not be >> needed at all) >> allowing EOL (i.e., allowing remaining unused spare area) implies that >> processing needs to stop at some point, >> either based on a counter or the data seen (and given that a CS loads data >> into a register anyway, there's no clear performance win to either approach) >> EOL itself is patterned after the TCP option of the same name >> and yes, leaving the spare area available for future use by other protocol >> extensions is intended here >> >> - does CS end when EOL is seen? >> yes, as currently specified >> as noted above, leaving the spare are for future standards is a goal >> >> My conclusion is that all the choices above either fail to improve the >> situation vs. our current proposal or increase overhead (or both). I don't >> yet see a reason why any of them warrant a change vs. the existing approach. --=_0aeb13fe1c994921a0e03f574b9fde26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Tom,

We've had the TLV discussion on other lists.

What I'm wondering here is why UDP options would need to be different th= an TCP options - which are TLV exactly to allow the flexibility of future e= volution that have enabled quite a few TCP features beyond the fixed header= =2E

It would be useful to hear from others on this point as well.

Some clarifications:

- required options are those with a star (*) in sec 5; we can adjust tha= t list prior to final publication vs. the ones currently indicated

- "required' means 'required to implement' only; all options are optiona= l to use in general (they may be expected on a given association, but = that doesn't mandate order)

 

Joe

On 2018-05-24 12:52, Tom Herbert wrote:

= On Thu, May 24, 2018 at 11:43 AM, Joe Touch <touch@strayalpha.com> wrote:
Hi, all,

I didn't see any comments on the = following - it would be useful to hear from
anyone on the list regard= ing the issues below so we can run a rev on the doc
and pin these thi= ngs down.

So far I've heard from only two parties - I'd appreci= ate both them and
anyone else providing a very brief list of position= s on these...

Joe,

One of the problems with TLVs in a datapath protocol is th= at they can
too easily be used for DOS attack. This is especially tru= e in the case
that unkown TLV types are be ignored by a receiver and = there is no
reasonable protocol limit to the number of TLVs can be pu= t into a
packet. Both of these conditions seem to be true for the UDP= options.
The attack is simple, just fill up a packet with tiny TLVs = with
unknown types to the receiver.

A mitigation is descr= ibed in the draft:

 ">> Required options MUST come b= efore other options. Each required
option MUST NOT occur more than on= ce (if they are repeated in a
received segment, all except the first = MUST be silently ignored)."

and

"Implementations co= ncerned with the potential for this vulnerability
MAY implement only = the required options"

The first question I have to this is what= are "required options". I
don't see where this is defined. Also, req= uired is ambiguous. I assume
the intent is that these are options tha= t a receiver is required to
implement-- but that could have other mea= nings, like options that a
sender is required to send. This needs to = be clarified. Also, if
required options must appear first then that r= aises another question:
what happens if a packet is received where re= quired options follow
non-required options. How does the receiver dea= l with this?

I'll assume for sake of argument that the options = specified in the
draft are required options in that sense that a rece= iver must
understand these. So then my next question is how can any n= ew required
options be added. Say that type 9 is defined as new secur= ity option
that is considered a required option. How will deployed de= vices know
that this is a required option (as opposed to one that isn= 't required
and can be ignored)? Seems like the proper  way to d= eal with would be
to steal a bit from the type field that indicates t= he receive behavior
if the type in unknown-- either ignore TLV or dro= p packet. This is
similar to high order two bits of IPv6 option types= (an option to send
an ICMP error might also be useful here).
But, even if the required options are handled, DOS is still a problem<= br /> if an implementation wants to process even one non required option. I= n
that case it always needs to parse all the TLVs (i.e. it doesn't kn= ow
where in the TLV list the option is that it's looking for). So thi= s
presents the implementor with an unpleasant tradeoff, implementing = any
non-required options may mean allowing exposure to DOS attack.
BTW, this DOS attack issue comes up in other context. For DO and = HBH
options we added text to draft-ietf-6man-rfc6434-bis-08 that allo= ws
configurable limits on number of options (regardless of whether th= e
options are "required"). If the limit is exceeded the packet is
dropped. In Linux the default is to allow up to eight options, that's approximately based on the number of implemented options plus five.

Tom




Thanks,
Joe




On 201= 8-03-04 14:39, Joe Touch wrote:

Hi, all,

IMO, we wo= uld benefit popping up a level to the list of issues and
summarizing = our views.

Here's my attempt to do that.

Joe
<= br /> ———

Some assumptions:
a) overhead= is useful to minimize (efficiency and may reduce or avoid
fragmentat= ion)
b) LITE capability must be preserved
c) LITE+FRAG capabili= ty must be preserved
d) this solution is not expected to outperform T= CP (i.e., this is not an
opportunity to redesign transport from scrat= ch)

- TLV vs fixed header
motivated (AFAICT) by the desir= e to enable hardware optimization and/or to
detect error/misuses of s= pare area
no clear hardware benefit (given the option area "floats" r= elative to the
UDP header,
which floats relative to the IPv6 he= ader TLV chain, and given it may not be
word aligned)
no clear = benefit regarding packet errors or other spare area uses
(both requir= e either CS works or TLV chain parses, neither of which is
likely for= random errors or other misuses)
fixed wastes at least 2 bytes if CS = isn't used, (maybe 4-6 if supporting
LITE/LITE+FRAG)

- Op= tional CS vs. mandatory
motivated (AFAICT) by the desire to avoid pro= cessing packets with errors
(accidental or by others misusing the ext= ra space)
optional is needed to correlate to lack of UDP checksum (fo= r some types of
tunnels, e.g.)
mandatory also implies fixed (ab= ove), which incurs 2-6 bytes of overhead

- option-area checksum= details
size
8 if TLV, 16 if fixed; no clear problem with eith= er choice
algorithm
no clear issue with using minor mods (foldo= ver for 8 bit, invert or not)
there are known dangers to using the co= mplement of the sum
(such that the sum and data zero-out), as noted b= y the Partridge paper in
the 90s.

- EOL vs option length = field
length would have to be 2 bytes; EOL is an optional one byte (n= ot needed if
no spare area remains)
EOL thus saves up to 2 byte= s when not needed (and it should generally not be
needed at all)
allowing EOL (i.e., allowing remaining unused spare area) implies that processing needs to stop at some point,
either based on a counter= or the data seen (and given that a CS loads data
into a register any= way, there's no clear performance win to either approach)
EOL itself = is patterned after the TCP option of the same name
and yes, leaving t= he spare area available for future use by other protocol
extensions i= s intended here

- does CS end when EOL is seen?
yes, as c= urrently specified
as noted above, leaving the spare are for future s= tandards is a goal

My conclusion is that all the choices above = either fail to improve the
situation vs. our current proposal or incr= ease overhead (or both). I don't
yet see a reason why any of them war= rant a change vs. the existing approach.

--=_0aeb13fe1c994921a0e03f574b9fde26-- From nobody Thu May 24 14:50:06 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191BC12E899 for ; Thu, 24 May 2018 14:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 n3c10WbBrKzS for ; Thu, 24 May 2018 14:50:01 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9D812E884 for ; Thu, 24 May 2018 14:50:01 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id c2-v6so4083833qtn.9 for ; Thu, 24 May 2018 14:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eB+KYgfzS3hfg9IQeNt0eei+PdDsdlHz1eF8mW8tNi0=; b=Gmkdc27lTbF4Tb03L+zaKeat/PSDQBf/+8MEF9h+svr6l7jsySF5PC4T870bbC7mmK HWSlfCB4X8GITdV/+pwQ9/VgA1o7sH3CNmGl1PYRVYWDfaaEqNpuNPyHK1GbCcKUiNFI K2Vz8pLezOn6EiHf18oUUgIOwr9mQHJi9EYGkpy7jaSY/seTss2OxRV6hmzU86PNXcMY z3uCbq7LVLgjK2uZg7dKD3xhB5Yc06pRfHjX1Vt89qLaDMlOxwLwuzvIF8xH5vblgXFq Z8ZPqcLhAUoEMlkmiJvs+LlDL82rBFaxCTIn5Uba9WvMNKu+7Zl17VpbwSTj4HubYSjB b8tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eB+KYgfzS3hfg9IQeNt0eei+PdDsdlHz1eF8mW8tNi0=; b=rOyUVEgMNsuRQ/yXTtpbodozytxbZ7lbdpTetLSENE+N7FOJyqM+e0Z/iqI1J7fVZy 6pwueGh5d7mxV7wzxcsMBoFjp5bOumHHfTP1wJCepCKIQNzL28IytGliMdin4a7EWvlw BfyqUxp1eTX/rdm7hLPDNWGt5GmxlUXwRnkZFXOeSMUGsRL+CO1hCAatnzoi6sUhzncx 90VHO0K45hivAxb51t+CHjM3CuVE+6w2WmVYUWFp8SDokOuNsP8XUXjVsnBGDp6I/tGZ mRyjSU/6ss3Oy9JjsKG/dRpdUrghpD0yNMQwZ5wyBzNSzYDn01UM/33702iKpQs8YBXb oktg== X-Gm-Message-State: ALKqPwftARTLD8zdmjhz2XIpRtDvZeQcmUrwUuehSUxGvknombTq+sRq JldBGUGWwqMPLZlRemV4V4S4Vt0i2OmgVMWbrqeTsQ== X-Google-Smtp-Source: AB8JxZrCbZKYD9mZBB7laP1liQdcQ7A0YLbXVKH4eNsJ6/EO8gYRN0OWyNdr+yHes2ME3Lr4QFBAWEBw27WVvcl3IGs= X-Received: by 2002:a0c:bc85:: with SMTP id l5-v6mr8797252qvg.242.1527198599944; Thu, 24 May 2018 14:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:3042:0:0:0:0:0 with HTTP; Thu, 24 May 2018 14:49:59 -0700 (PDT) In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> From: Tom Herbert Date: Thu, 24 May 2018 14:49:59 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 21:50:04 -0000 On Thu, May 24, 2018 at 2:08 PM, Joe Touch wrote: > Tom, > > We've had the TLV discussion on other lists. > > What I'm wondering here is why UDP options would need to be different tha= n > TCP options - which are TLV exactly to allow the flexibility of future > evolution that have enabled quite a few TCP features beyond the fixed > header. They are different because: 1) TCP options are limited to forty bytes in length 2) TCP options are negotiated 3) For a non-SYN packet, options are only processed after the TCP connection is matched. In other words, there is no way to send unsolicited TCP packets with long lists of TLVs to DOS a receiver (even if EDO were in use). UDP options are much more like IPv6 DO and HBH options in this regard. > > It would be useful to hear from others on this point as well. > > Some clarifications: > > - required options are those with a star (*) in sec 5; we can adjust that > list prior to final publication vs. the ones currently indicated > I see, these were not explicitly called out to be required options. Probably need some more text about this. Also, does this mean that the three options marked as required (or whatever others are added to the required list before publication) are the only ones that will ever be required in UDP options (see my point about problem in adding new required options). I am a little suprised that ACS isn't required. This means that a sender may go though all of the work to create the checksum, but a receiver can simply ignore it. That behavior is not typical of checksums in IP protocols. Usually, the sender controls whether checksum is set and receivers only accept packets with the checksum present if it has been verified (like how UDP checksum is optional by sender to set, but not optional for receiver to ignore if it's non-zero, RFC1122). > - "required' means 'required to implement' only; all options are optional= to > use in general (they may be expected on a given association, but that > doesn't mandate order) I think you mean required to be implemented and be recognized by a receiver. Please clarify this in the next draft. Tom > > > > Joe > > On 2018-05-24 12:52, Tom Herbert wrote: > > On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: > > Hi, all, > > I didn't see any comments on the following - it would be useful to hear f= rom > anyone on the list regarding the issues below so we can run a rev on the = doc > and pin these things down. > > So far I've heard from only two parties - I'd appreciate both them and > anyone else providing a very brief list of positions on these... > > Joe, > > One of the problems with TLVs in a datapath protocol is that they can > too easily be used for DOS attack. This is especially true in the case > that unkown TLV types are be ignored by a receiver and there is no > reasonable protocol limit to the number of TLVs can be put into a > packet. Both of these conditions seem to be true for the UDP options. > The attack is simple, just fill up a packet with tiny TLVs with > unknown types to the receiver. > > A mitigation is described in the draft: > > ">> Required options MUST come before other options. Each required > option MUST NOT occur more than once (if they are repeated in a > received segment, all except the first MUST be silently ignored)." > > and > > "Implementations concerned with the potential for this vulnerability > MAY implement only the required options" > > The first question I have to this is what are "required options". I > don't see where this is defined. Also, required is ambiguous. I assume > the intent is that these are options that a receiver is required to > implement-- but that could have other meanings, like options that a > sender is required to send. This needs to be clarified. Also, if > required options must appear first then that raises another question: > what happens if a packet is received where required options follow > non-required options. How does the receiver deal with this? > > I'll assume for sake of argument that the options specified in the > draft are required options in that sense that a receiver must > understand these. So then my next question is how can any new required > options be added. Say that type 9 is defined as new security option > that is considered a required option. How will deployed devices know > that this is a required option (as opposed to one that isn't required > and can be ignored)? Seems like the proper way to deal with would be > to steal a bit from the type field that indicates the receive behavior > if the type in unknown-- either ignore TLV or drop packet. This is > similar to high order two bits of IPv6 option types (an option to send > an ICMP error might also be useful here). > > But, even if the required options are handled, DOS is still a problem > if an implementation wants to process even one non required option. In > that case it always needs to parse all the TLVs (i.e. it doesn't know > where in the TLV list the option is that it's looking for). So this > presents the implementor with an unpleasant tradeoff, implementing any > non-required options may mean allowing exposure to DOS attack. > > BTW, this DOS attack issue comes up in other context. For DO and HBH > options we added text to draft-ietf-6man-rfc6434-bis-08 that allows > configurable limits on number of options (regardless of whether the > options are "required"). If the limit is exceeded the packet is > dropped. In Linux the default is to allow up to eight options, that's > approximately based on the number of implemented options plus five. > > Tom > > > > > Thanks, > Joe > > > > > On 2018-03-04 14:39, Joe Touch wrote: > > Hi, all, > > IMO, we would benefit popping up a level to the list of issues and > summarizing our views. > > Here's my attempt to do that. > > Joe > > =E2=80=94=E2=80=94=E2=80=94 > > Some assumptions: > a) overhead is useful to minimize (efficiency and may reduce or avoid > fragmentation) > b) LITE capability must be preserved > c) LITE+FRAG capability must be preserved > d) this solution is not expected to outperform TCP (i.e., this is not an > opportunity to redesign transport from scratch) > > - TLV vs fixed header > motivated (AFAICT) by the desire to enable hardware optimization and/or t= o > detect error/misuses of spare area > no clear hardware benefit (given the option area "floats" relative to the > UDP header, > which floats relative to the IPv6 header TLV chain, and given it may not = be > word aligned) > no clear benefit regarding packet errors or other spare area uses > (both require either CS works or TLV chain parses, neither of which is > likely for random errors or other misuses) > fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting > LITE/LITE+FRAG) > > - Optional CS vs. mandatory > motivated (AFAICT) by the desire to avoid processing packets with errors > (accidental or by others misusing the extra space) > optional is needed to correlate to lack of UDP checksum (for some types o= f > tunnels, e.g.) > mandatory also implies fixed (above), which incurs 2-6 bytes of overhead > > - option-area checksum details > size > 8 if TLV, 16 if fixed; no clear problem with either choice > algorithm > no clear issue with using minor mods (foldover for 8 bit, invert or not) > there are known dangers to using the complement of the sum > (such that the sum and data zero-out), as noted by the Partridge paper in > the 90s. > > - EOL vs option length field > length would have to be 2 bytes; EOL is an optional one byte (not needed = if > no spare area remains) > EOL thus saves up to 2 bytes when not needed (and it should generally not= be > needed at all) > allowing EOL (i.e., allowing remaining unused spare area) implies that > processing needs to stop at some point, > either based on a counter or the data seen (and given that a CS loads dat= a > into a register anyway, there's no clear performance win to either approa= ch) > EOL itself is patterned after the TCP option of the same name > and yes, leaving the spare area available for future use by other protoco= l > extensions is intended here > > - does CS end when EOL is seen? > yes, as currently specified > as noted above, leaving the spare are for future standards is a goal > > My conclusion is that all the choices above either fail to improve the > situation vs. our current proposal or increase overhead (or both). I don'= t > yet see a reason why any of them warrant a change vs. the existing approa= ch. > From nobody Thu May 24 19:59:53 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC92212D7F3 for ; Thu, 24 May 2018 19:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=erblichs@earthlink.net header.d=earthlink.net 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 gGmNI3A63fSG for ; Thu, 24 May 2018 19:59:48 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (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 3A71912D7F2 for ; Thu, 24 May 2018 19:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1527216967; bh=Pu02bt6r3Dwdk9EnoAcR3bSEjfsG/dHzw4yV 79U+0Lw=; h=Received:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; b=XPxL8NTYIx 2LbG+WcLjzOO0Gor1mQByexHkor+J9ZJdJ/ME7xcWTroT4KXkm4WodfW/4qJPAt3+h+ +s4Of1zJzOZy17cQJYvMSw95YlS7MRhxYxbb6kvkxS5BOayDAzX+tvdw2Hkb6OROJsl 8Rtc0mRH7HEW3i8OVYcfKfheUTEVEFzHAG2fdwZg96tsdBxXieo0YzFSe84zP5lykam i0ZmHrFz+or46Bd/7+OrFIYuD0tJtrS6egQdrNxZ1uvuXUZ2dEIiawbauinbLmXwR8q q8oALhnrtgzhOnVW8Jy5SOl5sLLxagtzXTbDTycqL5w21Is+fxx1pYIgBrD7vUDQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=eD88pLRrNkKVtMxbRZcOUBP6x92GB8GKN++j4g74cWGwN/wbRI+fXubS6XBVEfa6Jn9TtaQphJ5Fm7ZpVaO5cl24lWwwqXDZhHUOicTPc1Nam8yMfLouTN2fzNtMalxEKUlvLCw5CSp6RcxWPNPtWoABhIAgB5KeyippG/6k83xfqyTpuQg3fEEchbh0520pLHTyZVJO+QSkrDVGYCvQlz3mXM3vA5HVIAau6ylpBzYxIA69F1jMVbVpVtPhXFwrzkrrfQbAL6mjjA5qquk4NNCM7P1lc2CZaPMr3HlaOOCgFXbhhn1LT0zURgFBeWraE+MkMPd6vdVeT+BTROkWXQ==; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [24.6.250.120] (helo=[10.0.0.43]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4) (envelope-from ) id 1fM2tg-000Ec1-Ow; Thu, 24 May 2018 22:56:04 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mitchell Erblich In-Reply-To: Date: Thu, 24 May 2018 19:59:44 -0700 Cc: Tom Herbert , tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <0112B493-9AF7-4E2D-8417-F4CE857047CE@earthlink.net> References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3124) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7990e9674a28c827415c82900e0b27a73e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.6.250.120 Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 02:59:51 -0000 A possible DoS mitigation due to TLV processing, could be added with = wording such as: Any receiver/intermediate system processing a = packet with multiple TLVs SHOULD have the option to drop the packet = and/or quietly and/or respond with a packet processing time exceeded = error or packet exceeded the maximum number of unknown count of TLVs if = the processing of the packet exceeds a TLV processing time or the number = of unknown TLVs exceeds a maximum count. Any receiver/intermediate system should keep a = count of discarded packets and if the count exceeds a maximum local = value, be able to make decisions to black hole or make some other = decision against the packet=E2=80=99s believed source. Mitchell Erblich erblichs@earthlink.net > On May 24, 2018, at 2:08 PM, Joe Touch wrote: >=20 > Tom, >=20 > We've had the TLV discussion on other lists. >=20 > What I'm wondering here is why UDP options would need to be different = than TCP options - which are TLV exactly to allow the flexibility of = future evolution that have enabled quite a few TCP features beyond the = fixed header. >=20 > It would be useful to hear from others on this point as well. >=20 > Some clarifications: >=20 > - required options are those with a star (*) in sec 5; we can adjust = that list prior to final publication vs. the ones currently indicated >=20 > - "required' means 'required to implement' only; all options are = optional to use in general (they may be expected on a given association, = but that doesn't mandate order) >=20 > =20 > Joe >=20 > On 2018-05-24 12:52, Tom Herbert wrote: >=20 >> On Thu, May 24, 2018 at 11:43 AM, Joe Touch = wrote: >>> Hi, all, >>>=20 >>> I didn't see any comments on the following - it would be useful to = hear from >>> anyone on the list regarding the issues below so we can run a rev on = the doc >>> and pin these things down. >>>=20 >>> So far I've heard from only two parties - I'd appreciate both them = and >>> anyone else providing a very brief list of positions on these... >>>=20 >> Joe, >>=20 >> One of the problems with TLVs in a datapath protocol is that they can >> too easily be used for DOS attack. This is especially true in the = case >> that unkown TLV types are be ignored by a receiver and there is no >> reasonable protocol limit to the number of TLVs can be put into a >> packet. Both of these conditions seem to be true for the UDP options. >> The attack is simple, just fill up a packet with tiny TLVs with >> unknown types to the receiver. >>=20 >> A mitigation is described in the draft: >>=20 >> ">> Required options MUST come before other options. Each required >> option MUST NOT occur more than once (if they are repeated in a >> received segment, all except the first MUST be silently ignored)." >>=20 >> and >>=20 >> "Implementations concerned with the potential for this vulnerability >> MAY implement only the required options" >>=20 >> The first question I have to this is what are "required options". I >> don't see where this is defined. Also, required is ambiguous. I = assume >> the intent is that these are options that a receiver is required to >> implement-- but that could have other meanings, like options that a >> sender is required to send. This needs to be clarified. Also, if >> required options must appear first then that raises another question: >> what happens if a packet is received where required options follow >> non-required options. How does the receiver deal with this? >>=20 >> I'll assume for sake of argument that the options specified in the >> draft are required options in that sense that a receiver must >> understand these. So then my next question is how can any new = required >> options be added. Say that type 9 is defined as new security option >> that is considered a required option. How will deployed devices know >> that this is a required option (as opposed to one that isn't required >> and can be ignored)? Seems like the proper way to deal with would be >> to steal a bit from the type field that indicates the receive = behavior >> if the type in unknown-- either ignore TLV or drop packet. This is >> similar to high order two bits of IPv6 option types (an option to = send >> an ICMP error might also be useful here). >>=20 >> But, even if the required options are handled, DOS is still a problem >> if an implementation wants to process even one non required option. = In >> that case it always needs to parse all the TLVs (i.e. it doesn't know >> where in the TLV list the option is that it's looking for). So this >> presents the implementor with an unpleasant tradeoff, implementing = any >> non-required options may mean allowing exposure to DOS attack. >>=20 >> BTW, this DOS attack issue comes up in other context. For DO and HBH >> options we added text to draft-ietf-6man-rfc6434-bis-08 that allows >> configurable limits on number of options (regardless of whether the >> options are "required"). If the limit is exceeded the packet is >> dropped. In Linux the default is to allow up to eight options, that's >> approximately based on the number of implemented options plus five. >>=20 >> Tom >>=20 >>=20 >>=20 >>=20 >>> Thanks, >>> Joe >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2018-03-04 14:39, Joe Touch wrote: >>>=20 >>> Hi, all, >>>=20 >>> IMO, we would benefit popping up a level to the list of issues and >>> summarizing our views. >>>=20 >>> Here's my attempt to do that. >>>=20 >>> Joe >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> Some assumptions: >>> a) overhead is useful to minimize (efficiency and may reduce or = avoid >>> fragmentation) >>> b) LITE capability must be preserved >>> c) LITE+FRAG capability must be preserved >>> d) this solution is not expected to outperform TCP (i.e., this is = not an >>> opportunity to redesign transport from scratch) >>>=20 >>> - TLV vs fixed header >>> motivated (AFAICT) by the desire to enable hardware optimization = and/or to >>> detect error/misuses of spare area >>> no clear hardware benefit (given the option area "floats" relative = to the >>> UDP header, >>> which floats relative to the IPv6 header TLV chain, and given it may = not be >>> word aligned) >>> no clear benefit regarding packet errors or other spare area uses >>> (both require either CS works or TLV chain parses, neither of which = is >>> likely for random errors or other misuses) >>> fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if = supporting >>> LITE/LITE+FRAG) >>>=20 >>> - Optional CS vs. mandatory >>> motivated (AFAICT) by the desire to avoid processing packets with = errors >>> (accidental or by others misusing the extra space) >>> optional is needed to correlate to lack of UDP checksum (for some = types of >>> tunnels, e.g.) >>> mandatory also implies fixed (above), which incurs 2-6 bytes of = overhead >>>=20 >>> - option-area checksum details >>> size >>> 8 if TLV, 16 if fixed; no clear problem with either choice >>> algorithm >>> no clear issue with using minor mods (foldover for 8 bit, invert or = not) >>> there are known dangers to using the complement of the sum >>> (such that the sum and data zero-out), as noted by the Partridge = paper in >>> the 90s. >>>=20 >>> - EOL vs option length field >>> length would have to be 2 bytes; EOL is an optional one byte (not = needed if >>> no spare area remains) >>> EOL thus saves up to 2 bytes when not needed (and it should = generally not be >>> needed at all) >>> allowing EOL (i.e., allowing remaining unused spare area) implies = that >>> processing needs to stop at some point, >>> either based on a counter or the data seen (and given that a CS = loads data >>> into a register anyway, there's no clear performance win to either = approach) >>> EOL itself is patterned after the TCP option of the same name >>> and yes, leaving the spare area available for future use by other = protocol >>> extensions is intended here >>>=20 >>> - does CS end when EOL is seen? >>> yes, as currently specified >>> as noted above, leaving the spare are for future standards is a goal >>>=20 >>> My conclusion is that all the choices above either fail to improve = the >>> situation vs. our current proposal or increase overhead (or both). I = don't >>> yet see a reason why any of them warrant a change vs. the existing = approach. >>>=20 From nobody Thu May 24 22:35:14 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C905712D892 for ; Thu, 24 May 2018 22:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 B8iS1wK6q-Zg for ; Thu, 24 May 2018 22:35:10 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 5F03B12D88C for ; Thu, 24 May 2018 22:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d5ArqV3A87weUemHzqBvep5y0/MNsj0k/dORAcJKqiM=; b=kHJ2M5KdPQXzC879Dj8TBOPCF qICDZd+L/VIE+JS8O0JYdAAdjeLluJ6ilMm+tRJh9aItOoUEzP+lvKpCixc/XUu2tAg2DxZ0whpWD siTEd1xmpjlGzQOEGoEs1z0T23fJZg2+7tJBKXjT3t6T49qqXye77NJx6H4KAFofXyKlRzvJyeP3L 3Mpr4fqpxH/K/fW+E8ZilFIb4+oT2Xjyfm6ybWkTvaswqifwIrRXrUBYYUMcTjuYe3Xup80qOfIGE 4hV34N7jG2L2rmMTIQbJWuNG7ubOV2Id1a1Id4JL7jImfaezIZBEM4naIMp08nSQyvjkEEqM65J4C ZGcF4auxw==; Received: from [::1] (port=56588 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fM5Nb-00451t-Vh; Fri, 25 May 2018 01:35:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a30506db3d1c373e785c95725d786ad1" Date: Thu, 24 May 2018 22:35:07 -0700 From: Joe Touch To: Tom Herbert Cc: tsvwg In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> Message-ID: X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 05:35:13 -0000 --=_a30506db3d1c373e785c95725d786ad1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-24 14:49, Tom Herbert wrote: > On Thu, May 24, 2018 at 2:08 PM, Joe Touch wrote: > >> Tom, >> >> We've had the TLV discussion on other lists. >> >> What I'm wondering here is why UDP options would need to be different than >> TCP options - which are TLV exactly to allow the flexibility of future >> evolution that have enabled quite a few TCP features beyond the fixed >> header. > > They are different because: 1) TCP options are limited to forty bytes > in length 2) TCP options are negotiated These effectively are as well - although with soft state only. > 3) For a non-SYN packet, > options are only processed after the TCP connection is matched. That's roughly true here as well - due to the soft state property. The state isn't due to a handshake, but packets arriving at a host not listening to a port would not need to have their options processed either. > In > other words, there is no way to send unsolicited TCP packets with long > lists of TLVs to DOS a receiver (even if EDO were in use). UDP options > are much more like IPv6 DO and HBH options in this regard. Perhaps, but a host can easily just decide not to process options sequences that are too long - just as they can do so to SYN floods. >> It would be useful to hear from others on this point as well. >> >> Some clarifications: >> >> - required options are those with a star (*) in sec 5; we can adjust that >> list prior to final publication vs. the ones currently indicated > I see, these were not explicitly called out to be required options. > Probably need some more text about this. Also, does this mean that the > three options marked as required (or whatever others are added to the > required list before publication) are the only ones that will ever be > required in UDP options (see my point about problem in adding new > required options). They're the same as the only ones required for TCP - they MUST be implemented, which means both that transmitters MUST be able to send them and receivers MUST be able to interpret them. > I am a little suprised that ACS isn't required. This means that a > sender may go though all of the work to create the checksum, but a > receiver can simply ignore it. True - and it's up to the sender to decide to cease further transmission if desired. > That behavior is not typical of > checksums in IP protocols. It's exactly the behavior of *alternate* checksums, which are all optional. > Usually, the sender controls whether > checksum is set and receivers only accept packets with the checksum > present if it has been verified (like how UDP checksum is optional by > sender to set, but not optional for receiver to ignore if it's > non-zero, RFC1122). That wouldn't be true for any of the alternate checksums in TCP. >> - "required' means 'required to implement' only; all options are optional to >> use in general (they may be expected on a given association, but that >> doesn't mandate order) > > I think you mean required to be implemented and be recognized by a > receiver. Please clarify this in the next draft. And for the sender to transmit these. The list right now is based on the current minimum required set for TCP. If there's a clear case for making any of the others required, we can include them too - I'm hoping the set can be kept small enough not to be a burden for IoT devices. Joe > Tom > >> Joe >> >> On 2018-05-24 12:52, Tom Herbert wrote: >> >> On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: >> >> Hi, all, >> >> I didn't see any comments on the following - it would be useful to hear from >> anyone on the list regarding the issues below so we can run a rev on the doc >> and pin these things down. >> >> So far I've heard from only two parties - I'd appreciate both them and >> anyone else providing a very brief list of positions on these... >> >> Joe, >> >> One of the problems with TLVs in a datapath protocol is that they can >> too easily be used for DOS attack. This is especially true in the case >> that unkown TLV types are be ignored by a receiver and there is no >> reasonable protocol limit to the number of TLVs can be put into a >> packet. Both of these conditions seem to be true for the UDP options. >> The attack is simple, just fill up a packet with tiny TLVs with >> unknown types to the receiver. >> >> A mitigation is described in the draft: >> >> ">> Required options MUST come before other options. Each required >> option MUST NOT occur more than once (if they are repeated in a >> received segment, all except the first MUST be silently ignored)." >> >> and >> >> "Implementations concerned with the potential for this vulnerability >> MAY implement only the required options" >> >> The first question I have to this is what are "required options". I >> don't see where this is defined. Also, required is ambiguous. I assume >> the intent is that these are options that a receiver is required to >> implement-- but that could have other meanings, like options that a >> sender is required to send. This needs to be clarified. Also, if >> required options must appear first then that raises another question: >> what happens if a packet is received where required options follow >> non-required options. How does the receiver deal with this? >> >> I'll assume for sake of argument that the options specified in the >> draft are required options in that sense that a receiver must >> understand these. So then my next question is how can any new required >> options be added. Say that type 9 is defined as new security option >> that is considered a required option. How will deployed devices know >> that this is a required option (as opposed to one that isn't required >> and can be ignored)? Seems like the proper way to deal with would be >> to steal a bit from the type field that indicates the receive behavior >> if the type in unknown-- either ignore TLV or drop packet. This is >> similar to high order two bits of IPv6 option types (an option to send >> an ICMP error might also be useful here). >> >> But, even if the required options are handled, DOS is still a problem >> if an implementation wants to process even one non required option. In >> that case it always needs to parse all the TLVs (i.e. it doesn't know >> where in the TLV list the option is that it's looking for). So this >> presents the implementor with an unpleasant tradeoff, implementing any >> non-required options may mean allowing exposure to DOS attack. >> >> BTW, this DOS attack issue comes up in other context. For DO and HBH >> options we added text to draft-ietf-6man-rfc6434-bis-08 that allows >> configurable limits on number of options (regardless of whether the >> options are "required"). If the limit is exceeded the packet is >> dropped. In Linux the default is to allow up to eight options, that's >> approximately based on the number of implemented options plus five. >> >> Tom >> >> Thanks, >> Joe >> >> On 2018-03-04 14:39, Joe Touch wrote: >> >> Hi, all, >> >> IMO, we would benefit popping up a level to the list of issues and >> summarizing our views. >> >> Here's my attempt to do that. >> >> Joe >> >> ------ >> >> Some assumptions: >> a) overhead is useful to minimize (efficiency and may reduce or avoid >> fragmentation) >> b) LITE capability must be preserved >> c) LITE+FRAG capability must be preserved >> d) this solution is not expected to outperform TCP (i.e., this is not an >> opportunity to redesign transport from scratch) >> >> - TLV vs fixed header >> motivated (AFAICT) by the desire to enable hardware optimization and/or to >> detect error/misuses of spare area >> no clear hardware benefit (given the option area "floats" relative to the >> UDP header, >> which floats relative to the IPv6 header TLV chain, and given it may not be >> word aligned) >> no clear benefit regarding packet errors or other spare area uses >> (both require either CS works or TLV chain parses, neither of which is >> likely for random errors or other misuses) >> fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting >> LITE/LITE+FRAG) >> >> - Optional CS vs. mandatory >> motivated (AFAICT) by the desire to avoid processing packets with errors >> (accidental or by others misusing the extra space) >> optional is needed to correlate to lack of UDP checksum (for some types of >> tunnels, e.g.) >> mandatory also implies fixed (above), which incurs 2-6 bytes of overhead >> >> - option-area checksum details >> size >> 8 if TLV, 16 if fixed; no clear problem with either choice >> algorithm >> no clear issue with using minor mods (foldover for 8 bit, invert or not) >> there are known dangers to using the complement of the sum >> (such that the sum and data zero-out), as noted by the Partridge paper in >> the 90s. >> >> - EOL vs option length field >> length would have to be 2 bytes; EOL is an optional one byte (not needed if >> no spare area remains) >> EOL thus saves up to 2 bytes when not needed (and it should generally not be >> needed at all) >> allowing EOL (i.e., allowing remaining unused spare area) implies that >> processing needs to stop at some point, >> either based on a counter or the data seen (and given that a CS loads data >> into a register anyway, there's no clear performance win to either approach) >> EOL itself is patterned after the TCP option of the same name >> and yes, leaving the spare area available for future use by other protocol >> extensions is intended here >> >> - does CS end when EOL is seen? >> yes, as currently specified >> as noted above, leaving the spare are for future standards is a goal >> >> My conclusion is that all the choices above either fail to improve the >> situation vs. our current proposal or increase overhead (or both). I don't >> yet see a reason why any of them warrant a change vs. the existing approach. --=_a30506db3d1c373e785c95725d786ad1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2018-05-24 14:49, Tom Herbert wrote:

= On Thu, May 24, 2018 at 2:08 PM, Joe Touch <touch@strayalpha.com> wrote:
Tom,

We've had the TLV discussion on other= lists.

What I'm wondering here is why UDP options would need t= o be different than
TCP options - which are TLV exactly to allow the = flexibility of future
evolution that have enabled quite a few TCP fea= tures beyond the fixed
header.

They are different because: 1) TCP options are limited to forty byte= s
in length 2) TCP options are negotiated
=  
= These effectively are as well - although with soft state only.
=  
= 3) For a non-SYN packet,
options are only processed after the TCP con= nection is matched.
=  
= That's roughly true here as well - due to the soft state property. The= state isn't due to a handshake, but packets arriving at a host not listeni= ng to a port would not need to have their options processed either.
=  
=  
= In
other words, there is no way to send unsolicited TCP packets with = long
lists of TLVs to DOS a receiver (even if EDO were in use). UDP o= ptions
are much more like IPv6 DO and HBH options in this regard.
=  
= Perhaps, but a host can easily just decide not to process options sequences= that are too long - just as they can do so to SYN floods.
=  
=

It would be useful to hear from others on this = point as well.

Some clarifications:

- required opti= ons are those with a star (*) in sec 5; we can adjust that
list prior= to final publication vs. the ones currently indicated

I see, these were not explicitly called out to be required options.
P= robably need some more text about this. Also, does this mean that the
= three options marked as required (or whatever others are added to the
required list before publication) are the only ones that will ever be
required in UDP options (see my point about problem in adding new
= required options).
=  
= They're the same as the only ones required for TCP - they MUST be implement= ed, which means both that transmitters MUST be able to send them and receiv= ers MUST be able to interpret them.
=  
= I am a little suprised that ACS isn't required. This means that a
sen= der may go though all of the work to create the checksum, but a
recei= ver can simply ignore it.
=  
= True - and it's up to the sender to decide to cease further transmission if= desired.
=  
= That behavior is not typical of
checksums in IP protocols.
=  
= It's exactly the behavior of *alternate* checksums, which are all optional= =2E
=  
= Usually, the sender controls whether
checksum is set and receivers on= ly accept packets with the checksum
present if it has been verified (= like how UDP checksum is optional by
sender to set, but not optional = for receiver to ignore if it's
non-zero, RFC1122).
=  
= That wouldn't be true for any of the alternate checksums in TCP.
=  
=
- "required' means 'required to implement' only; all o= ptions are optional to
use in general (they may be expected on a give= n association, but that
doesn't mandate order)

I think you mean required to be implemented and be recognized by a receiver. Please clarify this in the next draft.
=  
= And for the sender to transmit these.
=  
= The list right now is based on the current minimum required set for TCP. If= there's a clear case for making any of the others required, we can include= them too - I'm hoping the set can be kept small enough not to be a burden = for IoT devices.
=  
= Joe
=  
=

Tom




Joe

On 2018-05-24 12:52= , Tom Herbert wrote:

On Thu, May 24, 2018 at 11:43 AM, Joe Touc= h <touch@strayalpha.com> = wrote:

Hi, all,

I didn't see any comments on the fo= llowing - it would be useful to hear from
anyone on the list regardin= g the issues below so we can run a rev on the doc
and pin these thing= s down.

So far I've heard from only two parties - I'd appreciat= e both them and
anyone else providing a very brief list of positions = on these...

Joe,

One of the problems with TLVs in a= datapath protocol is that they can
too easily be used for DOS attack= =2E This is especially true in the case
that unkown TLV types are be = ignored by a receiver and there is no
reasonable protocol limit to th= e number of TLVs can be put into a
packet. Both of these conditions s= eem to be true for the UDP options.
The attack is simple, just fill u= p a packet with tiny TLVs with
unknown types to the receiver.
A mitigation is described in the draft:

 ">> Re= quired options MUST come before other options. Each required
option M= UST NOT occur more than once (if they are repeated in a
received segm= ent, all except the first MUST be silently ignored)."

and
=
"Implementations concerned with the potential for this vulnerability=
MAY implement only the required options"

The first quest= ion I have to this is what are "required options". I
don't see where = this is defined. Also, required is ambiguous. I assume
the intent is = that these are options that a receiver is required to
implement-- but= that could have other meanings, like options that a
sender is requir= ed to send. This needs to be clarified. Also, if
required options mus= t appear first then that raises another question:
what happens if a p= acket is received where required options follow
non-required options= =2E How does the receiver deal with this?

I'll assume for sake = of argument that the options specified in the
draft are required opti= ons in that sense that a receiver must
understand these. So then my n= ext question is how can any new required
options be added. Say that t= ype 9 is defined as new security option
that is considered a required= option. How will deployed devices know
that this is a required optio= n (as opposed to one that isn't required
and can be ignored)? Seems l= ike the proper  way to deal with would be
to steal a bit from th= e type field that indicates the receive behavior
if the type in unkno= wn-- either ignore TLV or drop packet. This is
similar to high order = two bits of IPv6 option types (an option to send
an ICMP error might = also be useful here).

But, even if the required options are han= dled, DOS is still a problem
if an implementation wants to process ev= en one non required option. In
that case it always needs to parse all= the TLVs (i.e. it doesn't know
where in the TLV list the option is t= hat it's looking for). So this
presents the implementor with an unple= asant tradeoff, implementing any
non-required options may mean allowi= ng exposure to DOS attack.

BTW, this DOS attack issue comes up = in other context. For DO and HBH
options we added text to draft-ietf-= 6man-rfc6434-bis-08 that allows
configurable limits on number of opti= ons (regardless of whether the
options are "required"). If the limit = is exceeded the packet is
dropped. In Linux the default is to allow u= p to eight options, that's
approximately based on the number of imple= mented options plus five.

Tom




Tha= nks,
Joe




On 2018-03-04 14:39, Joe Touch= wrote:

Hi, all,

IMO, we would benefit popping up a= level to the list of issues and
summarizing our views.

H= ere's my attempt to do that.

Joe

——&mda= sh;

Some assumptions:
a) overhead is useful to minimize (= efficiency and may reduce or avoid
fragmentation)
b) LITE capab= ility must be preserved
c) LITE+FRAG capability must be preserved
d) this solution is not expected to outperform TCP (i.e., this is not an=
opportunity to redesign transport from scratch)

- TLV vs= fixed header
motivated (AFAICT) by the desire to enable hardware opt= imization and/or to
detect error/misuses of spare area
no clear= hardware benefit (given the option area "floats" relative to the
UDP= header,
which floats relative to the IPv6 header TLV chain, and give= n it may not be
word aligned)
no clear benefit regarding packet= errors or other spare area uses
(both require either CS works or TLV= chain parses, neither of which is
likely for random errors or other = misuses)
fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 i= f supporting
LITE/LITE+FRAG)

- Optional CS vs. mandatory<= br /> motivated (AFAICT) by the desire to avoid processing packets with err= ors
(accidental or by others misusing the extra space)
optional= is needed to correlate to lack of UDP checksum (for some types of
tu= nnels, e.g.)
mandatory also implies fixed (above), which incurs 2-6 b= ytes of overhead

- option-area checksum details
size
8 if TLV, 16 if fixed; no clear problem with either choice
algorith= m
no clear issue with using minor mods (foldover for 8 bit, invert or= not)
there are known dangers to using the complement of the sum
(such that the sum and data zero-out), as noted by the Partridge paper in=
the 90s.

- EOL vs option length field
length would= have to be 2 bytes; EOL is an optional one byte (not needed if
no sp= are area remains)
EOL thus saves up to 2 bytes when not needed (and i= t should generally not be
needed at all)
allowing EOL (i.e., al= lowing remaining unused spare area) implies that
processing needs to = stop at some point,
either based on a counter or the data seen (and g= iven that a CS loads data
into a register anyway, there's no clear pe= rformance win to either approach)
EOL itself is patterned after the T= CP option of the same name
and yes, leaving the spare area available = for future use by other protocol
extensions is intended here
- does CS end when EOL is seen?
yes, as currently specified
= as noted above, leaving the spare are for future standards is a goal
=
My conclusion is that all the choices above either fail to improve t= he
situation vs. our current proposal or increase overhead (or both)= =2E I don't
yet see a reason why any of them warrant a change vs. the= existing approach.

--=_a30506db3d1c373e785c95725d786ad1-- From nobody Fri May 25 00:50:46 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8444120454 for ; Fri, 25 May 2018 00:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 TZJG0zyck7oM for ; Fri, 25 May 2018 00:50:40 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D27AB1201FA for ; Fri, 25 May 2018 00:50:39 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 86EA31B0010D; Fri, 25 May 2018 08:50:05 +0100 (BST) Message-ID: <5B07C02C.2070908@erg.abdn.ac.uk> Date: Fri, 25 May 2018 08:50:04 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mitchell Erblich CC: Joe Touch , tsvwg References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> <0112B493-9AF7-4E2D-8417-F4CE857047CE@earthlink.net> In-Reply-To: <0112B493-9AF7-4E2D-8417-F4CE857047CE@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 07:50:44 -0000 I'd encourage some thought on TLV processing and DOS vulnerabilities as a separate security considerations subsection. I'd suggest this topic appears enough in transport design to justify a separate heading to assure readers of the safety of the approach. Since UDP provides a datagram service, the app (or the stack/path) can silently discard any data. I think this means we can think a little about how this should best now be handled. Is it the case that option and the datagram payload share the same fate? i.e. if the option part is not processed - then the datagram payload is not forwarded to the App? - This could simplify any probing by an endpoint to understand if an option is supported and will also avoid unexpected behaviours when any DDOS mechanism kicks-in and starts not processing options. If the API discards the entire datagram, it then behaves just as any IP-level policer would. - I also think it may perhaps be OK to separately log these discards (where rate-limiting permits), counting them as received at the transport but not forwarded to the App. I was assuming from what is written below that the decision about how to respond would be at the application level, or do you think the stack would have enough information to implement this sort of function? Gorry On 25/05/2018, 03:59, Mitchell Erblich wrote: > A possible DoS mitigation due to TLV processing, could be added with wording such as: > > Any receiver/intermediate system processing a packet with multiple TLVs SHOULD have the option to drop the packet and/or quietly and/or respond with a packet processing time exceeded error or packet exceeded the maximum number of unknown count of TLVs if the processing of the packet exceeds a TLV processing time or the number of unknown TLVs exceeds a maximum count. > > Any receiver/intermediate system should keep a count of discarded packets and if the count exceeds a maximum local value, be able to make decisions to black hole or make some other decision against the packet’s believed source. > > Mitchell Erblich > erblichs@earthlink.net > > > >> On May 24, 2018, at 2:08 PM, Joe Touch wrote: >> >> Tom, >> >> We've had the TLV discussion on other lists. >> >> What I'm wondering here is why UDP options would need to be different than TCP options - which are TLV exactly to allow the flexibility of future evolution that have enabled quite a few TCP features beyond the fixed header. >> >> It would be useful to hear from others on this point as well. >> >> Some clarifications: >> >> - required options are those with a star (*) in sec 5; we can adjust that list prior to final publication vs. the ones currently indicated >> >> - "required' means 'required to implement' only; all options are optional to use in general (they may be expected on a given association, but that doesn't mandate order) >> >> >> Joe >> >> On 2018-05-24 12:52, Tom Herbert wrote: >> >>> On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: >>>> Hi, all, >>>> >>>> I didn't see any comments on the following - it would be useful to hear from >>>> anyone on the list regarding the issues below so we can run a rev on the doc >>>> and pin these things down. >>>> >>>> So far I've heard from only two parties - I'd appreciate both them and >>>> anyone else providing a very brief list of positions on these... >>>> >>> Joe, >>> >>> One of the problems with TLVs in a datapath protocol is that they can >>> too easily be used for DOS attack. This is especially true in the case >>> that unkown TLV types are be ignored by a receiver and there is no >>> reasonable protocol limit to the number of TLVs can be put into a >>> packet. Both of these conditions seem to be true for the UDP options. >>> The attack is simple, just fill up a packet with tiny TLVs with >>> unknown types to the receiver. >>> >>> A mitigation is described in the draft: >>> >>> ">> Required options MUST come before other options. Each required >>> option MUST NOT occur more than once (if they are repeated in a >>> received segment, all except the first MUST be silently ignored)." >>> >>> and >>> >>> "Implementations concerned with the potential for this vulnerability >>> MAY implement only the required options" >>> >>> The first question I have to this is what are "required options". I >>> don't see where this is defined. Also, required is ambiguous. I assume >>> the intent is that these are options that a receiver is required to >>> implement-- but that could have other meanings, like options that a >>> sender is required to send. This needs to be clarified. Also, if >>> required options must appear first then that raises another question: >>> what happens if a packet is received where required options follow >>> non-required options. How does the receiver deal with this? >>> >>> I'll assume for sake of argument that the options specified in the >>> draft are required options in that sense that a receiver must >>> understand these. So then my next question is how can any new required >>> options be added. Say that type 9 is defined as new security option >>> that is considered a required option. How will deployed devices know >>> that this is a required option (as opposed to one that isn't required >>> and can be ignored)? Seems like the proper way to deal with would be >>> to steal a bit from the type field that indicates the receive behavior >>> if the type in unknown-- either ignore TLV or drop packet. This is >>> similar to high order two bits of IPv6 option types (an option to send >>> an ICMP error might also be useful here). >>> >>> But, even if the required options are handled, DOS is still a problem >>> if an implementation wants to process even one non required option. In >>> that case it always needs to parse all the TLVs (i.e. it doesn't know >>> where in the TLV list the option is that it's looking for). So this >>> presents the implementor with an unpleasant tradeoff, implementing any >>> non-required options may mean allowing exposure to DOS attack. >>> >>> BTW, this DOS attack issue comes up in other context. For DO and HBH >>> options we added text to draft-ietf-6man-rfc6434-bis-08 that allows >>> configurable limits on number of options (regardless of whether the >>> options are "required"). If the limit is exceeded the packet is >>> dropped. In Linux the default is to allow up to eight options, that's >>> approximately based on the number of implemented options plus five. >>> >>> Tom >>> >>> >>> >>> >>>> Thanks, >>>> Joe >>>> >>>> >>>> >>>> >>>> On 2018-03-04 14:39, Joe Touch wrote: >>>> >>>> Hi, all, >>>> >>>> IMO, we would benefit popping up a level to the list of issues and >>>> summarizing our views. >>>> >>>> Here's my attempt to do that. >>>> >>>> Joe >>>> >>>> ——— >>>> >>>> Some assumptions: >>>> a) overhead is useful to minimize (efficiency and may reduce or avoid >>>> fragmentation) >>>> b) LITE capability must be preserved >>>> c) LITE+FRAG capability must be preserved >>>> d) this solution is not expected to outperform TCP (i.e., this is not an >>>> opportunity to redesign transport from scratch) >>>> >>>> - TLV vs fixed header >>>> motivated (AFAICT) by the desire to enable hardware optimization and/or to >>>> detect error/misuses of spare area >>>> no clear hardware benefit (given the option area "floats" relative to the >>>> UDP header, >>>> which floats relative to the IPv6 header TLV chain, and given it may not be >>>> word aligned) >>>> no clear benefit regarding packet errors or other spare area uses >>>> (both require either CS works or TLV chain parses, neither of which is >>>> likely for random errors or other misuses) >>>> fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting >>>> LITE/LITE+FRAG) >>>> >>>> - Optional CS vs. mandatory >>>> motivated (AFAICT) by the desire to avoid processing packets with errors >>>> (accidental or by others misusing the extra space) >>>> optional is needed to correlate to lack of UDP checksum (for some types of >>>> tunnels, e.g.) >>>> mandatory also implies fixed (above), which incurs 2-6 bytes of overhead >>>> >>>> - option-area checksum details >>>> size >>>> 8 if TLV, 16 if fixed; no clear problem with either choice >>>> algorithm >>>> no clear issue with using minor mods (foldover for 8 bit, invert or not) >>>> there are known dangers to using the complement of the sum >>>> (such that the sum and data zero-out), as noted by the Partridge paper in >>>> the 90s. >>>> >>>> - EOL vs option length field >>>> length would have to be 2 bytes; EOL is an optional one byte (not needed if >>>> no spare area remains) >>>> EOL thus saves up to 2 bytes when not needed (and it should generally not be >>>> needed at all) >>>> allowing EOL (i.e., allowing remaining unused spare area) implies that >>>> processing needs to stop at some point, >>>> either based on a counter or the data seen (and given that a CS loads data >>>> into a register anyway, there's no clear performance win to either approach) >>>> EOL itself is patterned after the TCP option of the same name >>>> and yes, leaving the spare area available for future use by other protocol >>>> extensions is intended here >>>> >>>> - does CS end when EOL is seen? >>>> yes, as currently specified >>>> as noted above, leaving the spare are for future standards is a goal >>>> >>>> My conclusion is that all the choices above either fail to improve the >>>> situation vs. our current proposal or increase overhead (or both). I don't >>>> yet see a reason why any of them warrant a change vs. the existing approach. >>>> From nobody Fri May 25 07:36:57 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B0312DA1D for ; Fri, 25 May 2018 07:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 QDvw_VSINbkD for ; Fri, 25 May 2018 07:36:53 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508C012E051 for ; Fri, 25 May 2018 07:36:52 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id EFD0AF7C6D for ; Fri, 25 May 2018 10:36:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=C6bn9aoYd049ocYSlmPuFY6FGu8=; b=gdCk5I NN4gTmMN9Xg92zZUeY8UDHFY/n7uP6ML2C5aSeWXTRSDovLUERLXrsaNE62nj5SE LKgWnxeRBg3HL3cBvuA5kJbJwkY7lIzSBjkE6RZcmg9+aLOzTLpEn3LZBZlCAKVv jNbg9wFjJzqzZbTncMCg+5euqGXxGWuHvK9lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=Nu7uCIvCRF9g41xU47vQi2Qxx2KqjWfZ y45AWxYXFlkKNfnbz3ZwJ08NIKZZj2mVekfpuhKhAr9KipiZbmInVHxScARhScPo v+nVeJUiqilGPFa7B+cv1XxeiHAr16mZRf7CaNkMv1A185cUJThDTzrLfh10ybt2 SQIgWTqeO9M= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E8148F7C6B for ; Fri, 25 May 2018 10:36:51 -0400 (EDT) Received: from mail-oi0-f54.google.com (unknown [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 7A46DF7C6A for ; Fri, 25 May 2018 10:36:51 -0400 (EDT) Received: by mail-oi0-f54.google.com with SMTP id e80-v6so4755388oig.11 for ; Fri, 25 May 2018 07:36:51 -0700 (PDT) X-Gm-Message-State: ALKqPwfksNjnCWUxTE0yzw3gEuZhnE0CODVZctuxiAlgZu9OwybCb+Jl QEDRdwb3AaT2cO3fABxV6R0w/siHr5jvRBZXqcE= X-Google-Smtp-Source: ADUXVKL83k1ghM0lqUxT2xvYz/YFNoOMnmqBh8mtsxe6gyyM0T3w1jqQ2kUSBmMIaIHC0WeFFLPDk18UhGPwFyzZVfw= X-Received: by 2002:aca:917:: with SMTP id 23-v6mr1515368oij.119.1527259010898; Fri, 25 May 2018 07:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:88c6:0:0:0:0:0 with HTTP; Fri, 25 May 2018 07:36:30 -0700 (PDT) In-Reply-To: <143e3d8b4d675e2830a561e5a95fef37@strayalpha.com> References: <143e3d8b4d675e2830a561e5a95fef37@strayalpha.com> From: "C. M. Heard" Date: Fri, 25 May 2018 07:36:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: Tom Jones , tsvwg Content-Type: multipart/alternative; boundary="000000000000d3228f056d08b2f8" X-Pobox-Relay-ID: 101E9280-6029-11E8-B8E1-44CE1968708C-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 14:36:55 -0000 --000000000000d3228f056d08b2f8 Content-Type: text/plain; charset="UTF-8" On Thu, May 24, 2018 at 11:33 AM, Joe Touch wrote: > ... > For 3 bytes or less, "SLIDE" > For 4 bytes, SLIDE is the same as SWAP > For more than 4 bytes, SWAP is more efficient than SLIDE (avoids a long > copy of the data) > > I don't think it's bad to have a special case for 3 or fewer bytes. > Agreed. --cmh > > --000000000000d3228f056d08b2f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000d3228f056d08b2f8-- From nobody Fri May 25 07:49:17 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7DD12E876 for ; Fri, 25 May 2018 07:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 vahEvEk-yq3N for ; Fri, 25 May 2018 07:49:07 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15F812EAA4 for ; Fri, 25 May 2018 07:49:06 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id 185-v6so4246337qkk.11 for ; Fri, 25 May 2018 07:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T0MbAZ5fRvJsTj7fASSacw37nTFAy77U3fuW2x9xle0=; b=QStdR4H+7O6WC/cAJln9QKRPHWNMbfS0hDKpk3jYT+5nzsWBST99WYpvTPDjR8TV1q kSW/65jmGmKyLWgdfDAVe6gNYp+WP04ls8S7np0qRCD20T/jWNgYJ6PdLnFfcq08tiIm GM9BSsygkGXR0Jk/2AN3KD0k9HAFFzO5ZIaYwPcDA/EPP0QAFYeG5cAwqu2sR9id4uYn WlNoEHyPRelMVJxzdxce4dYsOaeclOKFG7L063QzKi5/I49o7z1T7m/3OfpC4FnWuK8y +lF6WFFo7XvMaKmpcWnMzRF2XnRQgBx/rb1FiRXzLrbZW7u5Ee3ss4NRWGeAtn3yVdAu Xm5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T0MbAZ5fRvJsTj7fASSacw37nTFAy77U3fuW2x9xle0=; b=BLDx1F2c7ZwRtqZSa64BvauFgAdMBehd4xoIw2zbEnEtM4ra97wqNGV8f4nWW7g0B3 rr2WBnCg50jTtsVy5p531z2V/GSaRS/Aqs5e4vnXJIrXAdFLbXHWWP1Xakt5k6vWuCT0 SJ6SYgOWtG3UeoKqiyPLM6h4XJSfyiNJuf3WFJsz8Uj4x2oh6QoiG/PzS54vlBMJu/D3 p69ucZ8i2LzenuMpriRXavc/fjGbjDy7upn9oymjFZuJNIN5AMAVnKrQEfk+rZU9fazX bJvkncDBx9+61wy17kjlHC+auea8bLyjzxPGS3+TkfIZ/NLjWoCQK4o/M+dIsee7Hooh lBHA== X-Gm-Message-State: ALKqPwe7CB8ZPA6M+tKKWj5jC1grAraM747C7fw38wixpRxFsoqaxIeA alYE2VMbtk4cZ6LZzIui878ojRMfLPu23xQK6iTyWA== X-Google-Smtp-Source: ADUXVKKV3nO5KSfPNZi41mhiQABtMAfrWSOB5PG5ve0jDlgtsbC7xKLlpdJEli/yTRsLBFXQI4n6bTMmVbetIf18s58= X-Received: by 2002:a37:1807:: with SMTP id j7-v6mr2407079qkh.333.1527259745501; Fri, 25 May 2018 07:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:3042:0:0:0:0:0 with HTTP; Fri, 25 May 2018 07:49:04 -0700 (PDT) In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> From: Tom Herbert Date: Fri, 25 May 2018 07:49:04 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 14:49:16 -0000 On Thu, May 24, 2018 at 10:35 PM, Joe Touch wrote: > On 2018-05-24 14:49, Tom Herbert wrote: > > On Thu, May 24, 2018 at 2:08 PM, Joe Touch wrote: > > Tom, > > We've had the TLV discussion on other lists. > > What I'm wondering here is why UDP options would need to be different tha= n > TCP options - which are TLV exactly to allow the flexibility of future > evolution that have enabled quite a few TCP features beyond the fixed > header. > > > They are different because: 1) TCP options are limited to forty bytes > in length 2) TCP options are negotiated > > > These effectively are as well - although with soft state only. > > > 3) For a non-SYN packet, > options are only processed after the TCP connection is matched. > > > That's roughly true here as well - due to the soft state property. The st= ate > isn't due to a handshake, but packets arriving at a host not listening to= a > port would not need to have their options processed either. > > > > In > other words, there is no way to send unsolicited TCP packets with long > lists of TLVs to DOS a receiver (even if EDO were in use). UDP options > are much more like IPv6 DO and HBH options in this regard. > > > Perhaps, but a host can easily just decide not to process options sequenc= es > that are too long - just as they can do so to SYN floods. > > > > > It would be useful to hear from others on this point as well. > > Some clarifications: > > - required options are those with a star (*) in sec 5; we can adjust that > list prior to final publication vs. the ones currently indicated > > I see, these were not explicitly called out to be required options. > Probably need some more text about this. Also, does this mean that the > three options marked as required (or whatever others are added to the > required list before publication) are the only ones that will ever be > required in UDP options (see my point about problem in adding new > required options). > > > They're the same as the only ones required for TCP - they MUST be > implemented, which means both that transmitters MUST be able to send them > and receivers MUST be able to interpret them. > > > I am a little suprised that ACS isn't required. This means that a > sender may go though all of the work to create the checksum, but a > receiver can simply ignore it. > > > True - and it's up to the sender to decide to cease further transmission = if > desired. > > > That behavior is not typical of > checksums in IP protocols. > > > It's exactly the behavior of *alternate* checksums, which are all optiona= l. > > > Usually, the sender controls whether > checksum is set and receivers only accept packets with the checksum > present if it has been verified (like how UDP checksum is optional by > sender to set, but not optional for receiver to ignore if it's > non-zero, RFC1122). > > > That wouldn't be true for any of the alternate checksums in TCP. > > > > - "required' means 'required to implement' only; all options are optional= to > use in general (they may be expected on a given association, but that > doesn't mandate order) > > > I think you mean required to be implemented and be recognized by a > receiver. Please clarify this in the next draft. > > > And for the sender to transmit these. > > The list right now is based on the current minimum required set for TCP. = If > there's a clear case for making any of the others required, we can includ= e > them too - I'm hoping the set can be kept small enough not to be a burden > for IoT devices. > Joe, Checksum is not optional in TCP, it is a field in the fixed TCP header. The TCP checksum must always be set by the sender and validated by the receiver. This advantages of a required checksum are major reason why I still think there should be a fixed header preceeding the UDP options list. The header would contain a one byte slack space type, a one byte length, two byte one's complement checksum of the header and option list (coverage inidicated by length). Such a header allows other uses of the slack space, substantially decreases the probability of misinterpretation of random bits in the slack space as being UDP options (checksum, type, and length need to be correct), solves the the checksum type being corrupted problem, and eliminates the need for EOL option. Please consider adding this header. Tom > Joe > > > > > Tom > > > > > Joe > > On 2018-05-24 12:52, Tom Herbert wrote: > > On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: > > Hi, all, > > I didn't see any comments on the following - it would be useful to hear f= rom > anyone on the list regarding the issues below so we can run a rev on the = doc > and pin these things down. > > So far I've heard from only two parties - I'd appreciate both them and > anyone else providing a very brief list of positions on these... > > Joe, > > One of the problems with TLVs in a datapath protocol is that they can > too easily be used for DOS attack. This is especially true in the case > that unkown TLV types are be ignored by a receiver and there is no > reasonable protocol limit to the number of TLVs can be put into a > packet. Both of these conditions seem to be true for the UDP options. > The attack is simple, just fill up a packet with tiny TLVs with > unknown types to the receiver. > > A mitigation is described in the draft: > > ">> Required options MUST come before other options. Each required > option MUST NOT occur more than once (if they are repeated in a > received segment, all except the first MUST be silently ignored)." > > and > > "Implementations concerned with the potential for this vulnerability > MAY implement only the required options" > > The first question I have to this is what are "required options". I > don't see where this is defined. Also, required is ambiguous. I assume > the intent is that these are options that a receiver is required to > implement-- but that could have other meanings, like options that a > sender is required to send. This needs to be clarified. Also, if > required options must appear first then that raises another question: > what happens if a packet is received where required options follow > non-required options. How does the receiver deal with this? > > I'll assume for sake of argument that the options specified in the > draft are required options in that sense that a receiver must > understand these. So then my next question is how can any new required > options be added. Say that type 9 is defined as new security option > that is considered a required option. How will deployed devices know > that this is a required option (as opposed to one that isn't required > and can be ignored)? Seems like the proper way to deal with would be > to steal a bit from the type field that indicates the receive behavior > if the type in unknown-- either ignore TLV or drop packet. This is > similar to high order two bits of IPv6 option types (an option to send > an ICMP error might also be useful here). > > But, even if the required options are handled, DOS is still a problem > if an implementation wants to process even one non required option. In > that case it always needs to parse all the TLVs (i.e. it doesn't know > where in the TLV list the option is that it's looking for). So this > presents the implementor with an unpleasant tradeoff, implementing any > non-required options may mean allowing exposure to DOS attack. > > BTW, this DOS attack issue comes up in other context. For DO and HBH > options we added text to draft-ietf-6man-rfc6434-bis-08 that allows > configurable limits on number of options (regardless of whether the > options are "required"). If the limit is exceeded the packet is > dropped. In Linux the default is to allow up to eight options, that's > approximately based on the number of implemented options plus five. > > Tom > > > > > Thanks, > Joe > > > > > On 2018-03-04 14:39, Joe Touch wrote: > > Hi, all, > > IMO, we would benefit popping up a level to the list of issues and > summarizing our views. > > Here's my attempt to do that. > > Joe > > =E2=80=94=E2=80=94=E2=80=94 > > Some assumptions: > a) overhead is useful to minimize (efficiency and may reduce or avoid > fragmentation) > b) LITE capability must be preserved > c) LITE+FRAG capability must be preserved > d) this solution is not expected to outperform TCP (i.e., this is not an > opportunity to redesign transport from scratch) > > - TLV vs fixed header > motivated (AFAICT) by the desire to enable hardware optimization and/or t= o > detect error/misuses of spare area > no clear hardware benefit (given the option area "floats" relative to the > UDP header, > which floats relative to the IPv6 header TLV chain, and given it may not = be > word aligned) > no clear benefit regarding packet errors or other spare area uses > (both require either CS works or TLV chain parses, neither of which is > likely for random errors or other misuses) > fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting > LITE/LITE+FRAG) > > - Optional CS vs. mandatory > motivated (AFAICT) by the desire to avoid processing packets with errors > (accidental or by others misusing the extra space) > optional is needed to correlate to lack of UDP checksum (for some types o= f > tunnels, e.g.) > mandatory also implies fixed (above), which incurs 2-6 bytes of overhead > > - option-area checksum details > size > 8 if TLV, 16 if fixed; no clear problem with either choice > algorithm > no clear issue with using minor mods (foldover for 8 bit, invert or not) > there are known dangers to using the complement of the sum > (such that the sum and data zero-out), as noted by the Partridge paper in > the 90s. > > - EOL vs option length field > length would have to be 2 bytes; EOL is an optional one byte (not needed = if > no spare area remains) > EOL thus saves up to 2 bytes when not needed (and it should generally not= be > needed at all) > allowing EOL (i.e., allowing remaining unused spare area) implies that > processing needs to stop at some point, > either based on a counter or the data seen (and given that a CS loads dat= a > into a register anyway, there's no clear performance win to either approa= ch) > EOL itself is patterned after the TCP option of the same name > and yes, leaving the spare area available for future use by other protoco= l > extensions is intended here > > - does CS end when EOL is seen? > yes, as currently specified > as noted above, leaving the spare are for future standards is a goal > > My conclusion is that all the choices above either fail to improve the > situation vs. our current proposal or increase overhead (or both). I don'= t > yet see a reason why any of them warrant a change vs. the existing approa= ch. > From nobody Fri May 25 08:29:28 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF811271DF; Fri, 25 May 2018 08:29:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152726215947.12812.12449221818348815443@ietfa.amsl.com> Date: Fri, 25 May 2018 08:29:19 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-iana-dscp-registry-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 15:29:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC Author : Godred Fairhurst Filename : draft-ietf-tsvwg-iana-dscp-registry-06.txt Pages : 7 Date : 2018-05-25 Abstract: The Differentiated Services (Diffserv) architecture specifies use of a field in the IPv4 and IPv6 packet headers to carry Diffserv Codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the Codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-iana-dscp-registry-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-dscp-registry-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 25 09:01:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D161912DDD0 for ; Fri, 25 May 2018 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 TV7xq6L3UZMb for ; Fri, 25 May 2018 09:01:36 -0700 (PDT) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C7A12DA6D for ; Fri, 25 May 2018 09:01:36 -0700 (PDT) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F0F55D5A5B for ; Fri, 25 May 2018 12:01:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=LuaI2fkQJB9AB5gVIrBtoUsiw1U=; b=cWN+RI HIVeNjSsOVxQTT4iaCnUpXvofF9Zff8uriDgwyW5tA64axxa19EztdOvPx6YpDWD 3ypQjFQ1iIDfAPGuA1OdWfXAkfyiYZTOT/H5B7War21CvZEkoEshpipE/iYIsAwW EF+ISKDB1SPRACOQaqWsbt4BowExBFUeqQ5KE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=UnYC3/OgC7XK2r0T5mTmINPfaS2Hxr7m twrLqOkV7G75l2t3yNIqb1XbcmVwGeLP87GAuJHjPFZmZTe1cWDckaB2vs07061C cp/4eTpF9hygIRAjcZFVBJZMSnkmAm6YV2SEdvMOOTQ+5iVWqF9P6V0mRKOk6pWt pI1aNiJY9j8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id DCFECD5A5A for ; Fri, 25 May 2018 12:01:35 -0400 (EDT) Received: from mail-ot0-f169.google.com (unknown [74.125.82.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6943BD5A58 for ; Fri, 25 May 2018 12:01:35 -0400 (EDT) Received: by mail-ot0-f169.google.com with SMTP id n1-v6so6597367otf.7 for ; Fri, 25 May 2018 09:01:35 -0700 (PDT) X-Gm-Message-State: ALKqPwfmSYRzv+10PRDsMnXSrBo/2PRTaAxX1T2+ZfjE5qNqqUYS3Y58 iz7Dtj/oS52s3OEBxDh4/4z07EVo29Zdmn0Lxvs= X-Google-Smtp-Source: ADUXVKLXO00nl50amP5z0W0xZhUP0phA2FZdio7b9qIvNO+iWDgkw9N/Lk8a236I+/w/eyuGFtNG6wjPSyR8fWzkSKI= X-Received: by 2002:a9d:336c:: with SMTP id u41-v6mr1789004otd.259.1527264094825; Fri, 25 May 2018 09:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:88c6:0:0:0:0:0 with HTTP; Fri, 25 May 2018 09:01:14 -0700 (PDT) In-Reply-To: References: From: "C. M. Heard" Date: Fri, 25 May 2018 09:01:14 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="000000000000d9b1b7056d09e10c" X-Pobox-Relay-ID: E6608794-6034-11E8-B5A8-67830C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:01:39 -0000 --000000000000d9b1b7056d09e10c Content-Type: text/plain; charset="UTF-8" Hi Joe, Regarding this: On Thu, May 24, 2018 at 11:39 AM, Joe Touch wrote: > On 2018-05-06 10:23, C. M. Heard wrote: > > Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over > from a previous incarnation of the draft? > > > UDP options support a similar service to UDP-Lite by terminating the > UDP options with an EOL option. The additional data not covered by > the UDP checksum follows that EOL option, and is passed to the user > separately. The difference is that UDP-Lite provides the un- > checksummed user data to the application by default, whereas UDP > options can provide the same capability only for endpoints that are > negotiated in advance (i.e., by default, UDP options would silently > discard this non-checksummed data). Additionally, in UDP-Lite the > checksummed and non-checksummed payload components are adjacent, > whereas in UDP options they are separated by the option area - > which, minimally, must consist of at least one EOL option. > > > It seems to me that this should be rewritten, because the service in > question is now provided by the LITE option. > > > > This text is exactly explaining the difference between our LITE and > "UDP-Lite". I can clarify this, e.g.,: > > The UDP option LITE option supports a similar service to UDP-Lite.... > > Is there some part of this explanation of the differences that isn't > accurate? > The trouble with the above explanation (a) that is starts with an inaccurate description of how the LITE option works -- the unchecksummed data does NOT follow EOL in the surplus area -- and (b) it says that the checksummed and unchecksummed payload components are separated by the options -- which is not the case; the order, after processing the LITE option (slide/swap), is: UDP Header | checksummed payload data | unchecksummed payload data | options | trailing data following EOL I've highlighted the specific sentences that I think have issues, and I propose the following replacement paragraph: UDP options, via the LITE option, support a service similar to UDP-Lite. The main difference is that UDP-Lite supports carriage of non-checksummed user data between the endpoints by default, whereas UDP options can safely provide that service only between endpoints that negotiate that capability in advance -- an endpoint that does not implement UDP options will silently discard the non-checksummed user data, along with the UDP options themselves. Hope this helps. Mike Heard --000000000000d9b1b7056d09e10c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

Regarding= this:

On Th= u, May 24, 2018 at 11:39 AM, Joe Touch <touch@strayalpha.com> wrote:

On 2018-05-06 10:23, C. M. Heard wrote:

Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over f= rom a previous incarnation of the draft?
=C2=A0
   UDP options support a similar service to UDP-Lite by terminating th=
e
   UDP options with an EOL option. The additional data not covered by
   the UDP checksum follows that EOL option, and is passed to the user
   separately. The difference is that UDP-Lite provides the un-
   checksummed user data to the application by default, whereas UDP
   options can provide the same capability only for endpoints that are
   negotiated in advance (i.e., by default, UDP options would silently
   discard this non-checksummed data). Additionally, in UDP-Lite the
   checksummed and non-checksummed payload components are adjacent,
   whereas in UDP options they are separated by the option area -
   which, minimally, must consist of at least one EOL option.
=C2=A0
It seems to me that this should be rewritten, because the service in q= uestion is now provided by the LITE option.
=C2=A0
=C2=A0
This text is exactly explaining the difference between our LITE and &q= uot;UDP-Lite". I can clarify this, e.g.,:
=C2=A0
=C2=A0 =C2=A0 The UDP option LITE option supports a similar service to= UDP-Lite....
=C2=A0
Is there some part of this explanation of the differences that isn'= ;t accurate?

The trouble with = the above explanation (a) that is starts with an inaccurate description of = how the LITE option works -- the unchecksummed data does NOT follow EOL in = the surplus area -- and (b) it says that the checksummed and unchecksummed = payload components are separated by the options -- which is not the case; t= he order, after processing the LITE option (slide/swap), is:

UDP Hea= der | checksummed payload data | unchecksummed payload data | options | =C2= =A0trailing data following EOL

I've highlighted the specific sen= tences that I think have issues, and I propose the following replacement pa= ragraph:
=C2=A0
   UDP options, via the LITE option, support a =
service similar to
   UDP-Lite.  The main difference is that UDP-Lite supports carriage
   of non-checksummed user data between the endpoints by default,
   whereas UDP options can safely provide that service only between
   endpoints that negotiate that capability in advance -- an endpoint
=
   that does not implement UDP options will silently d=
iscard the
   non-checksummed user data, along with the UDP optio=
ns themselves.

Hope this helps.

=
Mike Heard
--000000000000d9b1b7056d09e10c-- From nobody Fri May 25 09:10:41 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2912DDD0 for ; Fri, 25 May 2018 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 C9lVPed_UJda for ; Fri, 25 May 2018 09:10:35 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 28DA212DB71 for ; Fri, 25 May 2018 09:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DShVSIPpKklv+ODsKJcXOpMeJhZBsEU/dv+72Jniawg=; b=6T3ZEWs5m8O5Byg2i02QOqj/d XiwVNABem2FRT2LLY0IDoRAfpe3DodYZ1rPX3mx2DZNsZ46QXk+ydJtxn7iqbIkiclKctLAA/kaDa gwVNNpBHZJaQiX0oC5TPbrTmpjLbF9L7ghoXL3Z6FKGywl1TL7drxFc0083pIQpnvJNxx1VxQjJjD 6DJN/v5BwsxykkkdCZkraq16y2mbQGmQze789yXArqUKBPxGSJVwNGNsmnAIRqoft7dwPh3AQUDaY oL44gdU9VJKyTIuBFvPAn7QWNXrB4H69xFPBZWxiG6fy+xdrbHs8cGpdQFXbk7+Ue8QQiy9EfakBr d6yC3AACw==; Received: from [::1] (port=52624 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fMFIX-004Hnr-95; Fri, 25 May 2018 12:10:34 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_fdf23e3adeec6ec610a699b8b1887af3" Date: Fri, 25 May 2018 09:10:33 -0700 From: Joe Touch To: Tom Herbert Cc: tsvwg In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> Message-ID: <8c3a04b0bc55fe0d0b08ae9d7681afcd@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:10:39 -0000 --=_fdf23e3adeec6ec610a699b8b1887af3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi, Tom, I think you're confusing ACS with OCS; ACS is the alternate checksum on the body. You've made your views on OCS clear; it would be useful to hear from others. Also, note that even if OCS were mandatory: a) it probably cannot come before LITE b) there's no need to include a length field with OCS per se; further, a one-byte length puts us back on the path where TCP ended up (of limiting option space). IF we include that, it would need to be two bytes Joe On 2018-05-25 07:49, Tom Herbert wrote: > Joe, > > Checksum is not optional in TCP, it is a field in the fixed TCP > header. The TCP checksum must always be set by the sender and > validated by the receiver. This advantages of a required checksum are > major reason why I still think there should be a fixed header > preceeding the UDP options list. The header would contain a one byte > slack space type, a one byte length, two byte one's complement > checksum of the header and option list (coverage inidicated by > length). Such a header allows other uses of the slack space, > substantially decreases the probability of misinterpretation of random > bits in the slack space as being UDP options (checksum, type, and > length need to be correct), solves the the checksum type being > corrupted problem, and eliminates the need for EOL option. Please > consider adding this header. > > Tom > >> Joe >> >> Tom >> >> Joe >> >> On 2018-05-24 12:52, Tom Herbert wrote: >> >> On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: >> >> Hi, all, >> >> I didn't see any comments on the following - it would be useful to hear from >> anyone on the list regarding the issues below so we can run a rev on the doc >> and pin these things down. >> >> So far I've heard from only two parties - I'd appreciate both them and >> anyone else providing a very brief list of positions on these... >> >> Joe, >> >> One of the problems with TLVs in a datapath protocol is that they can >> too easily be used for DOS attack. This is especially true in the case >> that unkown TLV types are be ignored by a receiver and there is no >> reasonable protocol limit to the number of TLVs can be put into a >> packet. Both of these conditions seem to be true for the UDP options. >> The attack is simple, just fill up a packet with tiny TLVs with >> unknown types to the receiver. >> >> A mitigation is described in the draft: >> >> ">> Required options MUST come before other options. Each required >> option MUST NOT occur more than once (if they are repeated in a >> received segment, all except the first MUST be silently ignored)." >> >> and >> >> "Implementations concerned with the potential for this vulnerability >> MAY implement only the required options" >> >> The first question I have to this is what are "required options". I >> don't see where this is defined. Also, required is ambiguous. I assume >> the intent is that these are options that a receiver is required to >> implement-- but that could have other meanings, like options that a >> sender is required to send. This needs to be clarified. Also, if >> required options must appear first then that raises another question: >> what happens if a packet is received where required options follow >> non-required options. How does the receiver deal with this? >> >> I'll assume for sake of argument that the options specified in the >> draft are required options in that sense that a receiver must >> understand these. So then my next question is how can any new required >> options be added. Say that type 9 is defined as new security option >> that is considered a required option. How will deployed devices know >> that this is a required option (as opposed to one that isn't required >> and can be ignored)? Seems like the proper way to deal with would be >> to steal a bit from the type field that indicates the receive behavior >> if the type in unknown-- either ignore TLV or drop packet. This is >> similar to high order two bits of IPv6 option types (an option to send >> an ICMP error might also be useful here). >> >> But, even if the required options are handled, DOS is still a problem >> if an implementation wants to process even one non required option. In >> that case it always needs to parse all the TLVs (i.e. it doesn't know >> where in the TLV list the option is that it's looking for). So this >> presents the implementor with an unpleasant tradeoff, implementing any >> non-required options may mean allowing exposure to DOS attack. >> >> BTW, this DOS attack issue comes up in other context. For DO and HBH >> options we added text to draft-ietf-6man-rfc6434-bis-08 that allows >> configurable limits on number of options (regardless of whether the >> options are "required"). If the limit is exceeded the packet is >> dropped. In Linux the default is to allow up to eight options, that's >> approximately based on the number of implemented options plus five. >> >> Tom >> >> Thanks, >> Joe >> >> On 2018-03-04 14:39, Joe Touch wrote: >> >> Hi, all, >> >> IMO, we would benefit popping up a level to the list of issues and >> summarizing our views. >> >> Here's my attempt to do that. >> >> Joe >> >> ------ >> >> Some assumptions: >> a) overhead is useful to minimize (efficiency and may reduce or avoid >> fragmentation) >> b) LITE capability must be preserved >> c) LITE+FRAG capability must be preserved >> d) this solution is not expected to outperform TCP (i.e., this is not an >> opportunity to redesign transport from scratch) >> >> - TLV vs fixed header >> motivated (AFAICT) by the desire to enable hardware optimization and/or to >> detect error/misuses of spare area >> no clear hardware benefit (given the option area "floats" relative to the >> UDP header, >> which floats relative to the IPv6 header TLV chain, and given it may not be >> word aligned) >> no clear benefit regarding packet errors or other spare area uses >> (both require either CS works or TLV chain parses, neither of which is >> likely for random errors or other misuses) >> fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting >> LITE/LITE+FRAG) >> >> - Optional CS vs. mandatory >> motivated (AFAICT) by the desire to avoid processing packets with errors >> (accidental or by others misusing the extra space) >> optional is needed to correlate to lack of UDP checksum (for some types of >> tunnels, e.g.) >> mandatory also implies fixed (above), which incurs 2-6 bytes of overhead >> >> - option-area checksum details >> size >> 8 if TLV, 16 if fixed; no clear problem with either choice >> algorithm >> no clear issue with using minor mods (foldover for 8 bit, invert or not) >> there are known dangers to using the complement of the sum >> (such that the sum and data zero-out), as noted by the Partridge paper in >> the 90s. >> >> - EOL vs option length field >> length would have to be 2 bytes; EOL is an optional one byte (not needed if >> no spare area remains) >> EOL thus saves up to 2 bytes when not needed (and it should generally not be >> needed at all) >> allowing EOL (i.e., allowing remaining unused spare area) implies that >> processing needs to stop at some point, >> either based on a counter or the data seen (and given that a CS loads data >> into a register anyway, there's no clear performance win to either approach) >> EOL itself is patterned after the TCP option of the same name >> and yes, leaving the spare area available for future use by other protocol >> extensions is intended here >> >> - does CS end when EOL is seen? >> yes, as currently specified >> as noted above, leaving the spare are for future standards is a goal >> >> My conclusion is that all the choices above either fail to improve the >> situation vs. our current proposal or increase overhead (or both). I don't >> yet see a reason why any of them warrant a change vs. the existing approach. --=_fdf23e3adeec6ec610a699b8b1887af3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi, Tom,

I think you're confusing ACS with OCS; ACS is the alternate checksum on = the body.

 

You've made your views on OCS clear; it would be useful to hear from oth= ers.

Also, note that even if OCS were mandatory:

a) it probably cannot come before LITE

b) there's no need to include a length field with OCS per se; further, a= one-byte length puts us back on the path where TCP ended up (of limit= ing option space). IF we include that, it would need to be two bytes

Joe

On 2018-05-25 07:49, Tom Herbert wrote:

= Joe,

Checksum is not optional in TCP, it is a field in the fixe= d TCP
header. The TCP checksum must always be set by the sender and validated by the receiver. This advantages of a required checksum are<= br /> major reason why I still think there should be a fixed header
p= receeding the UDP options list. The header would contain a one byte
s= lack space type, a one byte length, two byte one's complement
checksu= m of the header and option list (coverage inidicated by
length). Such= a header allows other uses of the slack space,
substantially decreas= es the probability of misinterpretation of random
bits in the slack s= pace as being UDP options (checksum, type, and
length need to be corr= ect), solves the the checksum type being
corrupted problem, and elimi= nates the need for EOL option. Please
consider adding this header.
Tom

Joe




Tom




Joe

On 2018-05-24 12:52, Tom Herbert wrote:
=
On Thu, May 24, 2018 at 11:43 AM, Joe Touch <touch@strayalpha.com> wrote:

Hi, all= ,

I didn't see any comments on the following - it would be usef= ul to hear from
anyone on the list regarding the issues below so we c= an run a rev on the doc
and pin these things down.

So far= I've heard from only two parties - I'd appreciate both them and
anyo= ne else providing a very brief list of positions on these...

Jo= e,

One of the problems with TLVs in a datapath protocol is that= they can
too easily be used for DOS attack. This is especially true = in the case
that unkown TLV types are be ignored by a receiver and th= ere is no
reasonable protocol limit to the number of TLVs can be put = into a
packet. Both of these conditions seem to be true for the UDP o= ptions.
The attack is simple, just fill up a packet with tiny TLVs wi= th
unknown types to the receiver.

A mitigation is describ= ed in the draft:

 ">> Required options MUST come bef= ore other options. Each required
option MUST NOT occur more than once= (if they are repeated in a
received segment, all except the first MU= ST be silently ignored)."

and

"Implementations conc= erned with the potential for this vulnerability
MAY implement only th= e required options"

The first question I have to this is what a= re "required options". I
don't see where this is defined. Also, requi= red is ambiguous. I assume
the intent is that these are options that = a receiver is required to
implement-- but that could have other meani= ngs, like options that a
sender is required to send. This needs to be= clarified. Also, if
required options must appear first then that rai= ses another question:
what happens if a packet is received where requ= ired options follow
non-required options. How does the receiver deal = with this?

I'll assume for sake of argument that the options sp= ecified in the
draft are required options in that sense that a receiv= er must
understand these. So then my next question is how can any new= required
options be added. Say that type 9 is defined as new securit= y option
that is considered a required option. How will deployed devi= ces know
that this is a required option (as opposed to one that isn't= required
and can be ignored)? Seems like the proper  way to dea= l with would be
to steal a bit from the type field that indicates the= receive behavior
if the type in unknown-- either ignore TLV or drop = packet. This is
similar to high order two bits of IPv6 option types (= an option to send
an ICMP error might also be useful here).

But, even if the required options are handled, DOS is still a problem if an implementation wants to process even one non required option. In<= br /> that case it always needs to parse all the TLVs (i.e. it doesn't know=
where in the TLV list the option is that it's looking for). So this<= br /> presents the implementor with an unpleasant tradeoff, implementing an= y
non-required options may mean allowing exposure to DOS attack.

BTW, this DOS attack issue comes up in other context. For DO and HB= H
options we added text to draft-ietf-6man-rfc6434-bis-08 that allows=
configurable limits on number of options (regardless of whether the<= br /> options are "required"). If the limit is exceeded the packet is
= dropped. In Linux the default is to allow up to eight options, that's
approximately based on the number of implemented options plus five.
=
Tom




Thanks,
Joe




On 2018-03-04 14:39, Joe Touch wrote:

Hi, all,
IMO, we would benefit popping up a level to the list of issues an= d
summarizing our views.

Here's my attempt to do that.
Joe

———

Some assumption= s:
a) overhead is useful to minimize (efficiency and may reduce or av= oid
fragmentation)
b) LITE capability must be preserved
c= ) LITE+FRAG capability must be preserved
d) this solution is not expe= cted to outperform TCP (i.e., this is not an
opportunity to redesign = transport from scratch)

- TLV vs fixed header
motivated (= AFAICT) by the desire to enable hardware optimization and/or to
detec= t error/misuses of spare area
no clear hardware benefit (given the op= tion area "floats" relative to the
UDP header,
which floats rel= ative to the IPv6 header TLV chain, and given it may not be
word alig= ned)
no clear benefit regarding packet errors or other spare area use= s
(both require either CS works or TLV chain parses, neither of which= is
likely for random errors or other misuses)
fixed wastes at = least 2 bytes if CS isn't used, (maybe 4-6 if supporting
LITE/LITE+FR= AG)

- Optional CS vs. mandatory
motivated (AFAICT) by the= desire to avoid processing packets with errors
(accidental or by oth= ers misusing the extra space)
optional is needed to correlate to lack= of UDP checksum (for some types of
tunnels, e.g.)
mandatory al= so implies fixed (above), which incurs 2-6 bytes of overhead

- = option-area checksum details
size
8 if TLV, 16 if fixed; no cle= ar problem with either choice
algorithm
no clear issue with usi= ng minor mods (foldover for 8 bit, invert or not)
there are known dan= gers to using the complement of the sum
(such that the sum and data z= ero-out), as noted by the Partridge paper in
the 90s.

- E= OL vs option length field
length would have to be 2 bytes; EOL is an = optional one byte (not needed if
no spare area remains)
EOL thu= s saves up to 2 bytes when not needed (and it should generally not be
= needed at all)
allowing EOL (i.e., allowing remaining unused spare a= rea) implies that
processing needs to stop at some point,
eithe= r based on a counter or the data seen (and given that a CS loads data
= into a register anyway, there's no clear performance win to either approac= h)
EOL itself is patterned after the TCP option of the same name
and yes, leaving the spare area available for future use by other protoco= l
extensions is intended here

- does CS end when EOL is s= een?
yes, as currently specified
as noted above, leaving the sp= are are for future standards is a goal

My conclusion is that al= l the choices above either fail to improve the
situation vs. our curr= ent proposal or increase overhead (or both). I don't
yet see a reason= why any of them warrant a change vs. the existing approach.

--=_fdf23e3adeec6ec610a699b8b1887af3-- From nobody Fri May 25 09:19:59 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23C412DDD0 for ; Fri, 25 May 2018 09:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Yj9BhWb9XAPg for ; Fri, 25 May 2018 09:19:55 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FAB12DA4E for ; Fri, 25 May 2018 09:19:55 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id g13-v6so7221424qth.8 for ; Fri, 25 May 2018 09:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2pLdnWXBqEYyOf31MU+rZo4SSlQU7hvp6kTBherFlsM=; b=sBAYpRSeaQc7TRLxy1EVNgFy0OkmhE5KQ1330IgvY7NFCstv+pJc42KGOgJet4bMOS wTjgcUrt9EbkZbjbl+OlfqWkWnu2FxLQQFjcVS8F3Nt9XiqvEssBdugwWmMfeLXVb3Jx ZKm8QRRsG7Y4qGrg8pBp5gtURTp46oUUKlLhMxuqtxpxk3FF0iSxUehRLPEsyyIG05D4 S0Baonee1gWFf50o1irlaWnLtrYwWpYbskTzySIzJ14a1dekRlJu1P8QOrfnwKuxPkuJ 7sWa73HxfUm3JtOVid7zFDac8VzztDbgW4070879ufP21IPWcbjdlYfTVeqJ4syHk+90 A/VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2pLdnWXBqEYyOf31MU+rZo4SSlQU7hvp6kTBherFlsM=; b=gwVwVwngd4msTS7yN9jakbl7Wn0pm4uRjx85t8lkjUEEfldrxuDBFm7sSawuABKR0m HIeZJvWOX8/wKtqJiWKeiM3XYfigE+ka+HZ7SOW/W4HZQqxTI5NnWXkqxo9V7KwyycgD 62N4gVrgMvuplUU3yMzQbXL4TZ8PDubh0luOWWKM9SMMBEyuxZm5eNkWfU9uo+yXfDUR 5J90Mq5vpkPqbvn1M6YvXNx0t10g6O/H+sqVGiQacJkRP2SSVimhUlN5q//L/p1NSaN6 dOmw2HLwgQNGY8iBWx7E8QtjfJy4p69IfAZ3s8XYl4M71yoSiAi7OXkZefuwJWFg9i1H HPIg== X-Gm-Message-State: ALKqPwd81tCBJK3BoC8NbmM5obninemgmnxRh0p0l6tLlhvbduzDDN9o N1oofW3izlcskMKERy1CDf1sHjdT+HtgbSYSpXkHfQ== X-Google-Smtp-Source: ADUXVKLEDnDq7f9ewrux1HfhCslslHVWh9EZzR4ktX8481jzaoPzSKBUXqvWd4uVaHWv8ZwUz0YOhhb42tVPyNjO6w0= X-Received: by 2002:ac8:18c8:: with SMTP id o8-v6mr2748705qtk.400.1527265193932; Fri, 25 May 2018 09:19:53 -0700 (PDT) MIME-Version: 1.0 References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> <8c3a04b0bc55fe0d0b08ae9d7681afcd@strayalpha.com> In-Reply-To: <8c3a04b0bc55fe0d0b08ae9d7681afcd@strayalpha.com> From: Tom Herbert Date: Fri, 25 May 2018 09:18:41 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: multipart/alternative; boundary="0000000000005ccf14056d0a239e" Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:19:58 -0000 --0000000000005ccf14056d0a239e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 25, 2018, 9:10 AM Joe Touch wrote: > Hi, Tom, > > I think you're confusing ACS with OCS; ACS is the alternate checksum on > the body. > > > You've made your views on OCS clear; it would be useful to hear from > others. > > Also, note that even if OCS were mandatory: > > a) it probably cannot come before LITE > > b) there's no need to include a length field with OCS per se; further, a > one-byte length puts us back on the path where TCP ended up (of limiting > option space). IF we include that, it would need to be two bytes > A one byte length field would allow 256 bytes of options, same as IPv6 DO and HBH. That's already almost 20% of normal Ethernet MTU, I'm very doubtful there would ever be a practical use for more bytes in options (except for DOS!). Tom Joe > > On 2018-05-25 07:49, Tom Herbert wrote: > > Joe, > > Checksum is not optional in TCP, it is a field in the fixed TCP > header. The TCP checksum must always be set by the sender and > validated by the receiver. This advantages of a required checksum are > major reason why I still think there should be a fixed header > preceeding the UDP options list. The header would contain a one byte > slack space type, a one byte length, two byte one's complement > checksum of the header and option list (coverage inidicated by > length). Such a header allows other uses of the slack space, > substantially decreases the probability of misinterpretation of random > bits in the slack space as being UDP options (checksum, type, and > length need to be correct), solves the the checksum type being > corrupted problem, and eliminates the need for EOL option. Please > consider adding this header. > > Tom > > Joe > > > > > Tom > > > > > Joe > > On 2018-05-24 12:52, Tom Herbert wrote: > > On Thu, May 24, 2018 at 11:43 AM, Joe Touch wrote: > > Hi, all, > > I didn't see any comments on the following - it would be useful to hear > from > anyone on the list regarding the issues below so we can run a rev on the > doc > and pin these things down. > > So far I've heard from only two parties - I'd appreciate both them and > anyone else providing a very brief list of positions on these... > > Joe, > > One of the problems with TLVs in a datapath protocol is that they can > too easily be used for DOS attack. This is especially true in the case > that unkown TLV types are be ignored by a receiver and there is no > reasonable protocol limit to the number of TLVs can be put into a > packet. Both of these conditions seem to be true for the UDP options. > The attack is simple, just fill up a packet with tiny TLVs with > unknown types to the receiver. > > A mitigation is described in the draft: > > ">> Required options MUST come before other options. Each required > option MUST NOT occur more than once (if they are repeated in a > received segment, all except the first MUST be silently ignored)." > > and > > "Implementations concerned with the potential for this vulnerability > MAY implement only the required options" > > The first question I have to this is what are "required options". I > don't see where this is defined. Also, required is ambiguous. I assume > the intent is that these are options that a receiver is required to > implement-- but that could have other meanings, like options that a > sender is required to send. This needs to be clarified. Also, if > required options must appear first then that raises another question: > what happens if a packet is received where required options follow > non-required options. How does the receiver deal with this? > > I'll assume for sake of argument that the options specified in the > draft are required options in that sense that a receiver must > understand these. So then my next question is how can any new required > options be added. Say that type 9 is defined as new security option > that is considered a required option. How will deployed devices know > that this is a required option (as opposed to one that isn't required > and can be ignored)? Seems like the proper way to deal with would be > to steal a bit from the type field that indicates the receive behavior > if the type in unknown-- either ignore TLV or drop packet. This is > similar to high order two bits of IPv6 option types (an option to send > an ICMP error might also be useful here). > > But, even if the required options are handled, DOS is still a problem > if an implementation wants to process even one non required option. In > that case it always needs to parse all the TLVs (i.e. it doesn't know > where in the TLV list the option is that it's looking for). So this > presents the implementor with an unpleasant tradeoff, implementing any > non-required options may mean allowing exposure to DOS attack. > > BTW, this DOS attack issue comes up in other context. For DO and HBH > options we added text to draft-ietf-6man-rfc6434-bis-08 that allows > configurable limits on number of options (regardless of whether the > options are "required"). If the limit is exceeded the packet is > dropped. In Linux the default is to allow up to eight options, that's > approximately based on the number of implemented options plus five. > > Tom > > > > > Thanks, > Joe > > > > > On 2018-03-04 14:39, Joe Touch wrote: > > Hi, all, > > IMO, we would benefit popping up a level to the list of issues and > summarizing our views. > > Here's my attempt to do that. > > Joe > > =E2=80=94=E2=80=94=E2=80=94 > > Some assumptions: > a) overhead is useful to minimize (efficiency and may reduce or avoid > fragmentation) > b) LITE capability must be preserved > c) LITE+FRAG capability must be preserved > d) this solution is not expected to outperform TCP (i.e., this is not an > opportunity to redesign transport from scratch) > > - TLV vs fixed header > motivated (AFAICT) by the desire to enable hardware optimization and/or t= o > detect error/misuses of spare area > no clear hardware benefit (given the option area "floats" relative to the > UDP header, > which floats relative to the IPv6 header TLV chain, and given it may not = be > word aligned) > no clear benefit regarding packet errors or other spare area uses > (both require either CS works or TLV chain parses, neither of which is > likely for random errors or other misuses) > fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting > LITE/LITE+FRAG) > > - Optional CS vs. mandatory > motivated (AFAICT) by the desire to avoid processing packets with errors > (accidental or by others misusing the extra space) > optional is needed to correlate to lack of UDP checksum (for some types o= f > tunnels, e.g.) > mandatory also implies fixed (above), which incurs 2-6 bytes of overhead > > - option-area checksum details > size > 8 if TLV, 16 if fixed; no clear problem with either choice > algorithm > no clear issue with using minor mods (foldover for 8 bit, invert or not) > there are known dangers to using the complement of the sum > (such that the sum and data zero-out), as noted by the Partridge paper in > the 90s. > > - EOL vs option length field > length would have to be 2 bytes; EOL is an optional one byte (not needed = if > no spare area remains) > EOL thus saves up to 2 bytes when not needed (and it should generally not > be > needed at all) > allowing EOL (i.e., allowing remaining unused spare area) implies that > processing needs to stop at some point, > either based on a counter or the data seen (and given that a CS loads dat= a > into a register anyway, there's no clear performance win to either > approach) > EOL itself is patterned after the TCP option of the same name > and yes, leaving the spare area available for future use by other protoco= l > extensions is intended here > > - does CS end when EOL is seen? > yes, as currently specified > as noted above, leaving the spare are for future standards is a goal > > My conclusion is that all the choices above either fail to improve the > situation vs. our current proposal or increase overhead (or both). I don'= t > yet see a reason why any of them warrant a change vs. the existing > approach. > > --0000000000005ccf14056d0a239e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Fri, May 25, 2018, 9:10 AM Joe Touch <touch@strayalpha.com> wrote:

Hi, Tom,

I think you're confusing ACS with OCS; ACS is the alternate checksum= on the body.

=C2=A0

You've made your views on OCS clear; it would be useful to hear from= others.

Also, note that even if OCS were mandatory:

a) it probably cannot come before LITE

b) there's no need to include a length field with OCS per se; furthe= r, a one-byte length=C2=A0puts us back on the path where TCP ended up (of l= imiting option space). IF we include that, it would need to be two bytes


A one byte length field would allow 256 bytes of options, same as IPv6 D= O and HBH. That's already almost 20% of normal Ethernet MTU, I'm ve= ry doubtful there would ever be a practical use for more bytes in options (= except for DOS!).

Tom



Joe

On 2018-05-25 07:49, Tom Herbert wrote:

Joe,

Checksum is not optional in TCP, it is a field= in the fixed TCP
header. The TCP checksum must always be set by the se= nder and
validated by the receiver. This advantages of a required check= sum are
major reason why I still think there should be a fixed header preceeding the UDP options list. The header would contain a one byte
= slack space type, a one byte length, two byte one's complement
che= cksum of the header and option list (coverage inidicated by
length). Su= ch a header allows other uses of the slack space,
substantially decreas= es the probability of misinterpretation of random
bits in the slack spa= ce as being UDP options (checksum, type, and
length need to be correct)= , solves the the checksum type being
corrupted problem, and eliminates = the need for EOL option. Please
consider adding this header.

To= m

Joe




Tom




Joe

= On 2018-05-24 12:52, Tom Herbert wrote:

On Thu, May 24, 2018 at 11= :43 AM, Joe Touch <touch@strayalpha.com> wrote:

Hi, all= ,

I didn't see any comments on the following - it would be usef= ul to hear from
anyone on the list regarding the issues below so we can= run a rev on the doc
and pin these things down.

So far I'v= e heard from only two parties - I'd appreciate both them and
anyone= else providing a very brief list of positions on these...

Joe,
=
One of the problems with TLVs in a datapath protocol is that they can<= br> too easily be used for DOS attack. This is especially true in the case<= br> that unkown TLV types are be ignored by a receiver and there is no
= reasonable protocol limit to the number of TLVs can be put into a
packe= t. Both of these conditions seem to be true for the UDP options.
The at= tack is simple, just fill up a packet with tiny TLVs with
unknown types= to the receiver.

A mitigation is described in the draft:

= =C2=A0">> Required options MUST come before other options. Each = required
option MUST NOT occur more than once (if they are repeated in = a
received segment, all except the first MUST be silently ignored).&quo= t;

and

"Implementations concerned with the potential f= or this vulnerability
MAY implement only the required options"
=
The first question I have to this is what are "required options&q= uot;. I
don't see where this is defined. Also, required is ambiguou= s. I assume
the intent is that these are options that a receiver is req= uired to
implement-- but that could have other meanings, like options t= hat a
sender is required to send. This needs to be clarified. Also, if<= br> required options must appear first then that raises another question: what happens if a packet is received where required options follow
n= on-required options. How does the receiver deal with this?

I'll= assume for sake of argument that the options specified in the
draft ar= e required options in that sense that a receiver must
understand these.= So then my next question is how can any new required
options be added.= Say that type 9 is defined as new security option
that is considered a= required option. How will deployed devices know
that this is a require= d option (as opposed to one that isn't required
and can be ignored)= ? Seems like the proper =C2=A0way to deal with would be
to steal a bit = from the type field that indicates the receive behavior
if the type in = unknown-- either ignore TLV or drop packet. This is
similar to high ord= er two bits of IPv6 option types (an option to send
an ICMP error might= also be useful here).

But, even if the required options are handle= d, DOS is still a problem
if an implementation wants to process even on= e non required option. In
that case it always needs to parse all the TL= Vs (i.e. it doesn't know
where in the TLV list the option is that i= t's looking for). So this
presents the implementor with an unpleasa= nt tradeoff, implementing any
non-required options may mean allowing ex= posure to DOS attack.

BTW, this DOS attack issue comes up in other = context. For DO and HBH
options we added text to draft-ietf-6man-rfc643= 4-bis-08 that allows
configurable limits on number of options (regardle= ss of whether the
options are "required"). If the limit is ex= ceeded the packet is
dropped. In Linux the default is to allow up to ei= ght options, that's
approximately based on the number of implemente= d options plus five.

Tom




Thanks,
Joe



On 2018-03-04 14:39, Joe Touch wrote:

Hi, all,
IMO, we would benefit popping up a level to the list of issues and
su= mmarizing our views.

Here's my attempt to do that.

Joe<= br>
=E2=80=94=E2=80=94=E2=80=94

Some assumptions:
a) overhe= ad is useful to minimize (efficiency and may reduce or avoid
fragmentat= ion)
b) LITE capability must be preserved
c) LITE+FRAG capability m= ust be preserved
d) this solution is not expected to outperform TCP (i.= e., this is not an
opportunity to redesign transport from scratch)
<= br> - TLV vs fixed header
motivated (AFAICT) by the desire to enable ha= rdware optimization and/or to
detect error/misuses of spare area
no= clear hardware benefit (given the option area "floats" relative = to the
UDP header,
which floats relative to the IPv6 header TLV cha= in, and given it may not be
word aligned)
no clear benefit regardin= g packet errors or other spare area uses
(both require either CS works = or TLV chain parses, neither of which is
likely for random errors or ot= her misuses)
fixed wastes at least 2 bytes if CS isn't used, (maybe= 4-6 if supporting
LITE/LITE+FRAG)

- Optional CS vs. mandatory<= br> motivated (AFAICT) by the desire to avoid processing packets with error= s
(accidental or by others misusing the extra space)
optional is ne= eded to correlate to lack of UDP checksum (for some types of
tunnels, e= .g.)
mandatory also implies fixed (above), which incurs 2-6 bytes of ov= erhead

- option-area checksum details
size
8 if TLV, 16 if = fixed; no clear problem with either choice
algorithm
no clear issue= with using minor mods (foldover for 8 bit, invert or not)
there are kn= own dangers to using the complement of the sum
(such that the sum and d= ata zero-out), as noted by the Partridge paper in
the 90s.

- EO= L vs option length field
length would have to be 2 bytes; EOL is an opt= ional one byte (not needed if
no spare area remains)
EOL thus saves= up to 2 bytes when not needed (and it should generally not be
needed a= t all)
allowing EOL (i.e., allowing remaining unused spare area) implie= s that
processing needs to stop at some point,
either based on a co= unter or the data seen (and given that a CS loads data
into a register = anyway, there's no clear performance win to either approach)
EOL it= self is patterned after the TCP option of the same name
and yes, leavin= g the spare area available for future use by other protocol
extensions = is intended here

- does CS end when EOL is seen?
yes, as curren= tly specified
as noted above, leaving the spare are for future standard= s is a goal

My conclusion is that all the choices above either fail= to improve the
situation vs. our current proposal or increase overhead= (or both). I don't
yet see a reason why any of them warrant a chan= ge vs. the existing approach.

--0000000000005ccf14056d0a239e-- From nobody Fri May 25 09:25:28 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20412DDD0 for ; Fri, 25 May 2018 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 JbZ_XJyPARvd for ; Fri, 25 May 2018 09:25:24 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 7D2DB127023 for ; Fri, 25 May 2018 09:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H55HXG5FOD7UsD/YMPMoNHdDfyVR1upKDuqgu7hMeKs=; b=2iENzckXDBWzpKxxvypyT+LW+ ids26Wdie2hkBgEUpWZwZqEevzJ6wY6g2whoeJUj+TcnW5X1NyG1hOzpJuYrG1vHQq7d6jj9Br7m3 CSOg/qfgq2/SOUJMIkKqkSRy5sBB35BuXKViOHsZNQnJV3slMACNYabQwP5JSMd3odbzig3GxGh0y hmG9tz0sNm38ZqH0j9vwNYUMBTdkWt9UbkrkjxgH2IhD7bc7vmy1cbNNk9igQoceSfBlil03vXEmg 9Dlb3udPRiJcCcCeNaScE14xFentXyOAJnI8V6Y4vlP+Y3uA3dJjR5BM2q4bTiuWf2dyCgzUPex2d FLUztCBfg==; Received: from [::1] (port=33606 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fMFWt-000BW8-5A; Fri, 25 May 2018 12:25:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c2ae70710f2d3e4cb2bcc39eb53fbfa3" Date: Fri, 25 May 2018 09:25:23 -0700 From: Joe Touch To: "C. M. Heard" Cc: tsvwg In-Reply-To: References: Message-ID: <98d37795c74813c2f4067154d6f34e65@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:25:26 -0000 --=_c2ae70710f2d3e4cb2bcc39eb53fbfa3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-25 09:01, C. M. Heard wrote: > Hi Joe, > > Regarding this: > > On Thu, May 24, 2018 at 11:39 AM, Joe Touch wrote: > > On 2018-05-06 10:23, C. M. Heard wrote: > Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over from a previous incarnation of the draft? > > UDP options support a similar service to UDP-Lite by terminating the > UDP options with an EOL option. The additional data not covered by > the UDP checksum follows that EOL option, and is passed to the user > separately. The difference is that UDP-Lite provides the un- > checksummed user data to the application by default, whereas UDP > options can provide the same capability only for endpoints that are > negotiated in advance (i.e., by default, UDP options would silently > discard this non-checksummed data). Additionally, in UDP-Lite the > checksummed and non-checksummed payload components are adjacent, > whereas in UDP options they are separated by the option area - > which, minimally, must consist of at least one EOL option. > > It seems to me that this should be rewritten, because the service in question is now provided by the LITE option. > > This text is exactly explaining the difference between our LITE and "UDP-Lite". I can clarify this, e.g.,: > The UDP option LITE option supports a similar service to UDP-Lite.... > Is there some part of this explanation of the differences that isn't accurate? The trouble with the above explanation (a) that is starts with an inaccurate description of how the LITE option works -- the unchecksummed data does NOT follow EOL in the surplus area Yes, that was from previous text and needs to be fixed. > -- and (b) it says that the checksummed and unchecksummed payload components are separated by the options -- which is not the case; the order, after processing the LITE option (slide/swap), is: > > UDP Header | checksummed payload data | unchecksummed payload data | options | trailing data following EOL Agreed - I do also need to check the how FRAG and LITE interact to make sure this describes the details correctly, but yes - thanks. I didn't see what you had issue with. > I've highlighted the specific sentences that I think have issues, and I propose the following replacement paragraph: > > UDP options, via the LITE option, support a service similar to > UDP-Lite. The main difference is that UDP-Lite supports carriage > of non-checksummed user data between the endpoints by default, > whereas UDP options can safely provide that service only between > endpoints that negotiate that capability in advance -- an endpoint > > that does not implement UDP options will silently discard the > > non-checksummed user data, along with the UDP options themselves. > > Hope this helps. Yes, thanks, Joe > Mike Heard --=_c2ae70710f2d3e4cb2bcc39eb53fbfa3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-05-25 09:01, C. M. Heard wrote:

Hi Joe,
 
Regarding this:

On Thu, May 24, 2018 at 11:39 AM, Joe Touch <touch@strayalpha.com><= /span> wrote:

On 2018-05-06 10:23, C. M. Heard wrote:=

Section 8, UDP options vs. UDP-Lite: Is the following para= graph left over from a previous incarnation of the draft?
   UDP options support a similar service to UDP-Lite by terminating =
the
   UDP options with an EOL option. The additional data not covered by
   the UDP checksum follows that EOL option, and is passed to the user
   separately. The difference is that UDP-Lite provides the un-
   checksummed user data to the application by default, whereas UDP
   options can provide the same capability only for endpoints that are
   negotiated in advance (i.e., by default, UDP options would silently
   discard this non-checksummed data). Additionally, in UDP-Lite the
   checksummed and non-checksummed payload components are adjacent,
   whereas in UDP options they are separated by the option area -
   which, minimally, must consist of at least one EOL option.
It seems to me that this should be rewritten, because the service in q= uestion is now provided by the LITE option.
This text is exactly explaining the difference between our LITE and "U= DP-Lite". I can clarify this, e.g.,:
    The UDP option LITE option supports a similar service to= UDP-Lite....
Is there some part of this explanation of the differences that isn't a= ccurate?
 
The trouble with the above explanation (a) that is starts with an inaccurat= e description of how the LITE option works -- the unchecksummed data does N= OT follow EOL in the surplus area
 
Yes, that was from previous text and needs to be= fixed. 
 
-- and (b) it says that the checksummed and unch= ecksummed payload components are separated by the options -- which is not t= he case; the order, after processing the LITE option (slide/swap), is:

UDP Header | checksummed payload data | unchecksummed payload data |= options |  trailing data following EOL
 
Agreed - I do also need to check the how FRAG an= d LITE interact to make sure this describes the details correctly, but yes = - thanks. I didn't see what you had issue with.
 
I've highlighted the specific sentences that I t= hink have issues, and I propose the following replacement paragraph:
   UDP options, via the LITE option, support a service similar =
to
   UDP-Lite.  The main difference is that UDP-Lite supports carriage
   of non-checksummed user data between the endpoints by default,
   whereas UDP options can safely provide that service only between
   endpoints that negotiate that capability in advance -- an endpoint
   that does not implement UDP options will silently discard th=
e
   non-checksummed user data, along with the UDP options themse=
lves.
 
Hope this helps.
 
Yes, thanks,
 
Joe
 
 
 
Mike Heard
--=_c2ae70710f2d3e4cb2bcc39eb53fbfa3-- From nobody Fri May 25 09:27:40 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7B12704A for ; Fri, 25 May 2018 09:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 HWIVlGYXalFe for ; Fri, 25 May 2018 09:27:36 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C1ACC127023 for ; Fri, 25 May 2018 09:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=h1cNnL1kn9BcOAqheSusWNJ1EyJit+D0bPu50bwSRyE=; b=Kcc8+vvl2ii08COffxh1VD0Au O71qj05vliG2W0KkKx/DlSE6CjmycI9tndgMITYmzTCVUOGm4OTpRs1v0QtjtbjSSUzf9glSsmmXr 18EdrxTcCuE452yvgyKgjffEUDbIF2at8SB5bIIEE1R4eIzWyaxwl0GXPdLy8UXuvkR2SNhcNyhQ8 PM4XuX4qD2F55E2qSuwQeK1MksrBzXNvnmGQ4rEL17vwa4GFimk115ILxVv2J0MuWWFA6AYuA3sSW 4+RBqggG5hEZvP2XU1/oC+IBcRYsXfu32cLmiX28Gvxgod4lXIXg0K47mRRDeXY0WM0azuAmIhnN6 3/gvQBjpw==; Received: from [::1] (port=57054 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fMFZ1-000D4z-Dh; Fri, 25 May 2018 12:27:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_bc0219e3958d7641039cdc09a50387fc" Date: Fri, 25 May 2018 09:27:35 -0700 From: Joe Touch To: Tom Herbert Cc: tsvwg In-Reply-To: References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> <8c3a04b0bc55fe0d0b08ae9d7681afcd@strayalpha.com> Message-ID: <786b0293d7c97d38b2795d4b247266fa@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:27:39 -0000 --=_bc0219e3958d7641039cdc09a50387fc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-25 09:18, Tom Herbert wrote: > On Fri, May 25, 2018, 9:10 AM Joe Touch wrote: > >> Hi, Tom, >> >> I think you're confusing ACS with OCS; ACS is the alternate checksum on the body. >> >> You've made your views on OCS clear; it would be useful to hear from others. >> >> Also, note that even if OCS were mandatory: >> >> a) it probably cannot come before LITE >> >> b) there's no need to include a length field with OCS per se; further, a one-byte length puts us back on the path where TCP ended up (of limiting option space). IF we include that, it would need to be two bytes > > A one byte length field would allow 256 bytes of options, same as IPv6 DO and HBH. That's already almost 20% of normal Ethernet MTU, I'm very doubtful there would ever be a practical use for more bytes in options (except for DOS!). At the transport layer, the "option" space could be used for any number of things - I'd also have to check how it interacts with FRAGs as well. I don't think it is useful to make this assumption at this time. Joe --=_bc0219e3958d7641039cdc09a50387fc Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-05-25 09:18, Tom Herbert wrote:



On Fri, May 25, 2018, 9:10 AM Joe Touch <touch@strayalpha.com> wrote:

Hi, Tom,

I think you're confusing ACS with OCS; ACS is the alternate checksum on = the body.

You've made your views on OCS clear; it would be useful to hear from oth= ers.

Also, note that even if OCS were mandatory:

a) it probably cannot come before LITE

b) there's no need to include a length field with OCS per se; further, a= one-byte length puts us back on the path where TCP ended up (of limit= ing option space). IF we include that, it would need to be two bytes

 
A one byte length field would allow 256 bytes of options,= same as IPv6 DO and HBH. That's already almost 20% of normal Ethernet MTU,= I'm very doubtful there would ever be a practical use for more bytes in op= tions (except for DOS!).
 
At the transport layer, the "option" space could be used = for any number of things - I'd also have to check how it interacts with FRA= Gs as well. I don't think it is useful to make this assumption at this time= =2E

Joe
--=_bc0219e3958d7641039cdc09a50387fc-- From nobody Fri May 25 09:32:04 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C1B12704A for ; Fri, 25 May 2018 09:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 hCsCHebTUY4n for ; Fri, 25 May 2018 09:32:00 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 68FEE127023 for ; Fri, 25 May 2018 09:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ewf6DgrWcsJlxOjYcaW5MuyY6pyMiNCScP4eXob4j24=; b=w6MIfhKt9rdeUdJ5ljHyB/XFm Tc2axz71SU3xGR8MHT05XquI4dguDqmD/dhfuOWHwC/D150eeFjC9CpNxKciGucKzEGbQotIXw1AH ITbJ1PWGyT3a9ziDKmeixttaAMTIM3/jWjAu/kYQytT6vVn5YZU/y7frUhI1E5+sp0P81Nw3jkO2k Uc+arx/P1I4G6pL5OaatxBD1x5He7Jfkk0nkwslWTvc/EoFcWrwBqloVoV7DEQHH9Vls7mFkxlsH7 gqdEFdDngeaR4tvrgTP7vy2rVSvWQ3Ai6+BTTCrAJH1qLk3BMJunYceloS9lZJsR9FFVPMmjWQmxm jS9GWsbPA==; Received: from [::1] (port=46842 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fMFdD-000GCh-TU; Fri, 25 May 2018 12:31:56 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f07f66a818084b966ddaab2e438ddda1" Date: Fri, 25 May 2018 09:31:55 -0700 From: Joe Touch To: gorry@erg.abdn.ac.uk Cc: Mitchell Erblich , tsvwg In-Reply-To: <5B07C02C.2070908@erg.abdn.ac.uk> References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> <0112B493-9AF7-4E2D-8417-F4CE857047CE@earthlink.net> <5B07C02C.2070908@erg.abdn.ac.uk> Message-ID: <8ea31ba2bb9dd4432432b3783f7c3708@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:32:03 -0000 --=_f07f66a818084b966ddaab2e438ddda1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII > HI, Gorry, On 2018-05-25 00:50, Gorry Fairhurst wrote: >> I'd encourage some thought on TLV processing and DOS vulnerabilities as a separate security considerations subsection. I'd suggest this topic appears enough in transport design to justify a separate heading to assure readers of the safety of the approach. While I agree some text would be useful, I don't think this protocol needs to fight that battle in total. >> Since UDP provides a datagram service, the app (or the stack/path) can silently discard any data. I think this means we can think a little about how this should best now be handled. >> >> Is it the case that option and the datagram payload share the same fate? >> i.e. if the option part is not processed - then the datagram payload is not forwarded to the App? It depends on the receiver's capability; for legacy receivers, yes - it would be forwarded. For option-capable receivers, that's a configuration parameter for the socket. >> - This could simplify any probing by an endpoint to understand if an option is supported and will also avoid unexpected behaviours when any DDOS mechanism kicks-in and starts not processing options. If the API discards the entire datagram, it then behaves just as any IP-level policer would. I don't think we should encourage dropping packets with unknown options until soft state has been established, because that undermines the deployment of new capabilities. But after that, sure. This does argue for an expanded discussion of the issue of soft state, though. >> - I also think it may perhaps be OK to separately log these discards (where rate-limiting permits), counting them as received at the transport but not forwarded to the App. It's not clear that's useful after soft-state is established. >> I was assuming from what is written below that the decision about how to respond would be at the application level, or do you think the stack would have enough information to implement this sort of function? The stack should, but if the count is high then at best it should alert the app. Any other behavior should be out of scope for this doc to specify - because a burst of such packets can occur legitimately (UDP is not rate-controlled or stateful), so it is inappropriate to infer an attack. >From another discussion, my corollary to the Postal Principle is: on sending, do not IMPLY on receiving, do not INFER Joe --=_f07f66a818084b966ddaab2e438ddda1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


HI, Gorry,

On 2018-05-25 00:50, Gorry Fairhurst wrote:

= I'd encourage some thought on TLV processing and DOS vulnerabilities as a s= eparate security considerations subsection. I'd suggest this topic appears = enough in transport design to justify a separate heading to assure readers = of the safety of the approach.
=  
= While I agree some text would be useful, I don't think this protocol needs = to fight that battle in total.
=  
= Since UDP provides a datagram service, the app (or the stack/path) can sile= ntly discard any data. I think this means we can think a little about how t= his should best now be handled.

Is it the case that option and the&= nbsp;datagram payload share the same fate?<= br />i.e. if the option part is not processed - then the datagram payload i= s not forwarded to the App?
=  
= It depends on the receiver's capability; for legacy receivers, yes - it wou= ld be forwarded.
=  
= For option-capable receivers, that's a configuration parameter for the sock= et.
=  
= - This could simplify any probing by an endpoint to understand if an option= is supported and will also avoid unexpected behaviours when any DDOS mecha= nism kicks-in and starts not processing options. If the API discards the en= tire datagram, it then behaves just as any IP-level policer would.
=  
= I don't think we should encourage dropping packets with unknown options unt= il soft state has been established, because that undermines the deployment = of new capabilities. But after that, sure.
=  
= This does argue for an expanded discussion of the issue of soft state, thou= gh.
=  
= - I also think it may perhaps be OK to separately log these discards (where= rate-limiting permits), counting them as received at the transport but not= forwarded to the App.
=  
= It's not clear that's useful after soft-state is established. 
=  
= I was assuming from what is written below that the decision about how to re= spond would be at the application level, or do you think the stack would ha= ve enough information to implement this sort of function?
=  
= The stack should, but if the count is high then at best it should alert the= app. Any other behavior should be out of scope for this doc to specify - b= ecause a burst of such packets can occur legitimately (UDP is not rate-cont= rolled or stateful), so it is inappropriate to infer an attack.
=  
= >From another discussion, my corollary to the Postal Principle is:
=  
=      on sending, do not IMPLY
    =  on receiving, do not INFER
=  
= Joe
--=_f07f66a818084b966ddaab2e438ddda1-- From nobody Fri May 25 09:35:25 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8921270AC for ; Fri, 25 May 2018 09:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 Q2-wgeiHMom2 for ; Fri, 25 May 2018 09:35:21 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814B8127023 for ; Fri, 25 May 2018 09:35:21 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id e8-v6so7297475qth.0 for ; Fri, 25 May 2018 09:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rV2JQLIpUxUMAhl8SMS/Mtoc0x8KUFs/D2tIFVYsuVw=; b=Z7DZL0StxiJH0WDT8fnAa9e/pBQLHGejeY+35JtV5aGmnuVrYbrvngU12ZeUyEzOZr 5Mq/ZtqsqDNuIMSwrharc/OqwF7uVmKVtlba75Sf+978aZg2mVxRu/yM0hXbKQaqxTWv rEOunZR1PcNKlab/Sv64mcDTzLi++f8+9k7u8lcYpXBV3BDmLVOvSvtSzcpgd9mI2V2y F3eNRm+sYNL0EuSyfuXrsO1IV1FidfiiQSmrwrGFfLWw1oNoo7iH9CMpPUolRmitTUOW 2Okw2oBISDOw8b4Os2mQNciy5UBK8UuNIf/g1PfnFwr4B32DSF8K2kP1eddNcS52sUZI u+hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rV2JQLIpUxUMAhl8SMS/Mtoc0x8KUFs/D2tIFVYsuVw=; b=okmG9AvDhcROhZCwzmX78JMPgg0goqeLwK3eYQXzpIzpW1LsrFOWJPW3rfd2exR/wj DRW1chrEOARbUNk7BFFLbPpehhsM3iz38OYyJvC03xhtXVJwHYavA5OpwYumLQxcxWAi q6cqdhrV8EJt3EUNfIBziu7Yx+5K8ABdRIlu+TmPvecfdDuJWtaCTXjjGO2PxpXc6Cz3 fpxQH1joqqy1sWx9G6bqf4de4bI1f7CxTUKzPco4lQzqbodL8rJ1ht2ZVHNb+bm/tZQV f637QmHfDc5B+isnpa4UjaJ0Z4L0DRoSHFzQs/BGOISadKEsp7uswlHRUufOoJulWIX8 18oA== X-Gm-Message-State: ALKqPwcg0FX011tUOwhERuuTmYy7WzDAioA5TW6v/H0y9el5vZHftHyp QOkr56YGgfOQAyCaWjM8Lytjov7offcCDEMrRBa3Cg== X-Google-Smtp-Source: ADUXVKKI9XAEGPTGJqGDfUoDQIQMyB/9lbfILP7e05PyagPHDzmCpq0+SFp24WsNW2M+/tqS/C4xet2CbJh37fIHwxI= X-Received: by 2002:ac8:18c8:: with SMTP id o8-v6mr2806819qtk.400.1527266120364; Fri, 25 May 2018 09:35:20 -0700 (PDT) MIME-Version: 1.0 References: <0E155501-B1FA-43E9-BF07-D30AADA4D088@strayalpha.com> <0112B493-9AF7-4E2D-8417-F4CE857047CE@earthlink.net> <5B07C02C.2070908@erg.abdn.ac.uk> <8ea31ba2bb9dd4432432b3783f7c3708@strayalpha.com> In-Reply-To: <8ea31ba2bb9dd4432432b3783f7c3708@strayalpha.com> From: Tom Herbert Date: Fri, 25 May 2018 09:35:07 -0700 Message-ID: To: Joe Touch Cc: Gorry Fairhurst , tsvwg Content-Type: multipart/alternative; boundary="000000000000950124056d0a5a0a" Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 16:35:24 -0000 --000000000000950124056d0a5a0a Content-Type: text/plain; charset="UTF-8" On Fri, May 25, 2018, 9:32 AM Joe Touch wrote: > > HI, Gorry, > > On 2018-05-25 00:50, Gorry Fairhurst wrote: > > I'd encourage some thought on TLV processing and DOS vulnerabilities as a > separate security considerations subsection. I'd suggest this topic appears > enough in transport design to justify a separate heading to assure readers > of the safety of the approach. > > > While I agree some text would be useful, I don't think this protocol needs > to fight that battle in total. > > > Since UDP provides a datagram service, the app (or the stack/path) can > silently discard any data. I think this means we can think a little about > how this should best now be handled. > > Is it the case that option and the datagram payload share the same fate? > i.e. if the option part is not processed - then the datagram payload is > not forwarded to the App? > > > It depends on the receiver's capability; for legacy receivers, yes - it > would be forwarded. > > For option-capable receivers, that's a configuration parameter for the > socket. > > > - This could simplify any probing by an endpoint to understand if an > option is supported and will also avoid unexpected behaviours when any DDOS > mechanism kicks-in and starts not processing options. If the API discards > the entire datagram, it then behaves just as any IP-level policer would. > > > I don't think we should encourage dropping packets with unknown options > until soft state has been established, because that undermines the > deployment of new capabilities. But after that, sure. > > This does argue for an expanded discussion of the issue of soft state, > though. > The draft mentions that UDP options should be negotiated. Is a protocol going to be specified for that? Tom > > - I also think it may perhaps be OK to separately log these discards > (where rate-limiting permits), counting them as received at the transport > but not forwarded to the App. > > > It's not clear that's useful after soft-state is established. > > > I was assuming from what is written below that the decision about how to > respond would be at the application level, or do you think the stack would > have enough information to implement this sort of function? > > > The stack should, but if the count is high then at best it should alert > the app. Any other behavior should be out of scope for this doc to specify > - because a burst of such packets can occur legitimately (UDP is not > rate-controlled or stateful), so it is inappropriate to infer an attack. > > >From another discussion, my corollary to the Postal Principle is: > > on sending, do not IMPLY > on receiving, do not INFER > > Joe > --000000000000950124056d0a5a0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Fri, May 25, 2018, 9:32 AM Joe Touch <touch@strayalpha.com> wrote:


HI, Gorry,

On 2018-05-25 00:50, Gorry Fairhurst wrote:

I'd encourage some thought on TLV processing and DOS vu= lnerabilities as a separate security considerations subsection. I'd sug= gest this topic appears enough in transport design to justify a separate he= ading to assure readers of the safety of the approach.
=C2=A0
While I agree some text would be useful, I don't think = this protocol needs to fight that battle=C2=A0in total.
=C2=A0
Since UDP provides a datagram service, the app (or the stac= k/path) can silently discard any data. I think this means we can think a li= ttle about how this should best now be handled.

Is=C2=A0it=C2=A0the=C2=A0case=C2=A0that=C2=A0option=C2=A0and= =C2=A0the=C2=A0datagram=C2=A0payload=C2=A0share=C2=A0the=C2=A0same=C2=A0fat= e?
i.e. if the option part is not processed - then the datagram p= ayload is not forwarded to the App?
=C2=A0
It depends on the receiver's capability; for legacy rec= eivers, yes - it would be forwarded.
=C2=A0
For option-capable receivers, that's a configuration pa= rameter for the socket.
=C2=A0
- This could simplify any probing by an endpoint to underst= and if an option is supported and will also avoid unexpected behaviours whe= n any DDOS mechanism kicks-in and starts not processing options. If the API= discards the entire datagram, it then behaves just as any IP-level policer= would.
=C2=A0
I don't think we should encourage dropping packets with= unknown options until soft state has been established, because that underm= ines the deployment of new capabilities. But after that, sure.
=C2=A0
This does argue for an expanded discussion of the issue of = soft state, though.

The draft mentions that UDP options should= be negotiated. Is a protocol going to be specified for that?

Tom

=
=C2=A0
- I also think it may perhaps be OK to separately log these= discards (where rate-limiting permits), counting them as received at the t= ransport but not forwarded to the App.
=C2=A0
It's not clear that's useful after soft-state is es= tablished.=C2=A0
=C2=A0
I was assuming from what is written below that the decision= about how to respond would be at the application level, or do you think th= e stack would have enough information to implement this sort of function?
=C2=A0
The stack should, but if the count is high then at best it = should alert the app. Any other behavior should be out of scope for this do= c to specify - because a burst of such packets can occur legitimately (UDP = is not rate-controlled or stateful), so it is inappropriate to infer an att= ack.
=C2=A0
>From another discussion, my corollary to the Postal Pri= nciple is:
=C2=A0
=C2=A0 =C2=A0 =C2=A0on sending, do not IMPLY
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0on receiving, do not INFER
=C2=A0
Joe
--000000000000950124056d0a5a0a-- From nobody Fri May 25 11:10:47 2018 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68F1127286 for ; Fri, 25 May 2018 11:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 odYqWcaIdsxD for ; Fri, 25 May 2018 11:10:44 -0700 (PDT) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A8A1270FC for ; Fri, 25 May 2018 11:10:44 -0700 (PDT) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 6F074DB00D for ; Fri, 25 May 2018 14:10:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=i3V O/D3YB0Lig0DI4pgjqzMacUk=; b=RUbQofkaVpQJc4HzcohRj7rrFGGJeZe8Fhj NuU4o/ahC3GzsydYG5ZwkNRayBOED4iNnwcWN5e4DWTmwB1410EBHz0yBsty1l9u ytSwZ9oQFYfGtttY+eUN9uCkuUUCdnYaRRwpICRCGe8iAVLpBdZfxF3dwojltYsF xd39Gxdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= ajWevza7LrhlVRwAsbxAhwGoJgBNbs4lIXNqVY2Tf1/rno7bRNcA+TJvIgUo8rFE zwPkbBgBIHIGILibj35NTk/DHMC4RuFa5wZPU+EU5zlghCP+Nd1GJIzFluNJdWeR C3VQZwosCGYrZA1TaJSXmK/1QwkMhksXxa0O1X/cxQc= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 65577DB00C for ; Fri, 25 May 2018 14:10:43 -0400 (EDT) Received: from mail-ot0-f179.google.com (unknown [74.125.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id DAD8EDB009 for ; Fri, 25 May 2018 14:10:42 -0400 (EDT) Received: by mail-ot0-f179.google.com with SMTP id y10-v6so7015464otg.10 for ; Fri, 25 May 2018 11:10:42 -0700 (PDT) X-Gm-Message-State: ALKqPweemDwdy/+cadL4pDStbFmwhmXXCkc/tLiHdwGVFyUAIkfiwCHE 86MbYnSXtMdFSnkK2tQkKVuHv6Cy1GZ/M3OKHm8= X-Google-Smtp-Source: ADUXVKIf9JRWIgvSzIfErO22gYlqSyMa1uULNZjWXGKbpj9XLAFQ9U6b2ebB2KAXh+iKTUlubdmY9ScqwlqQLLYf2GM= X-Received: by 2002:a9d:66f:: with SMTP id 102-v6mr2425288otn.106.1527271842213; Fri, 25 May 2018 11:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:88c6:0:0:0:0:0 with HTTP; Fri, 25 May 2018 11:10:21 -0700 (PDT) From: "C. M. Heard" Date: Fri, 25 May 2018 11:10:21 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tsvwg Cc: Joe Touch Content-Type: multipart/alternative; boundary="000000000000a17235056d0baf0b" X-Pobox-Relay-ID: F039D236-6046-11E8-B03E-67830C78B957-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] UDP options list of issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 18:10:46 -0000 --000000000000a17235056d0baf0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings, I am in general agreement with Joe's positions in the trailing message below. Regarding some other things raised during the recent discussion: - Mitigation of potential DOS attack from potentially long list of TLVs: Gorry's suggestion to include a beefed-up discussion of this issue in th= e Security Considerations section of the document seems to me the correct approach. - Mandatory options: these are the options that must be supported by all implementations of the UDP options specification. IMHO they should compr= ise the minimal set of options needed for proper parsing and validation of t= he UDP options trailer, with the expectation that the list will *not* be further expanded. That minimal set is EOL, NOP, OCS, and LITE. Note that= I have added LITE to the list in the current draft because an implementati= on that doesn't understand it will skip over it and start consuming part of the LITE data as if they were TLVs. That will not work. An implementatio= n must be able to perform the swap/slide operation to put the LITE option = in its proper place in order to parse the rest of the options trailer. I see some other things not yet discussed that need correction or clarification: - Options that depend on the contents of the option area: this set should include AE, alone. It should not include ACS, as ACS covers the payload alone, excluding the UDP header and the UDP options trailer. (No= te that there is a typo in this connection at the top of page 7: s/independent/dependent/.) - ACS coverage: does this include LITE data or not? This point needs to be made explicit. I can see arguments both ways, but I would like to see the LITE data included so that ACS can be used when FRAG is combined wit= h LITE. If there is worry about a redundant checksum calculation in this case, just set the checksum the final FRAG option to zero and don't comp= ute it. Mike Heard On Thu, 24 May 2018 11:43:47 -0700, Joe Touch wrote: > Hi, all, > > I didn't see any comments on the following - it would be useful to hear > from anyone on the list regarding the issues below so we can run a rev on > the doc and pin these things down. > > So far I've heard from only two parties - I'd appreciate both them and > anyone else providing a very brief list of positions on these... > > Thanks, > Joe > > > > On 2018-03-04 14:39, Joe Touch wrote: > > Hi, all, > > IMO, we would benefit popping up a level to the list of issues and > summarizing our views. > > Here's my attempt to do that. > > Joe > > =E2=80=94=E2=80=94=E2=80=94 > > Some assumptions: > a) overhead is useful to minimize (efficiency and may reduce or avoid > fragmentation) > b) LITE capability must be preserved > c) LITE+FRAG capability must be preserved > d) this solution is not expected to outperform TCP (i.e., this is not an > opportunity to redesign transport from scratch) > > - TLV vs fixed header > motivated (AFAICT) by the desire to enable hardware optimization and/or t= o > detect error/misuses of spare area > no clear hardware benefit (given the option area "floats" relative to the > UDP header, > which floats relative to the IPv6 header TLV chain, and given it may not > be word aligned) > no clear benefit regarding packet errors or other spare area uses > (both require either CS works or TLV chain parses, neither of which is > likely for random errors or other misuses) > fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting > LITE/LITE+FRAG) > > - Optional CS vs. mandatory > motivated (AFAICT) by the desire to avoid processing packets with errors > (accidental or by others misusing the extra space) > optional is needed to correlate to lack of UDP checksum (for some types o= f > tunnels, e.g.) > mandatory also implies fixed (above), which incurs 2-6 bytes of overhead > > - option-area checksum details > size > 8 if TLV, 16 if fixed; no clear problem with either choice > algorithm > no clear issue with using minor mods (foldover for 8 bit, invert or not) > there are known dangers to using the complement of the sum > (such that the sum and data zero-out), as noted by the Partridge paper in > the 90s. > > - EOL vs option length field > length would have to be 2 bytes; EOL is an optional one byte (not needed > if no spare area remains) > EOL thus saves up to 2 bytes when not needed (and it should generally not > be needed at all) > allowing EOL (i.e., allowing remaining unused spare area) implies that > processing needs to stop at some point, > either based on a counter or the data seen (and given that a CS loads dat= a > into a register anyway, there's no clear performance win to either approa= ch) > EOL itself is patterned after the TCP option of the same name > and yes, leaving the spare area available for future use by other protoco= l > extensions is intended here > > - does CS end when EOL is seen? > yes, as currently specified > as noted above, leaving the spare are for future standards is a goal > > My conclusion is that all the choices above either fail to improve the > situation vs. our current proposal or increase overhead (or both). I don'= t > yet see a reason why any of them warrant a change vs. the existing approa= ch. > > > --000000000000a17235056d0baf0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I am in general a= greement with Joe's positions in the trailing message below. Regarding = some other things raised during the recent discussion:
  • Mi= tigation of potential DOS attack from potentially long list of TLVs: Gorry&= #39;s suggestion to include a beefed-up discussion of this issue in the Sec= urity Considerations section of the document seems to me the correct approa= ch.
  • Mandatory options: these are the options that must be supported= by all implementations of the UDP options specification. IMHO they should = comprise the minimal set of options needed for proper parsing and validatio= n of the UDP options trailer, with the expectation that the list will not be further expanded. That minimal set is EOL, NOP, OCS,= and LITE. Note that I have added LITE to the list in the current draft bec= ause an implementation that doesn't understand it will skip over it and= start consuming part of the LITE data as if they were TLVs. That will not = work. An implementation must be able to perform the swap/slide operation to= put the LITE option in its proper place in order to parse the rest of the = options trailer.
I see some other things not yet discussed th= at need correction or clarification:
  • Options that depend on th= e contents of the option area: this set should include AE, alone. It should= not include ACS, as ACS covers the payload alone, excluding the UDP header= and the UDP options trailer. (Note that there is a typo in this connection= at the top of page 7: s/independent/dependent/.)
  • =C2=A0ACS coverag= e: does this include LITE data or not? This point needs to be made explicit= . I can see arguments both ways, but I would l