From nobody Fri Mar 3 16:03:15 2017 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 E3F8D129A6A; Fri, 3 Mar 2017 15:55:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533892.15846.13560113392485748104.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:38 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] tsvwg - Requested sessions have been scheduled for IETF 98 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:39 -0000 Dear Gorry Fairhurst, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tsvwg Session 1 (1:00:00) Monday, Afternoon Session III 1710-1810 Room Name: Vevey 1/2 size: 200 --------------------------------------------- tsvwg Session 2 (2:00:00) Thursday, Afternoon Session I 1300-1500 Room Name: Zurich A size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: intarea tsvarea iccrg aqm rmcat tcpm mptcp taps ippm quic tcpinc rtgwg opsarea Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Meetecho support in room Special Requests: [If rtcweb has 2 sessions, 1 should not conflict] [Must not conflict with Transport Area BoFs] --------------------------------------------------------- From nobody Fri Mar 3 16:04:50 2017 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 3BBAE126D73 for ; Fri, 3 Mar 2017 16:00:49 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, 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=dell.com header.b=HeLoYwMH; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=GMIDa0U4 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 5j5qt3rzMq7e for ; Fri, 3 Mar 2017 16:00:44 -0800 (PST) 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 D66291299A2 for ; Fri, 3 Mar 2017 15:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1488585571; x=1520121571; h=from:to:subject:date:message-id:mime-version; bh=bgsaUVqqV/pqIWRII8mvqQXYqNI9I8kCL8XFoP7iuP8=; b=HeLoYwMHVfzg5yj430TuwZUCTA8sh3LpEPsZZnxbcmVtxWHiKO8gp0i9 M2dBQzTQZ19zJSEOhtmA/IV52/fmNrYseRr/Jdix08mB+HA1tof38p8su vdaoqK+/VeSi7EntgIIQKy9/EWxdXuSxqjLAFXGxh0QFlFosc496cr/Yo E=; 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; 03 Mar 2017 17:59:31 -0600 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; 04 Mar 2017 05:59:30 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v23NxTeJ020017 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 3 Mar 2017 18:59:29 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v23NxTeJ020017 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1488585569; bh=tXwtiZMn5oZjyGz/cIuHlQJly3Y=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=GMIDa0U4x7djlI/7U4ahfD2ZuIg2PV0ZU6gR/fe3oseklJwwCXyjpf7TOYDC4jXSa cyZ3qRkqCr/A9bZT/CN42gNQmXhpiigBtmLJnJat+cxhTuFwp/jcoStYMnumQ1eTss bZ6/gtrgg/EHeegIo1HcfKjRUnWDJVrxKIhRdS8o= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v23NxTeJ020017 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Fri, 3 Mar 2017 18:57:51 -0500 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v23NxEDV023717 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 3 Mar 2017 18:59:14 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0266.001; Fri, 3 Mar 2017 18:59:14 -0500 To: "tsvwg@ietf.org" Thread-Topic: LE PHB -01 draft comments (from David Black) Thread-Index: AdKUeigkfiSLH844TRKlBvACYyszEQ== Date: Fri, 3 Mar 2017 23:59:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.62] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F8DD52BMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] LE PHB -01 draft comments (from David Black) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:00:49 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F8DD52BMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roland, I'm writing this email as the draft shepherd, not WG chair. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ First of all, thanks for working on this draft to help clean up a long-stan= ding set of problems around Lower Effort traffic marking and handling. I'v= e done a relatively thorough review of this draft, and listed comments in o= rder of occurrence. Technical issues that need some attention are noted w= ith ** for minor issue and **** for major issues, and summarized here: ** Section 1.2 - I wonder whether the 2nd and 3rd bullets are overstated. **** Section 3 - First paragraph needs some attention as it seems to switch= back and forth between networks in general and networks with full support = for LE **** Section 5 - "MUST remark" requirement, is not backwards compatible wit= h RFC 4594, needs WG discussion ** Section 7 - IANA Considerations need some attention ** Section 8 - Mention of traffic "downgraded" to LE seems to conflict with= recommendations not to downgrade to LE elsewhere. I also generally concur with Ruediger's comments, and in particular share h= is concern about whether "precedence" is the right word here - that might b= e good to discuss in Chicago. -- Section 1 OLD sufficiently low urgency, in which all other traffic takes precedence NEW sufficiently low urgency that all other traffic takes precedence Editorial Low urgency traffic has got a low priority in time, which does not necessarily imply that it is generally of minor importance. "has got a low priority in time" -> "has a low priority for timely forwardi= ng" OLD Alternatively, the effect of this type of traffic on all other network traffic is strictly limited. NEW Other networks may strictly limit the effects of this type of traffic on all other network traffic. (This is to parallel wording at start of immediately previous paragraph) -- Section 1.1 OLD A Lower Effort PHB is applicable for most elastic applications that otherwise use best-effort delivery. More specifically, it is suitable for traffic and services accepting strongly varying throughput for their data flows, especially with respect to periods of very low throughput or even starvation (i.e., long interruptions due to excessive packet loss). NEW A Lower Effort PHB is applicable for many applications that otherwise use best-effort delivery. More specifically, it is suitable for traffic and services that can tolerate strongly varying throughput for their data flows, especially periods of very low throughput or even starvation (i.e., long interruptions due to significant or even complete packet loss). Minor edits - "most" seems overstated in first sentence. OLD nor should packets be "downgraded" to the LE PHB used as a substitute for dropping packets that ought simply to be dropped as unauthorized. NEW nor should packets be "downgraded" to the LE PHB instead of being dropped, particularly when the packets are unauthorized traffic. Editorial The LE PHB is expected to have applicability in networks that have at least some unused capacity at some times of day. Just times of day, or also days of the week, holidays, etc.? I suggest ge= neralizing this text. OLD The LE PHB allows networks to protect themselves from selected types of traffic rather than giving a selected traffic aggregate preferential treatment. Moreover, the LE PHB may also exploit all unused resources from other PHBs. NEW The LE PHB allows networks to protect themselves from selected types of traffic as a complement to giving preferential treatment to other selected traffic aggregates. Moreover, the LE PHB may take advantage of network resources unused by other PHBs. Editorial OLD There is no intrinsic reason to limit the applicability of the LE PHB to any particular application or type of traffic. It is intended as an additional tool for administrators in engineering networks. For instance, it can be used for filling up protection capacity of transmission links which is otherwise unused. Some network providers keep link utilization below 50% in order to being able carrying all traffic without loss in case of rerouting due to a link failure. NEW There is no intrinsic reason to limit the applicability of the LE PHB to any particular application or type of traffic. It is intended as an additional traffic engineering tool for network administrators. For instance, it can be used to fill protection capacity of transmission links that is otherwise unused. Some network providers keep link utilization below 50% to ensure that all traffic without loss after rerouting caused by a link failure. "engineering" -> "traffic engineering" is important, all other changes are = editorial. Example uses for the LE PHB comprise: Delete "comprise" ** The last bullet in Section 1.1. contains some discussion of "downgraded"= that goes beyond an example, and ought to be merged into the last paragrap= h on p.3. -- Section 1.2 First bullet: "has got" -> "has" ** I wonder whether the 2nd and 3rd bullets are overstated. There is some = network switch/router configuration required and something like a low prior= ity queue has to be set up to drop LE traffic when there are other competin= g uses. I don't think the bullets are actually wrong, but some additional= text to point out what does have to be done to use the LE PHB would be hel= pful. -- Section 2 OLD Ideally, LE packets SHOULD be forwarded only if no best- effort packet is waiting for its transmission. NEW Ideally, LE packets SHOULD be forwarded only if no packet with any other PHB is awaiting transmission. Understated - should apply to all PHBs, not just default. -- Section 3 **** First paragraph needs some attention as it seems to switch back and fo= rth between networks in general (LE causes effects that are best-effort at = worst) and networks with full support for LE (last sentence recommending no= boundary policing assumes that LE is preferentially dropped wrt all other = PHBs at all bottlenecks). At a minimum, a network that forwards LE as Def= ault, needs to treat LE traffic as part of a Traffic Aggregate that is at l= east LE + Default and police that appropriately at the edge. In general, = I suggest thinking carefully about separating statements that apply to all = networks (with and degree or absence of LE PHB support) from those that app= ly to networks with full LE support at every possible bottleneck (warning: = this can be subtle, e.g., there may be an L2 link bottleneck that doesn't = understand the LE vs. Default distinction for IP traffic). Non-LE traffic (e.g., BE traffic) SHOULD not be remarked to LE on a regular basis without consent or knowledge of the user. "SHOULD not" -> SHOULD NOT" Also, this text feels like it's part of the "downgrade" discussion at the = end of p.3, and at least ought to point back to that. --Section 5 A DS domain that still uses DSCP CS1 for marking LE traffic (including Low Priority-Data as defined in [RFC4594] or the old definition in [RFC3662]) MUST remar= k traffic to the LE DSCP '000010' at the egress to the next DS domain. ****I definitely want to see broader WG discussion of that "MUST remark" re= quirement, as it's not backwards compatible with RFC 4594 - at a minimum, s= ome thought should be applied to transition and mixing networks that use CS= 1 and the new LE DSCP. --Section 7 ** (entire set of comments on Section 7) IANA Considerations need to tell IANA what Name to use for the codepoint (L= E) and what to use as a Reference (this document). In general, when assi= gning a field from an existing registry, check the columns that IANA will n= eed to fill in and supply contents. This section will need some editing, as the "Standards Action" of this memo= is what assigns that codepoint. Suggestion: This document assigns the Differentiated Services Field Codepoint (DSCP= ) '000010' from the Differentiated Services Field Codepoints (DSCP) regis= try (https://www.iana.org/assignments/dscp-registry/dscp-registry.xml) to th= e LE PHB. IANA is requested to update the registry as follows: - Name: LE - Codepoint: 000010 - Reference: [RFC number of this memo] Also, I just notice that the header on the middle column of the IANA regist= ry is "Space" - it should be "Codepoint": IANA is also requested to correct the header of the middle column of the Pool 1 Codepoints table in that registry by changing it from "Space" to "Codepoint". -- Section 8 ** Mention of traffic "downgraded" to LE seems to conflict with recommendat= ions not to downgrade elsewhere. Thanks, --David -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949362F8DD52BMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roland,

 

<WG chair hat OFF>

I’m writing this email as the draft shepher= d, not WG chair.

 

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-p= hb/

 

First of all, thanks for working on this draft to= help clean up a long-standing set of problems around Lower Effort traffic = marking and handling.  I’ve done a relatively thorough review of= this draft, and listed comments in order of occurrence.   Technical issues that need some attention are note= d with ** for minor issue and **** for major issues, and summarized here:

 

** Section 1.2 - I wonder whether the 2nd and 3rd= bullets are overstated.

**** Section 3 - First paragraph needs some atten= tion as it seems to switch back and forth between networks in general and n= etworks with full support for LE

**** Section 5 - “MUST remark” requir= ement, is not backwards compatible with RFC 4594, needs WG discussion<= /o:p>

** Section 7 - IANA Considerations need some atte= ntion

** Section 8 - Mention of traffic “downgrad= ed” to LE seems to conflict with recommendations not to downgrade to = LE elsewhere.

 

I also generally concur with Ruediger’s com= ments, and in particular share his concern about whether “precedence&= #8221; is the right word here - that might be good to discuss in Chicago.

 

-- Section 1

 

OLD

   sufficiently low urgency, in which all other = traffic takes precedence

NEW

   sufficiently low urgency that all other traff= ic takes precedence

 

Editorial

 

   Low

   urgency traffic has got a low priority in tim= e, which does not

   necessarily imply that it is generally of min= or importance.

 

“has got a low priority in time” ->= ; “has a low priority for timely forwarding”

 

OLD

   Alternatively, the effect of this type of tra= ffic on all other

   network traffic is strictly limited.

NEW

   Other networks may strictly limit the effects= of this type of

   traffic on all other network traffic.

 

(This is to parallel wording at start of immediat= ely previous paragraph)

 

-- Section 1.1

 

OLD

   A Lower Effort PHB is applicable for most ela= stic applications that

   otherwise use best-effort delivery.  Mor= e specifically, it is

   suitable for traffic and services accepting s= trongly varying

   throughput for their data flows, especially w= ith respect to periods

   of very low throughput or even starvation (i.= e., long interruptions

   due to excessive packet loss).

NEW

   A Lower Effort PHB is applicable for many app= lications that

   otherwise use best-effort delivery.  Mor= e specifically, it is

   suitable for traffic and services that can to= lerate strongly

   varying throughput for their data flows, espe= cially periods

   of very low throughput or even starvation (i.= e., long interruptions

   due to significant or even complete packet lo= ss).

 

Minor edits - “most” seems overstated= in first sentence.

 

OLD

   nor should packets be "downgraded" = to the LE PHB used as a

   substitute for dropping packets that ought si= mply to be dropped as

   unauthorized.

NEW

   nor should packets be "downgraded" = to the LE PHB instead of being

   dropped, particularly when the packets are un= authorized traffic.

 

Editorial

 

   The LE PHB is expected to have applicability = in

   networks that have at least some unused capac= ity at some times of

   day.

 

Just times of day, or also days of the week, holi= days, etc.?   I suggest generalizing this text.

 

OLD

   The LE PHB allows networks to protect themsel= ves from selected types

   of traffic rather than giving a selected traf= fic aggregate

   preferential treatment.  Moreover, the L= E PHB may also exploit all

   unused resources from other PHBs.<= /span>

NEW

   The LE PHB allows networks to protect themsel= ves from selected types

   of traffic as a complement to giving preferen= tial treatment to other

   selected traffic aggregates.  Moreover, = the LE PHB may take advantage

   of network resources unused by other PHBs.

 

Editorial

 

OLD

   There is no intrinsic reason to limit the app= licability of the LE PHB

   to any particular application or type of traf= fic.  It is intended as

   an additional tool for administrators in engi= neering networks.  For

   instance, it can be used for filling up prote= ction capacity of

   transmission links which is otherwise unused.=   Some network providers

   keep link utilization below 50% in order to b= eing able carrying all

   traffic without loss in case of rerouting due= to a link failure.

NEW

   There is no intrinsic reason to limit the app= licability of the LE PHB

   to any particular application or type of traf= fic.  It is intended as

   an additional traffic engineering tool for ne= twork administrators.

  For instance, it can be used to fill protectio= n capacity of

   transmission links that is otherwise unused.&= nbsp; Some network providers

   keep link utilization below 50% to ensure tha= t all traffic without

   loss after rerouting caused by a link failure= .

 

“engineering” -> “traffic engin= eering” is important, all other changes are editorial.

 

 

  Example uses for the LE PHB comprise:


Delete “comprise”

 

** The last bullet in Section 1.1. contains some = discussion of “downgraded” that goes beyond an example, and oug= ht to be merged into the last paragraph on p.3.

 

-- Section 1.2

 

First bullet: “has got” -> “= has”

 

** I wonder whether the 2nd and 3rd bullets are o= verstated.  There is some network switch/router configuration required= and something like a low priority queue has to be set up to drop LE traffi= c when there are other competing uses.   I don’t think the bullets are actually wrong, but some additional te= xt to point out what does have to be done to use the LE PHB would be helpfu= l.

 

-- Section 2

 

OLD

  Ideally, LE packets SHOULD be forwarded only i= f no best-

   effort packet is waiting for its transmission= .

NEW

   Ideally, LE packets SHOULD be forwarded only = if no packet

   with any other PHB is awaiting transmission.<= o:p>

 

Understated - should apply to all PHBs, not just = default.

 

-- Section 3

 

**** First paragraph needs some attention as it s= eems to switch back and forth between networks in general (LE causes effect= s that are best-effort at worst) and networks with full support for LE (las= t sentence recommending no boundary policing assumes that LE is preferentially dropped wrt all other PHBs at a= ll bottlenecks).  At a  minimum, a network that forwards LE as De= fault, needs to treat LE traffic as part of a Traffic Aggregate that is at = least LE + Default and police that appropriately at the edge.   In general, I suggest thinking carefully about se= parating statements that apply to all networks (with and degree or absence = of LE PHB support) from those that apply to networks with full LE support a= t every possible bottleneck (warning: this can be subtle, e.g.,  there may be an L2 link bottleneck that doesn&#= 8217;t understand the LE vs. Default distinction for IP traffic).

   Non-LE traffic (e.g., BE traffic) SHOULD not = be remarked to LE on a

   regular basis without consent or knowledge of= the user.

 

“SHOULD not” -> SHOULD NOT”<= o:p>

Also, this text  feels like it’s part = of the “downgrade” discussion at the end of p.3, and at least o= ught to point back to that.

 

--Section 5

 

   A DS domain that still uses DSCP CS1 for mark= ing LE traffic

   (including Low Priority-Data as defined in [<= a href=3D"https://tools.ietf.org/html/rfc4594" title=3D""Configuration= Guidelines for DiffServ Service Classes"">= RFC4594] or the old

   definition in [RFC3662= ]) MUST remark traffic to the LE DSCP '000010'

   at the egress to the next DS domain.

 

****I definitely want to see broader WG discussio= n of that “MUST remark” requirement, as it’s not backward= s compatible with RFC 4594 - at a minimum, some thought should be applied t= o transition and mixing networks that use CS1 and the new LE DSCP.

 

--Section 7

 

** (entire set of comments on Section 7)

 

IANA Considerations need to tell IANA what Name t= o use for the codepoint (LE) and what to use as a Reference (this document)= .    In general, when assigning a field from an existing reg= istry, check the columns that IANA will need to fill in and supply contents.

 

This section will need some editing, as the ̶= 0;Standards Action” of this memo is what assigns that codepoint. = ; Suggestion:

 

   This document assigns the Differenti= ated Services  Field Codepoint (DSCP)

   '000010' from the Differentiated Ser= vices  Field Codepoints (DSCP) registry

   (https://www.iana.org/assignments/= dscp-registry/dscp-registry.xml) to the

   LE PHB.  IANA is requested to u= pdate the registry as follows:

        &= nbsp;       - Name: LE

        &= nbsp;       - Codepoint: 000010

        &= nbsp;       - Reference: [RFC number of this = memo]

 

Also, I just notice that the header on the middle= column of the IANA registry is “Space” - it should be “C= odepoint”:

 

   IANA is also requested to correct th= e header of the middle column

   of the Pool 1  Codepoints table= in that registry by changing it from

   “Space” to “Codepo= int”.

 

-- Section 8

 

** Mention of traffic “downgraded” to= LE seems to conflict with recommendations not to downgrade elsewhere.=

 

</WG chair hat OFF>

 

Thanks, --David

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

David L. Black, Distinguished Engineer=

Dell EMC, 176 South St., Hopkinton, MA  0174= 8

+1 (508) 293-7953     Cel= l: +1 (978) 394-7754

David.Black@dell.com  <=3D=3D=3D NEW =3D= =3D=3D

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

 

 

--_000_CE03DB3D7B45C245BCA0D243277949362F8DD52BMX307CL04corpem_-- From nobody Mon Mar 6 10:01:03 2017 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 6A7EF1294BE for ; Mon, 6 Mar 2017 10:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BBfK5e0sjRNU for ; Mon, 6 Mar 2017 10:01:00 -0800 (PST) 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 C29121294A3 for ; Mon, 6 Mar 2017 10:01:00 -0800 (PST) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:408:2082:8a9b:529]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A4B461B01468 for ; Mon, 6 Mar 2017 19:58:42 +0000 (GMT) References: <52FCE567.5020502@erg.abdn.ac.uk> To: tsvwg WG From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <2415382e-004c-7db9-bd1a-08656f79315f@erg.abdn.ac.uk> Date: Mon, 6 Mar 2017 18:00:59 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <52FCE567.5020502@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Please send TSVWG Agenda requests for the IETF in Chicago (March 2017) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:01:02 -0000 TSVWG has two slots allocated for the Chicago IETF. If you have a draft that you have revised recently and would like to see this discussed at the meeting in Chicago, please send your request for agenda time to the tsvwg chairs (tsvwg-chairs@ietf.org). Please include in the request, the title and file name of the draft, the speaker's name (and email), and how much time you think you will need. Please embed the name of this WG in any new draft submissions. We will prioritise drafts that are working group items and also drafts that have been actively discussed on the list. Drafts not discussed on the mailing list prior to the meeting, or drafts that do not appear to yet have support from the working group are unlikely to get time at the meeting. If you have any questions or doubts, please do contact the chairs, Regards, Gorry, Wes & David (TSVWG Co-Chairs) tsvwg-chairs@ietf.org From nobody Tue Mar 7 14:16:48 2017 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 610A4129602; Tue, 7 Mar 2017 14:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 J1N5XRUqnld0; Tue, 7 Mar 2017 14:16:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2ACB12951A; Tue, 7 Mar 2017 14:16:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 58687B81999; Tue, 7 Mar 2017 14:16:20 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170307221620.58687B81999@rfc-editor.org> Date: Tue, 7 Mar 2017 14:16:20 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] BCP 208, RFC 8084 on Network Transport Circuit Breakers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:16:34 -0000 A new Request for Comments is now available in online RFC libraries. BCP 208 RFC 8084 Title: Network Transport Circuit Breakers Author: G. Fairhurst Status: Best Current Practice Stream: IETF Date: March 2017 Mailbox: gorry@erg.abdn.ac.uk Pages: 24 Characters: 61712 See Also: BCP 208 I-D Tag: draft-ietf-tsvwg-circuit-breaker-15.txt URL: https://www.rfc-editor.org/info/rfc8084 DOI: 10.17487/RFC8084 This document explains what is meant by the term "network transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Mar 7 14:17:46 2017 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 15E83129607; Tue, 7 Mar 2017 14:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 JBW0iqGCf-nA; Tue, 7 Mar 2017 14:17:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89281295FD; Tue, 7 Mar 2017 14:17:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3DBA1B819A0; Tue, 7 Mar 2017 14:17:37 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170307221737.3DBA1B819A0@rfc-editor.org> Date: Tue, 7 Mar 2017 14:17:37 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] BCP 145, RFC 8085 on UDP Usage Guidelines X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:17:41 -0000 A new Request for Comments is now available in online RFC libraries. BCP 145 RFC 8085 Title: UDP Usage Guidelines Author: L. Eggert, G. Fairhurst, G. Shepherd Status: Best Current Practice Stream: IETF Date: March 2017 Mailbox: lars@netapp.com, gorry@erg.abdn.ac.uk, gjshep@gmail.com Pages: 55 Characters: 145359 Obsoletes: RFC 5405 See Also: BCP 145 I-D Tag: draft-ietf-tsvwg-rfc5405bis-19.txt URL: https://www.rfc-editor.org/info/rfc8085 DOI: 10.17487/RFC8085 The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Mar 7 14:18:25 2017 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 188BE12960D; Tue, 7 Mar 2017 14:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 U_nO1J07raSx; Tue, 7 Mar 2017 14:18:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DAB12962D; Tue, 7 Mar 2017 14:18:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0A9E0B819AB; Tue, 7 Mar 2017 14:18:04 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170307221804.0A9E0B819AB@rfc-editor.org> Date: Tue, 7 Mar 2017 14:18:04 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] RFC 8086 on GRE-in-UDP Encapsulation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:18:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8086 Title: GRE-in-UDP Encapsulation Author: L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert Status: Standards Track Stream: IETF Date: March 2017 Mailbox: lucy.yong@huawei.com, edward.crabbe@gmail.com, xuxiaohu@huawei.com, tom@herbertland.com Pages: 27 Characters: 58743 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-gre-in-udp-encap-19.txt URL: https://www.rfc-editor.org/info/rfc8086 DOI: 10.17487/RFC8086 This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet. This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Mar 8 07:59:02 2017 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 3797112706D for ; Wed, 8 Mar 2017 07:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=wv3ov1it; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=sdFEwhpx 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 INZkU5npeabF for ; Wed, 8 Mar 2017 07:59:00 -0800 (PST) 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 0E0631296D5 for ; Wed, 8 Mar 2017 07:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1488988740; x=1520524740; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Vo/j2Y5/TL2emdXBam/XkNk72IHeA8MjQxTREAbR+nQ=; b=wv3ov1itNkXcgrmimCPYv9tvdIsTigXtueSevtqwpAo77WhYopfGKhGo BrPHZ5SxRO5QMy19DvKl1Ng2I+MaKplSc0PZdhHPHsixkwddtX2faYEv1 hSwWYda/DLi3ixMjHdjVq5AC/Vr0J1f8b0UjyahhqnVV+n65Bsj5XVpsa A=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 09:58:58 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 21:58:58 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v28Fwunb015775 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 Mar 2017 10:58:56 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com v28Fwunb015775 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1488988736; bh=8a9ixYs1pyKaBOBvlFdL/fT5iUg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sdFEwhpxv71o8z2jiLHt8sSlhfjvX8xoXgkO2iGNTmdNalcLnfhYUFFsV1DEsj/uV tGSlYKt8ZyrdCQSC27smuVaYWMEor3cL77tnZbFwjXEBxf46SHwHYIw85/0BFVLILF qf5lvjieedbNUYQ3x9ueeSFdrWGTKh+QRkdej4tQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com v28Fwunb015775 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Wed, 8 Mar 2017 10:58:33 -0500 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v28FwcVN017094 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Wed, 8 Mar 2017 10:58:38 -0500 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.0266.001; Wed, 8 Mar 2017 10:58:37 -0500 To: "tsvwg@ietf.org" Thread-Topic: 3 (!) new TSVWG RFCs Thread-Index: AdKYJNjAdMx/DWc6SjytNOmumygZFw== Date: Wed, 8 Mar 2017 15:58:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.139] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] 3 (!) new TSVWG RFCs X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:59:01 -0000 Late yesterday, three RFCs were published based on TSVWG work: - BCP 208, RFC 8084 on Network Transport Circuit Breakers - BCP 145, RFC 8085 on UDP Usage Guidelines - RFC 8086 on GRE-in-UDP Encapsulation I want to congratulate and thank the authors for all of their hard work, as= all three documents are significant and important: - Network Transport Circuit Breakers are a new protocol design element/con= sideration that has broad applicability. - UDP Usage Guidelines updates and expands this important material to addr= ess increased UDP usage in protocol design. - GRE-in-UDP is the second of two important worked examples of UDP encapsu= lation; the first was MPLS-in-UDP. All three RFCs are likely to be influential on future protocol designs. Many thanks to the authors and everyone who contributed! Thanks, --David -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- From nobody Wed Mar 8 13:26:06 2017 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 92442129510; Wed, 8 Mar 2017 13:26:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148900836057.20187.960931026877662314@ietfa.amsl.com> Date: Wed, 08 Mar 2017 13:26:00 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:26:00 -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 of the IETF. Title : Explicit Congestion Notification (ECN) Experimentation Author : David Black Filename : draft-ietf-tsvwg-ecn-experimentation-01.txt Pages : 15 Date : 2017-03-08 Abstract: Multiple protocol experiments have been proposed that involve changes to Explicit Congestion Notification (ECN) as specified in RFC 3168. This memo summarizes the proposed areas of experimentation to provide an overview to the Internet community and updates RFC 3168, a Proposed Standard RFC, to allow the experiments to proceed without requiring a standards process exception for each Experimental RFC to update RFC 3168. Each experiment is still required to be documented in an Experimental RFC. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and to the ECN specifications for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic to enable new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-01 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 Mar 8 13:30:15 2017 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 26DF61295DD for ; Wed, 8 Mar 2017 13:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=L8EsuRQf; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=sAkRX2fv 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 oxaYMJ7ZmZGd for ; Wed, 8 Mar 2017 13:30:12 -0800 (PST) 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 990941295E6 for ; Wed, 8 Mar 2017 13:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1489008612; x=1520544612; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w2eackpmXxHCfbnnaGGPlbojPB1GCug16Qz3+ZTVnUQ=; b=L8EsuRQfNgPCvC9f1e/0fzYws8SXmsiNFC8lZNswplFOuBjnEGnMB7vG Y0f8pSQ63y74R85SmUOeGX94+qxkNHaXb68SUv55Zl4QABn15AxU105Kj FYDVrGMi0+jhBWDKJCTWi0PEL8O3L6ilVVaYWOuJrIHOSVIzEDhhB/5q3 o=; 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 Mar 2017 15:30:11 -0600 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; 09 Mar 2017 03:27:55 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v28LU9XM021102 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 8 Mar 2017 16:30:10 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v28LU9XM021102 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1489008610; bh=td+w4W+jzBQQHIsw9NPzq4IqPkI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=sAkRX2fvvlydRYPeELH31vyC3sz0SfAFLnQW/Fwxpu0/JGHnScXjzpQV8IWnNYo43 zX/cKQ851NQO7XKqHTZe5NYtm9hcPzr9etQsZyyc5jWHTAh1IOYiSXuAbJRD0aR6jx Al7MPxgnlPsBiFJWbAmOsneT2BtvTCTu4abYgXfk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v28LU9XM021102 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Wed, 8 Mar 2017 16:29:50 -0500 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v28LTsdg008897 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 8 Mar 2017 16:29:55 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Wed, 8 Mar 2017 16:29:54 -0500 To: "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-ietf-tsvwg-ecn-experimentation-01.txt Thread-Index: AQHSmFKj+gsZtjYTr0y/xJf6l+dN1aGLdMxw Date: Wed, 8 Mar 2017 21:29:53 +0000 Message-ID: References: <148900836057.20187.960931026877662314@ietfa.amsl.com> In-Reply-To: <148900836057.20187.960931026877662314@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:30:14 -0000 This minor -01 update adds a sentence on the possibility of DCTCP experimen= tation along with a reference to the DCTCP draft Credit and thanks to Kare= n Nielsen for suggesting this addition. This draft is likely to be headed = for Working Group Last Call not too long after Chicago, so now might be a g= ood time to put it on your reading list ;-). Thanks, --David (as draft author) > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, March 08, 2017 4:26 PM > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: I-D Action: draft-ietf-tsvwg-ecn-experimentation-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Transport Area Working Group of the IETF= . >=20 > Title : Explicit Congestion Notification (ECN) Experime= ntation > Author : David Black > Filename : draft-ietf-tsvwg-ecn-experimentation-01.txt > Pages : 15 > Date : 2017-03-08 >=20 > Abstract: > Multiple protocol experiments have been proposed that involve changes > to Explicit Congestion Notification (ECN) as specified in RFC 3168. > This memo summarizes the proposed areas of experimentation to provide > an overview to the Internet community and updates RFC 3168, a > Proposed Standard RFC, to allow the experiments to proceed without > requiring a standards process exception for each Experimental RFC to > update RFC 3168. Each experiment is still required to be documented > in an Experimental RFC. In addition, this memo makes related updates > to the ECN specifications for RTP in RFC 6679 and to the ECN > specifications for DCCP in RFC 4341, RFC 4342 and RFC 5622. This > memo also records the conclusion of the ECN Nonce experiment in RFC > 3540, obsoletes RFC 3540 and reclassifies it as Historic to enable > new experimental use of the ECT(1) codepoint. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn-experimentation-= 01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Mar 9 18:36:47 2017 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 CDD9A1294CA; Thu, 9 Mar 2017 18:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 arvS1_Gh-eNq; Thu, 9 Mar 2017 18:36:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18AF12943B; Thu, 9 Mar 2017 18:36:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9B96AB8020A; Thu, 9 Mar 2017 18:06:31 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170310020631.9B96AB8020A@rfc-editor.org> Date: Thu, 9 Mar 2017 18:06:31 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] RFC 8100 on Diffserv-Interconnection Classes and Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:36:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8100 Title: Diffserv-Interconnection Classes and Practice Author: R. Geib, Ed., D. Black Status: Informational Stream: IETF Date: March 2017 Mailbox: Ruediger.Geib@telekom.de, david.black@dell.com Pages: 21 Characters: 50264 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-diffserv-intercon-14.txt URL: https://www.rfc-editor.org/info/rfc8100 DOI: 10.17487/RFC8100 This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS. This document is a product of the Transport Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From shweta.k.r@huawei.com Fri Mar 10 03:53:56 2017 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 83D7412954A for ; Fri, 10 Mar 2017 03:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 eXk6lOMJhsgr for ; Fri, 10 Mar 2017 03:53:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACA6129445 for ; Fri, 10 Mar 2017 03:53:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCO31567; Fri, 10 Mar 2017 11:53:50 +0000 (GMT) Received: from SZXEMI411-HUB.china.huawei.com (10.86.210.34) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 10 Mar 2017 11:53:48 +0000 Received: from SZXEMI503-MBX.china.huawei.com ([169.254.7.4]) by szxemi411-hub.china.huawei.com ([10.86.210.34]) with mapi id 14.03.0235.001; Fri, 10 Mar 2017 19:53:37 +0800 From: Shweta r To: "tsvwg@ietf.org" Thread-Topic: Query regarding sending ABORT in SCTP RFC 4960 Thread-Index: AdKZlPK4BnGXIpDtRyKQ4HhZnmHerA== Date: Fri, 10 Mar 2017 11:53:36 +0000 Message-ID: <421CE35A2FDF994790546C7F50F875455DF4566B@SZXEMI503-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.208.102] Content-Type: multipart/alternative; boundary="_000_421CE35A2FDF994790546C7F50F875455DF4566BSZXEMI503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58C293CE.0241, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.4, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7aa73cc34413799e65ee165899233787 Archived-At: X-Mailman-Approved-At: Fri, 10 Mar 2017 05:58:08 -0800 Cc: Sharath Chandra B , Ashutosh prakash Subject: [tsvwg] Query regarding sending ABORT in SCTP RFC 4960 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:04:04 -0000 --_000_421CE35A2FDF994790546C7F50F875455DF4566BSZXEMI503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Group, Greetings. I have a doubt regarding SCTP RFC 4960, section "9.1. Abort of = an Association". Doubt 1: 1) Section 3.3.2. Initiation (INIT) (1) If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT. --> Here clearly it is written to close the association when sending = ABORT 2)Section 5.1. Normal Establishment of an Association If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer. -->When the endpoint is client and receives INIT-ACK with invalid parameter= , it should send only ABORT and don't disturb the existing association or stack should send ABORT and close the association ? Doubt 2 : 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged), provided that no NEW address has been added to the forming association. If the INIT message indicates that a new address has been added to the association, then the entire INIT MUST be discarded, and NO changes should be made to the existing association. An ABORT SHOULD be sent in response that MAY include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association. ---> Other than the scenarios of new address adding, in all other cases, se= nding ABORT means send ABORT and close the existing association ? Regards Shweta --_000_421CE35A2FDF994790546C7F50F875455DF4566BSZXEMI503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Group,

 

Greetings. I have a doubt regarding SCTP RFC 4960, s= ection “9.1.  Abort of an Association”.

 

Doubt 1:

 

1) Section 3.3.2.  Initiation (INIT) (1)

 

      If the value of the I= nitiate Tag in a received INIT chunk is found

      to be 0, the receiver= MUST treat it as an error and close the

      association by transm= itting an ABORT.

     

      --> Here clea= rly it is written to close the association when sending ABORT

     

      

2)Section 5.1.  Normal Establishment of an Asso= ciation

 

   If an endpoint receives an INIT, INIT A= CK, or COOKIE ECHO chunk but

   decides not to establish the new associ= ation due to missing mandatory

   parameters in the received INIT or INIT= ACK, invalid parameter

   values, or lack of local resources, it = SHOULD respond with an ABORT

   chunk.  It SHOULD also specify the= cause of abort, such as the type

   of the missing mandatory parameters, et= c., by including the error

   cause parameters with the ABORT chunk.&= nbsp; The Verification Tag field in

   the common header of the outbound SCTP = packet containing the ABORT

   chunk MUST be set to the Initiate Tag v= alue of the peer.

 

-->When the endpoint is client and receives INIT-= ACK with invalid parameter, it should send only ABORT and don’t distu= rb the existing association   

    or stack should send ABORT a= nd close the association  ?

  

    

    

Doubt 2 :

 

5.2.1.  INIT Received in COOKIE-WAIT or COOKIE-= ECHOED State (Item B)

 

Upon receipt of an INIT in the COOKIE-ECHOED state, = an endpoint MUST

   respond with an INIT ACK using the same= parameters it sent in its

   original INIT chunk (including its Init= iate Tag, unchanged), provided

   that no NEW address has been added to t= he forming association.  If

   the INIT message indicates that a new a= ddress has been added to the

   association, then the entire INIT MUST = be discarded, and NO changes

   should be made to the existing associat= ion.  An ABORT SHOULD be sent

   in response that MAY include the error = 'Restart of an association

   with new addresses'.  The error SH= OULD list the addresses that were

   added to the restarting association.

 

 

---> Other than the scenarios of new address addi= ng, in all other cases, sending ABORT means send ABORT and  close the = existing association ?

 


Regards

Shweta

--_000_421CE35A2FDF994790546C7F50F875455DF4566BSZXEMI503MBXchi_-- From nobody Fri Mar 10 13:18:59 2017 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 4A40312946E for ; Fri, 10 Mar 2017 13:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 x9lHlemAzBdE for ; Fri, 10 Mar 2017 13:18:51 -0800 (PST) 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 4409C129452 for ; Fri, 10 Mar 2017 13:18:51 -0800 (PST) Received: from [IPv6:2003:cd:6bd5:6500:708f:b8fb:2d98:5267] (p200300CD6BD56500708FB8FB2D985267.dip0.t-ipconnect.de [IPv6:2003:cd:6bd5:6500:708f:b8fb:2d98:5267]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 641AE721E281A; Fri, 10 Mar 2017 22:18:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <421CE35A2FDF994790546C7F50F875455DF4566B@SZXEMI503-MBX.china.huawei.com> Date: Fri, 10 Mar 2017 22:18:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <421CE35A2FDF994790546C7F50F875455DF4566B@SZXEMI503-MBX.china.huawei.com> To: Shweta r X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Sharath Chandra B , Ashutosh prakash , "tsvwg@ietf.org" Subject: Re: [tsvwg] Query regarding sending ABORT in SCTP RFC 4960 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 21:18:58 -0000 > On 10 Mar 2017, at 12:53, Shweta r wrote: >=20 > Hi Group, > =20 > Greetings. I have a doubt regarding SCTP RFC 4960, section =E2=80=9C9.1.= Abort of an Association=E2=80=9D. > =20 > Doubt 1: > =20 > 1) Section 3.3.2. Initiation (INIT) (1) > =20 > If the value of the Initiate Tag in a received INIT chunk is = found > to be 0, the receiver MUST treat it as an error and close the > association by transmitting an ABORT. > =20 > --> Here clearly it is written to close the association when = sending ABORT Yepp. > =20 > =20 > 2)Section 5.1. Normal Establishment of an Association > =20 > If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but > decides not to establish the new association due to missing = mandatory > parameters in the received INIT or INIT ACK, invalid parameter > values, or lack of local resources, it SHOULD respond with an ABORT > chunk. It SHOULD also specify the cause of abort, such as the type > of the missing mandatory parameters, etc., by including the error > cause parameters with the ABORT chunk. The Verification Tag field = in > the common header of the outbound SCTP packet containing the ABORT > chunk MUST be set to the Initiate Tag value of the peer. > =20 > -->When the endpoint is client and receives INIT-ACK with invalid = parameter, it should send only ABORT and don=E2=80=99t disturb the = existing association =20 > or stack should send ABORT and close the association ? The text doesn't describe whether the receiver of an INIT-ACK with an = invalid parameter has to stop the association setup procedure or can continue with it. So an endpoint could just drop the INIT-ACK and retransmit the INIT in = the hope that the next INIT-ACK is better. But if the endpoint decides not to = establish the association, sending an ABORT is a good thing. > =20 > =20 > =20 > Doubt 2 : > =20 > 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) > =20 > Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST > respond with an INIT ACK using the same parameters it sent in its > original INIT chunk (including its Initiate Tag, unchanged), = provided > that no NEW address has been added to the forming association. If > the INIT message indicates that a new address has been added to the > association, then the entire INIT MUST be discarded, and NO changes > should be made to the existing association. An ABORT SHOULD be = sent > in response that MAY include the error 'Restart of an association > with new addresses'. The error SHOULD list the addresses that were > added to the restarting association. > =20 > =20 > ---> Other than the scenarios of new address adding, in all other = cases, sending ABORT means send ABORT and close the existing = association ? I guess so... Best regards Michael > =20 >=20 > Regards > Shweta From nobody Sun Mar 12 15:15:49 2017 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 A784312945F for ; Sun, 12 Mar 2017 15:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 57h1CiKXe_cq for ; Sun, 12 Mar 2017 15:15:46 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5DF126D74 for ; Sun, 12 Mar 2017 15:15:45 -0700 (PDT) Received: from [192.168.1.121] (p57BB464E.dip0.t-ipconnect.de [87.187.70.78]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7286C721E281A; Sun, 12 Mar 2017 23:15:41 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <9356BD96-203C-49B9-B1E0-4788499959FD@ifi.uio.no> Date: Sun, 12 Mar 2017 23:15:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7104608B-AF21-45D8-8ADC-85C597676554@lurchi.franken.de> References: <9356BD96-203C-49B9-B1E0-4788499959FD@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3259) Archived-At: Cc: tsvwg IETF list Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 22:15:48 -0000 > On 14 Dec 2016, at 14:08, Michael Welzl wrote: >=20 > Hi all, >=20 > I also read the document now. 90% editorial / nits below. > I do think this is a very valuable document! (hence also my comment: = why does the text say that this is =E2=80=9Coff by default=E2=80=9D ?) Hi Michael, thank you very much for your review. See my comments in-line. Best regards Michael >=20 >=20 > Cheers, > Michael >=20 >=20 > --- >=20 > Shouldn't it say "arbitrarily" in: >=20 > "The Stream Control Transmission Protocol (SCTP) is a message oriented > transport protocol supporting arbitrary large user messages." Fixed.=20 >=20 >=20 > 1.1: I think this misses ", this can" after the reference to RFC4960: > "When such large messages are sent over > SCTP as specified in [RFC4960] can result in a form..." It was already fixed by using: The sending of such large messages over SCTP as specified in can result in a form >=20 >=20 > It should be "Figure 1" or "The following figure", I think, in: > " The following Figure 1 illustrates the behaviour of a round robin > stream scheduler using DATA chunks." Fixed by using "Figure 1". >=20 > Fig.1 and fig.2: I'm guessing that SID is Stream Identifier? I don't = think it's defined / explained before the figure, it wouldn't hurt to = remind the reader what that means. I expected it to be defined in = RFC4960 at least, but the abbreviation list there doesn't contain "SID" = either. Added a clarification: illustrates the behaviour of a round = robin stream scheduler using DATA chunks when three streams with the Stream Identifiers (SIDs) 0, 1, and 2 are used. >=20 > Suggest to remove comma after "should be noted" in: > "It should be > noted, that an SCTP implementation needs to support the coexistence > of associations using DATA chunks and associations using I-DATA > chunks." Fixed. >=20 > section 2.2.2: > "Please note" strikes me as a bit odd for an RFC, here: > "Please note that this is the only form of interleaving support." Hmm. We have used it also in other RFCs. For example in the second = paragraph of https://tools.ietf.org/html/rfc6525#section-6 Will keep it for now. >=20 > This sentence seems a bit broken: > " Upon reception of an SCTP packet containing an I-DATA chunk if the > message needs to be reassembled, then the receiver MUST use the FSN > for reassembly of the message and not the TSN. " > I'd fix this to: "If, upon reception of ...., the message needs..." The issue is already fixed by using: Upon reception of an SCTP packet containing an I-DATA chunk whose user message needs to be reassembled, the receiver MUST use the FSN for reassembly of the message and not the TSN. >=20 > 2.3.1: missing "to" after "refers" in: > "The U bit specifies if the Message Identifier of this entry refers > unordered messages" Fixed. >=20 >=20 > sec 3: "The set > of schedulers being implemented is implementation dependent.=E2=80=9D > this seems a little odd to me. Maybe this is the place for clearer, = 2119-style language? To say that the following is a set of possible = schedulers, any of them MAY be implemented? >=20 > sec 3.3: this description isn=E2=80=99t clear enough, I think - the = use of =E2=80=9Cbundles=E2=80=9D here confuses me=E2=80=A6 not sure how = this should be implemented? You basically switch only to a new stream when you start a new packet. = This ensures that only one stream is affected by a packet loss. Any suggestion on how = to improve the text? >=20 > 3.4: again, the use of =E2=80=9Cimplementation specific=E2=80=9D here = seems strange - I=E2=80=99d rather say: =E2=80=9C, =E2=80=A6 any form of = scheduling between them MAY be used.=E2=80=9D OK. Changed to An implementation MAY implement any subset of them. >=20 > Much here is a bit vague=E2=80=A6 e.g. in 3.6: > "schedules them in a certain way to use the bandwidth according to the = given weights. The details are implementation specific.=E2=80=9D >=20 > I understand that you don=E2=80=99t want to prescribe details on how = to implement the WFQ scheduler, but =E2=80=9Cin a certain way to us the = bandwidth according to the given weights=E2=80=9D doesn=E2=80=99t even = precisely prescribe the resulting behavior. If you leave both the = implementation and the resulting behavior open, this section may be = worthless? > To be clearer about my concern: the priorities could, for example, be = linear or exponential. E.g., priority 3 could mean 3 times as much = bandwidth as priority 1. But, for example, = https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17#section-4.1 = specifies this differently: =E2=80=9C... SHOULD cause data to be emitted = in such a way that each stream at each level of priority is being given = approximately twice the transmission capacity (measured in payload = bytes) of the level below.=E2=80=9D So, IMO, the precise meaning of = priorities must be clear from the text in this draft. Right. I added: If the weight of stream S1 is n times the weight of stream S2, the scheduler should assign to stream S1 n times the bandwidth it assigns to stream S2. >=20 > Summarizing for section 3, it would be good to add an example = illustrating the expected behavior (a bit like Fig.1) for each of the = schedulers. I think this is hard to do and would over-specify the scheduler. = Therefore I'm not adding them. >=20 > Also: as shown by figure 1, these stream schedulers can operate = without interleaving too. This doesn=E2=80=99t get very clear =E2=80=A6 = the introduction should explain that this document also describes stream = schedulers, how they are exposed in the sockets API, and how they would = operate with and without interleaving. Yes. I changed the text in the introduction to read: This document also defines several stream schedulers for general SCTP associations. They can be used with and without user message = interleaving being negotiated and possibly behave differently. >=20 > Section 4.3.1 says: " User message interleaving is disabled per = default.=E2=80=9D > Isn=E2=80=99t this a bad idea? This just seems to me to make things = better, what=E2=80=99s the reason not to always use it? > Come to think of it - if there indeed is a trade-off here, a good = reason to sometimes *not* use this mechanism, this should be explained, = probably in the introduction. > (I could only think of slightly more header overhead - is this such a = big deal?) I added the following text to explain why it is off by default. Since = this is a API argument it belongs here. If you have an implementation with a different API, you = might enable it by default. I moved the text specifying the default down after the discussion of the = fragment interleave level and added there: Since the default fragment interleave level is not 2, user message = interleaving is disabled per default. >=20 > 4.3.2: is this possible with or without interleaving? I=E2=80=99d = guess it=E2=80=99s possible without, but it would be nice to have this = explicit, as somehow this whole document reads as if it=E2=80=99s really = about interleaving. Sure. There is no restriction. Only the schedulers behave differently = when user message interleaving has been negotiated as indicated in the text describing each scheduler. >=20 >=20 From nobody Mon Mar 13 00:21:18 2017 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 B32D2129424 for ; Mon, 13 Mar 2017 00:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 wOP3QgN66ROL for ; Mon, 13 Mar 2017 00:21:14 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC53126B6D for ; Mon, 13 Mar 2017 00:21:13 -0700 (PDT) Received: from [192.168.1.121] (p57BB464E.dip0.t-ipconnect.de [87.187.70.78]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id D0366721E281E; Mon, 13 Mar 2017 08:21:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: Date: Mon, 13 Mar 2017 08:21:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Proshin, Maksim" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:21:17 -0000 > On 19 Dec 2016, at 17:16, Proshin, Maksim wrote: >=20 > Hi, >=20 > Thanks for the document! Please find below some comments. Only major = comments are included while editorial/minor comments have been sent = directly to Michael. Hi Maxim, thanks a lot for the review. I addresses the minor comments and = responded to your mail. See my comments in-line. Best regards Michael >=20 > 1. Section 1.1: "DATA chunks are not > permitted when I-DATA support has been negotiated." > What exactly does it mean for implementation (both sending and = receiving sides)? I think to avoid any problems with the sending side it = should be "MUST NOT" in the sentence. For the receiving side I suppose = it means stop processing of the packet and silently discard all further = chunks in the packet, right? I think this should be clearly stated. It = could also be good to clearly state that after association restart which = was with DATA previously but became with I-DATA after the restart, SCTP = still may receive packets with DATA and they should be silently = discarded due to VTag mismatch following the rules of Section 8.5. from = RFC4960 (I suppose this is important to avoid any "protocol violation" = reaction).=20 >=20 > 2. Section 2.1:=20 > The only differences between the I-DATA chunk in Figure 3 and the > DATA chunk defined in [RFC4960] and [RFC7053] is the addition of = the > new Message Identifier (MID) and Fragment Sequence Number (FSN) and > the removal of the Stream Sequence Number (SSN). > The B bit now has a different (extended) purpose and also specifies if = PPID or FSN is used. I think it should be stated. > =20 > 3. I suppose the draft assumes that SCTP still MAY (i.e. not = SHOULD/MUST) support fragmentation even with I-DATA and MUST (i.e. not = MAY/SHOULD) support re-assembling. If so, I suggest to clearly state it. >=20 > 4. Is RFC6096 impacted by new chunks? No. It only deals with old chunks. When defining a new chunk, you have = to define the corresponding flags registry as we do in this document. >=20 > 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated = during the SCTP > association setup via the Supported Extensions Parameter as defined > in [RFC5061]. Only if both end points support the I-DATA chunk and > the I-FORWARD-TSN chunk, the partial reliability extension can be > used in combination with user message interleaving. > Not sure how implementation should behave if either of these chunks is = unsupported. I think it should be clearly stated. > Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the = partial reliability functionality should be completely off, i.e. not = fallback to FORWARD-TSN.=20 > If I-DATA is not supported but I-FORWARD-TSN is supported (strange = implementation but still according to the draft as it does not prohibit = the opposite), it seems both functionalities message interleaving and = partial reliability should be off, i.e. there is no way to fallback to = FORWARD-TSN, right? =20 > Should the draft state something like "If I-DATA chunk is not used, = I-FORWARD-TSN chunk MUST NOT be used."? >=20 > 6. Section 4.1:=20 > MID is 32 bits while SSN is 16 bits so why a new SCTP Receive = Information Structure cannot be introduced instead of using the existing = one? One could add such a structure, but is it needed? > If the new SCTP Receive Information Structure is introduced then a new = message receive function should also be introduced (instead of = recv_msg() ). Is that the main problem? recvmsg() is generic. It doesn't need to be changed. You would add = another CMSG. > Of course, it would also be a problem if the interleaving = functionality requires enabling only on the sender side (see the next = comment).=20 >=20 > 7. Section 4.3.1: > User message interleaving is disabled per default. > I'm not sure about it. First of all I think it should be clearly = stated what does it mean for the sender and for the receiver. > If the intention was that I-DATA is included to INIT and INIT ACK only = when the user enabled this functionality then I think this is not a good = way because then it impacts not only the sender but also the receiver.=20= > In other words, if the feature is disabled by default on both sides = while SCTP on both sides support it then it is not enough to just enable = it on one side, it requires enabling it on the other side. =20 Exactly. I think this is stated in the first sentence of 2.2.1. >=20 > 7. Section 4.3.1: Why don't specify exactly value 1 for the enabled = feature? Otherwise, in the future it will be difficult to use another = value of this parameter for a different purpose as it will be = non-backward compatible (old application and new SCTP may work = improperly). Since it is the standard way of encoding a flag in an int... >=20 > 8. Section 5 does not cover I-FORWARD-TSN. Good point. I added corresponding text. > =20 > 9. Section 6: In case of DTLS over SCTP support of the message = interleaving functionality may increase the risk of receiving messages = with new epoch after ChangeCipherSpec message and before Finished = message. Possibly. But implementations have to deal with it anyway. So what is = the point? >=20 >=20 > BR, Maksim >=20 >> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk: >>=20 >>=20 >> This mail announces a TSVWG Working Group Last Call (WGLC) on: >>=20 >> Stream Schedulers and User Message Interleaving forSCTP >> draft-ietf-tsvwg-sctp-ndata >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata >>=20 >> This WGLC will last for 2 weeks weeks. >>=20 >> Comments should be sent to the tsvwg@ietf.org list, although purely >> editorial comments may be sent directly to the authors. Please cc: = the >> WG chairs at tsvwg-chairs@ietf.org if you would like the chairs to >> track such editorial comments as part of the WGLC process. >>=20 >> No IPR disclosures have been submitted directly on >> draft-ietf-tsvwg-sctp-ndata. >>=20 >> Thanks, >> Gorry >> (TSVWG Co-Chair) From nobody Mon Mar 13 00:23:11 2017 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 1784D1294E0 for ; Mon, 13 Mar 2017 00:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 auzRokai3nkp for ; Mon, 13 Mar 2017 00:23:07 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C77129546 for ; Mon, 13 Mar 2017 00:23:05 -0700 (PDT) Received: from [192.168.1.121] (p57BB464E.dip0.t-ipconnect.de [87.187.70.78]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9DDCC721E281A; Mon, 13 Mar 2017 08:23:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: Date: Mon, 13 Mar 2017 08:23:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Proshin, Maksim" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:23:09 -0000 >=20 Still incomplete, I hit the send button by accident. Will follow up when = the response is complete. Sorry for the noise. Best regards Michael > Hi, >=20 > Thanks for the document! Please find below some comments. Only major = comments are included while editorial/minor comments have been sent = directly to Michael. Hi Maxim, thanks a lot for the review. I addresses the minor comments and = responded to your mail. See my comments in-line. Best regards Michael >=20 > 1. Section 1.1: "DATA chunks are not > permitted when I-DATA support has been negotiated." > What exactly does it mean for implementation (both sending and = receiving sides)? I think to avoid any problems with the sending side it = should be "MUST NOT" in the sentence. For the receiving side I suppose = it means stop processing of the packet and silently discard all further = chunks in the packet, right? I think this should be clearly stated. It = could also be good to clearly state that after association restart which = was with DATA previously but became with I-DATA after the restart, SCTP = still may receive packets with DATA and they should be silently = discarded due to VTag mismatch following the rules of Section 8.5. from = RFC4960 (I suppose this is important to avoid any "protocol violation" = reaction).=20 >=20 > 2. Section 2.1:=20 > The only differences between the I-DATA chunk in Figure 3 and the > DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the > new Message Identifier (MID) and Fragment Sequence Number (FSN) and > the removal of the Stream Sequence Number (SSN). > The B bit now has a different (extended) purpose and also specifies if = PPID or FSN is used. I think it should be stated. >=20 > 3. I suppose the draft assumes that SCTP still MAY (i.e. not = SHOULD/MUST) support fragmentation even with I-DATA and MUST (i.e. not = MAY/SHOULD) support re-assembling. If so, I suggest to clearly state it. >=20 > 4. Is RFC6096 impacted by new chunks? No. It only deals with old chunks. When defining a new chunk, you have = to define the corresponding flags registry as we do in this document. >=20 > 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated = during the SCTP > association setup via the Supported Extensions Parameter as defined > in [RFC5061]. Only if both end points support the I-DATA chunk and > the I-FORWARD-TSN chunk, the partial reliability extension can be > used in combination with user message interleaving. > Not sure how implementation should behave if either of these chunks is = unsupported. I think it should be clearly stated. > Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the = partial reliability functionality should be completely off, i.e. not = fallback to FORWARD-TSN.=20 > If I-DATA is not supported but I-FORWARD-TSN is supported (strange = implementation but still according to the draft as it does not prohibit = the opposite), it seems both functionalities message interleaving and = partial reliability should be off, i.e. there is no way to fallback to = FORWARD-TSN, right? =20 > Should the draft state something like "If I-DATA chunk is not used, = I-FORWARD-TSN chunk MUST NOT be used."? >=20 > 6. Section 4.1:=20 > MID is 32 bits while SSN is 16 bits so why a new SCTP Receive = Information Structure cannot be introduced instead of using the existing = one? One could add such a structure, but is it needed? > If the new SCTP Receive Information Structure is introduced then a new = message receive function should also be introduced (instead of = recv_msg() ). Is that the main problem? recvmsg() is generic. It doesn't need to be changed. You would add = another CMSG. > Of course, it would also be a problem if the interleaving = functionality requires enabling only on the sender side (see the next = comment).=20 >=20 > 7. Section 4.3.1: > User message interleaving is disabled per default. > I'm not sure about it. First of all I think it should be clearly = stated what does it mean for the sender and for the receiver. > If the intention was that I-DATA is included to INIT and INIT ACK only = when the user enabled this functionality then I think this is not a good = way because then it impacts not only the sender but also the receiver.=20= > In other words, if the feature is disabled by default on both sides = while SCTP on both sides support it then it is not enough to just enable = it on one side, it requires enabling it on the other side. =20 Exactly. I think this is stated in the first sentence of 2.2.1. >=20 > 7. Section 4.3.1: Why don't specify exactly value 1 for the enabled = feature? Otherwise, in the future it will be difficult to use another = value of this parameter for a different purpose as it will be = non-backward compatible (old application and new SCTP may work = improperly). Since it is the standard way of encoding a flag in an int... >=20 > 8. Section 5 does not cover I-FORWARD-TSN. Good point. I added corresponding text. >=20 > 9. Section 6: In case of DTLS over SCTP support of the message = interleaving functionality may increase the risk of receiving messages = with new epoch after ChangeCipherSpec message and before Finished = message. Possibly. But implementations have to deal with it anyway. So what is = the point? >=20 >=20 > BR, Maksim >=20 >> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk: >>=20 >>=20 >> This mail announces a TSVWG Working Group Last Call (WGLC) on: >>=20 >> Stream Schedulers and User Message Interleaving forSCTP >> draft-ietf-tsvwg-sctp-ndata >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata >>=20 >> This WGLC will last for 2 weeks weeks. >>=20 >> Comments should be sent to the tsvwg@ietf.org list, although purely >> editorial comments may be sent directly to the authors. Please cc: = the >> WG chairs at tsvwg-chairs@ietf.org if you would like the chairs to >> track such editorial comments as part of the WGLC process. >>=20 >> No IPR disclosures have been submitted directly on >> draft-ietf-tsvwg-sctp-ndata. >>=20 >> Thanks, >> Gorry >> (TSVWG Co-Chair) From nobody Mon Mar 13 01:24:24 2017 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 2AB97129562 for ; Mon, 13 Mar 2017 01:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 PHux_PrMsDSr for ; Mon, 13 Mar 2017 01:24:21 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 2BDD8129561 for ; Mon, 13 Mar 2017 01:24:20 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnLH8-00038W-H4 for tsvwg@ietf.org; Mon, 13 Mar 2017 09:24:18 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx03.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnLH7-00058T-Tc; Mon, 13 Mar 2017 09:24:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <7104608B-AF21-45D8-8ADC-85C597676554@lurchi.franken.de> Date: Mon, 13 Mar 2017 09:24:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AA5997D-C0A3-45B5-84F7-E84102230488@ifi.uio.no> References: <9356BD96-203C-49B9-B1E0-4788499959FD@ifi.uio.no> <7104608B-AF21-45D8-8ADC-85C597676554@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 52621 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.047, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 421C6259CD8FE6C5EFC5B58719E118CF6F6E1220 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12568 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tsvwg IETF list Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 08:24:23 -0000 Hi, > On 12 Mar 2017, at 23:15, Michael Tuexen = wrote: >=20 >> On 14 Dec 2016, at 14:08, Michael Welzl wrote: >>=20 >> Hi all, >>=20 >> I also read the document now. 90% editorial / nits below. >> I do think this is a very valuable document! (hence also my comment: = why does the text say that this is =E2=80=9Coff by default=E2=80=9D ?) > Hi Michael, >=20 > thank you very much for your review. See my comments in-line. I carefully read how you addressed my comments and I'm happy with all of = these fixes. I'm cutting them all away and leaving only one issue here, to answer a = question you ask: >> sec 3.3: this description isn=E2=80=99t clear enough, I think - the = use of =E2=80=9Cbundles=E2=80=9D here confuses me=E2=80=A6 not sure how = this should be implemented? > You basically switch only to a new stream when you start a new packet. = This ensures > that only one stream is affected by a packet loss. Any suggestion on = how to improve the text? I would suggest: OLD: *** This is a round-robin scheduler but bundles only DATA or I-DATA chunks referring to the same stream in a packet. This minimizes head-of-line blocking when a packet is lost because only a single stream is affected. *** NEW: *** This is a round-robin scheduler which only switches streams when starting to fill a new packet. It bundles only DATA or I-DATA chunks referring to the same stream in a packet. This scheduler minimizes head-of-line blocking when a packet is lost because only a single stream is affected. *** Cheers, Michael From nobody Mon Mar 13 02:42:54 2017 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 925CF1294E1 for ; Mon, 13 Mar 2017 02:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 o77k1DKqGJ7D for ; Mon, 13 Mar 2017 02:42:52 -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 4B140129400 for ; Mon, 13 Mar 2017 02:42:52 -0700 (PDT) Received: from [192.168.1.121] (p57BB464E.dip0.t-ipconnect.de [87.187.70.78]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 5C526721E281E; Mon, 13 Mar 2017 10:42:49 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <9AA5997D-C0A3-45B5-84F7-E84102230488@ifi.uio.no> Date: Mon, 13 Mar 2017 10:42:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9356BD96-203C-49B9-B1E0-4788499959FD@ifi.uio.no> <7104608B-AF21-45D8-8ADC-85C597676554@lurchi.franken.de> <9AA5997D-C0A3-45B5-84F7-E84102230488@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3259) Archived-At: Cc: tsvwg IETF list Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:42:53 -0000 > On 13 Mar 2017, at 09:24, Michael Welzl wrote: >=20 > Hi, >=20 >> On 12 Mar 2017, at 23:15, Michael Tuexen = wrote: >>=20 >>> On 14 Dec 2016, at 14:08, Michael Welzl wrote: >>>=20 >>> Hi all, >>>=20 >>> I also read the document now. 90% editorial / nits below. >>> I do think this is a very valuable document! (hence also my = comment: why does the text say that this is =E2=80=9Coff by default=E2=80=9D= ?) >> Hi Michael, >>=20 >> thank you very much for your review. See my comments in-line. >=20 > I carefully read how you addressed my comments and I'm happy with all = of these fixes. > I'm cutting them all away and leaving only one issue here, to answer a = question you ask: >=20 >>> sec 3.3: this description isn=E2=80=99t clear enough, I think - the = use of =E2=80=9Cbundles=E2=80=9D here confuses me=E2=80=A6 not sure how = this should be implemented? >> You basically switch only to a new stream when you start a new = packet. This ensures >> that only one stream is affected by a packet loss. Any suggestion on = how to improve the text? >=20 > I would suggest: >=20 > OLD: > *** > This is a round-robin scheduler but bundles only DATA or I-DATA > chunks referring to the same stream in a packet. This minimizes > head-of-line blocking when a packet is lost because only a single > stream is affected. > *** >=20 > NEW: > *** > This is a round-robin scheduler which only switches streams when > starting to fill a new packet. It bundles only DATA or I-DATA > chunks referring to the same stream in a packet. This scheduler > minimizes head-of-line blocking when a packet is lost because only > a single stream is affected. > *** OK. Text taken. Thank you very much. Best regards Michael >=20 > Cheers, > Michael >=20 From nobody Mon Mar 13 03:59:44 2017 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 042EA12955C for ; Mon, 13 Mar 2017 03:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 iCACSjMWPzia for ; Mon, 13 Mar 2017 03:59:39 -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 0E30B129543 for ; Mon, 13 Mar 2017 03:59:39 -0700 (PDT) Received: from [192.168.1.121] (p57BB464E.dip0.t-ipconnect.de [87.187.70.78]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E9208721E281E; Mon, 13 Mar 2017 11:59:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: Date: Mon, 13 Mar 2017 11:59:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> References: To: "Proshin, Maksim" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:59:42 -0000 > On 19 Dec 2016, at 17:16, Proshin, Maksim wrote: >=20 > Hi, >=20 > Thanks for the document! Please find below some comments. Only major = comments are included while editorial/minor comments have been sent = directly to Michael. Hi Maxim, thanks a lot for the review. I addresses the minor comments and = responded to your mail. See my comments in-line. Best regards Michael >=20 > 1. Section 1.1: "DATA chunks are not > permitted when I-DATA support has been negotiated." > What exactly does it mean for implementation (both sending and = receiving sides)? I think to avoid any problems with the sending side it = should be "MUST NOT" in the sentence. For the receiving side I suppose = it means stop processing of the packet and silently discard all further = chunks in the packet, right? I think this should be clearly stated. It = could also be good to clearly state that after association I think it is clearly stated in 2.2.1: If I-DATA support has been negotiated for an association, I-DATA chunks = MUST be used for all user messages and DATA-chunks MUST NOT be used. If = I-DATA support has not been negotiated for an association, DATA chunks = MUST be used for all user messages and I-DATA chunks MUST NOT be used. So if these rules are violated, I think sending an ABORT with protocol = violation might be appropriate. > restart which was with DATA previously but became with I-DATA after = the restart, SCTP still may receive packets with DATA and they should be = silently discarded due to VTag mismatch following the rules of Section = 8.5. from RFC4960 (I suppose this is important to avoid any "protocol = violation" reaction).=20 Sure. But this is normal restart behaviour. >=20 > 2. Section 2.1:=20 > The only differences between the I-DATA chunk in Figure 3 and the > DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the > new Message Identifier (MID) and Fragment Sequence Number (FSN) and > the removal of the Stream Sequence Number (SSN). > The B bit now has a different (extended) purpose and also specifies if = PPID or FSN is used. I think it should be stated. OK. I added: The Payload Protocol Identifier (PPID) and the FSN are stored at the same location of the packet using the B-bit to determine which value is stored at the location. >=20 > 3. I suppose the draft assumes that SCTP still MAY (i.e. not = SHOULD/MUST) support fragmentation even with I-DATA and MUST (i.e. not = MAY/SHOULD) support re-assembling. If so, I suggest to clearly state it. Yes, this hasn't changed. I think we don't need to repeat this point. = Especially since I have not see an implementation not supporting fragmentation... >=20 > 4. Is RFC6096 impacted by new chunks? No. It only deals with old chunks. When defining a new chunk, you have = to define the corresponding flags registry as we do in this document. >=20 > 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated = during the SCTP > association setup via the Supported Extensions Parameter as defined > in [RFC5061]. Only if both end points support the I-DATA chunk and > the I-FORWARD-TSN chunk, the partial reliability extension can be > used in combination with user message interleaving. > Not sure how implementation should behave if either of these chunks is = unsupported. I think it should be clearly stated. > Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the = partial reliability functionality should be completely off, i.e. not = fallback to FORWARD-TSN.=20 > If I-DATA is not supported but I-FORWARD-TSN is supported (strange = implementation but still according to the draft as it does not prohibit = the opposite), it seems both functionalities message interleaving and = partial reliability should be off, i.e. there is no way to fallback to = FORWARD-TSN, right? =20 Right. > Should the draft state something like "If I-DATA chunk is not used, = I-FORWARD-TSN chunk MUST NOT be used."? There is already text there: The FORWARD-TSN chunk MUST be used in combination with the DATA chunk and MUST NOT be used in combination with the I-DATA chunk. The I- FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk and MUST NOT be used in combination with the DATA chunk. >=20 > 6. Section 4.1:=20 > MID is 32 bits while SSN is 16 bits so why a new SCTP Receive = Information Structure cannot be introduced instead of using the existing = one? One could add such a structure, but is it needed? I don't see a = use-case... > If the new SCTP Receive Information Structure is introduced then a new = message receive function should also be introduced (instead of = recv_msg() ). Is that the main problem? recvmsg() is generic. It doesn't need to be changed. You would add = another CMSG. > Of course, it would also be a problem if the interleaving = functionality requires enabling only on the sender side (see the next = comment). No, it is required to be enabled on both sides. >=20 >=20 > 7. Section 4.3.1: > User message interleaving is disabled per default. > I'm not sure about it. First of all I think it should be clearly = stated what does it mean for the sender and for the receiver. > If the intention was that I-DATA is included to INIT and INIT ACK only = when the user enabled this functionality then I think this is not a good = way because then it impacts not only the sender but also the receiver.=20= > In other words, if the feature is disabled by default on both sides = while SCTP on both sides support it then it is not enough to just enable = it on one side, it requires enabling it on the other side. =20 Exactly. I think this is stated in the first sentence of 2.2.1. >=20 > 7. Section 4.3.1: Why don't specify exactly value 1 for the enabled = feature? Otherwise, in the future it will be difficult to use another = value of this parameter for a different purpose as it will be = non-backward compatible (old application and new SCTP may work = improperly). Since it is the standard way of encoding a flag in an int... >=20 > 8. Section 5 does not cover I-FORWARD-TSN. Good point. I added corresponding text. >=20 > 9. Section 6: In case of DTLS over SCTP support of the message = interleaving functionality may increase the risk of receiving messages = with new epoch after ChangeCipherSpec message and before Finished = message. Possibly. But implementations have to deal with it anyway. So what is = the point? >=20 >=20 > BR, Maksim >=20 >> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk: >>=20 >>=20 >> This mail announces a TSVWG Working Group Last Call (WGLC) on: >>=20 >> Stream Schedulers and User Message Interleaving forSCTP >> draft-ietf-tsvwg-sctp-ndata >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata >>=20 >> This WGLC will last for 2 weeks weeks. >>=20 >> Comments should be sent to the tsvwg@ietf.org list, although purely >> editorial comments may be sent directly to the authors. Please cc: = the >> WG chairs at tsvwg-chairs@ietf.org if you would like the chairs to >> track such editorial comments as part of the WGLC process. >>=20 >> No IPR disclosures have been submitted directly on >> draft-ietf-tsvwg-sctp-ndata. >>=20 >> Thanks, >> Gorry >> (TSVWG Co-Chair) From nobody Mon Mar 13 10:30:20 2017 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 DE70E12995D for ; Mon, 13 Mar 2017 10:30:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=bobbriscoe.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 NONsYExQXKOM for ; Mon, 13 Mar 2017 10:30:12 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 2DF0E129958 for ; Mon, 13 Mar 2017 10:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject: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=+e09qUSgU4zfCbprYv9Q5GlGHVKPGJgboM3Xsm8ACvc=; b=ob6eikEWQMfw7FDQK7UwivaOK Z3Vy0RdTQDCKqjBObZRtLjbWU18r+w9R4/3e22nwoUWSy+xvngsuuN8S6Zx/8yMzrIqk7AB01Eikb yU0yvjduOUrdg7o4TyfQel+9yYvSxsJUz4aiHlrQffro5pgslBSwUTnJTBzyRXr5Xq/7ZQjtxVXEg YwqnMblfzabhnSQ/WYItvyg+6TMu5+a1ug4X8FfaPZsEhU+wP2kutNgSR60Nq++eYSTVm1SceX0L0 KUFW1DOMVg0ka25k6xWS2w75glydbTJW7irbUzlN+Ci04vxHGP+aREU1hUF2WjKnwC6k0JGOh5dcP 9v+rWYeCw==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:35418 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cnTnK-0001z9-Gt; Mon, 13 Mar 2017 17:30:08 +0000 To: "Black, David" , Karen Elisabeth Egede Nielsen References: <73e2a785b099e897990704d3fdd8c078@mail.gmail.com> <6f068e27c5c0c61a87c5daed27cb0da3.squirrel@server.dnsblock1.com> <7599733a-d728-0d7d-3615-e8d3b4ec70c6@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Mon, 13 Mar 2017 17:30:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0E31D5A25FEEBB2CC249E896" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "iccrg@irtf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] [iccrg] Policing and L4S WAS RE: BBR and other congestion control mechanisms X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:30:18 -0000 This is a multi-part message in MIME format. --------------0E31D5A25FEEBB2CC249E896 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit David, Karen, While updating the L4S arch draft with stuff about policing, I just discovered that this email thread continued after I stopped watching. Sorry I missed it at the time. Inline... On 09/12/16 02:32, Black, David wrote: > > A few follow-up comments as an individual: > > */> [Karen Elisabeth Egede Nielsen] And you’re doing a great deal to > provide mechanisms/* > > */> that routers can deploy to support good interworking with ECN/l4s./* > > */> We need the same for policers./* > > */> It is not really enough that ECN/l4s does not do worse than > classic where there/* > > */> is a drop policer, if this often can be the case./* > I've done a lot of work on this in this past. But as I said earlier in the thread, I'm not convinced it's a priority for L4S right now, at least not until it's clear what (if any) policing requirements there are. Most simply, you could * either introduce an ECN marking threshold part way down a tb rate policer. * or use a dual tb as in a 3-colour (red/amber/green) marker, but with ECN marking instead of the amber colouring. Nonetheless, I prefer to consume tokens with the bytes dropped or ECN marked by the AQM, rather than with all bytes. This subtle change gives a huge improvement. The basic design is shown on slide 5 of the link below. http://www.bobbriscoe.net/presents/1210isoc/1210isoc-briscoe.pdf To address your concern, you could add a second threshold in each tb, at which extra ECN marking would start to be focused on a heavy user before they reach the threshold for focused drop. For heavy users it becomes a bandwidth policer, enforcing weighted shares of capacity rather than a fixed capacity threshold. But, unlike fq or WRR, it has just one queue. The improvement shown on slide 10 also prevents users from causing delay spikes in the shared queue. > +1 - I expect this to be more difficult to specify and deployed than > was the case for > > ECN support in routers, as ECN-based AQM is not close to what policers > currently do. > I'm not sure you need ECN-based AQM in a policer. I think you just need to add ECN to the dropping functions policers already have (tb's etc). As in my simple suggestions above. But I think the best approach is to bolt a policing module onto an AQM, then you can use the info the AQM gives you. It's not exactly a bandwidth policer, but Rong Pan's AFD works like that and it is apparently deployed quite widely. Similarly, the design on slide 5 above is a policer module designed as a bolt-on to most AQMs. And it is very close to how a tb policer works. It has been implemented by at least one traffic management vendor. They found it was still going strong at 4Gb/s line rate (as a software implementation), well beyond line rates when their other solutions could no longer keep up. There of course great scope for new mechanisms here - I'm not saying this has all been done before. > >So yes, we need to suggest which PHBs are appropriate for L4S. I'd be > happy to work > > > with someone doing that, but it's not my priority at the moment. I'll certainly add an > > > open issues section in the architecture doc and include this so it doesn't get lost. > > Good - IMHO, that’s important, as at the very least, guidance ought to > be provided on > > which PHBs SHOULD vs. SHOULD NOT be used for (initial) experimental > deployments > > of L4S. There may even be some prohibitions on L4S usage with certain > PHBs - > > VOICE-ADMIT and the network control traffic (e.g., routing) that > typically uses CS6 > > spring to mind as possibilities. > I think this is running ahead of ourselves a bit. This is experimental work. We need to get trials started in the default class first. Then, once there's some implementations, operators and vendors can try them in various combinations to build new services. I don't think now is the right time to write down prohibitions on what can be done in experiments. > > >> I have another concern with the text quoted from > >> the L4S architecture draft - it contains an assertion that networks ought to just > >> ignore the L4S identifier and pass that identifier through unchanged for traffic that > >> does not receive L4S service. The analogous exhortation for DSCPs has failed > >> miserably for operational reasons > > [... snip ...] > > >> If the L4S identifier selects a distinct low latency network service, it will become a > >> good network operational practice to remove that identifier from traffic that is > >> not authorized to receive that low latency service. > > > Bleaching ECT(1) cannot be ruled out as a future scenario But we have tried to do as > much as we can to head-off this possibility: > > 1) By explaining exactly how operators can offer exclusivity without > needing to bleach > > 2) We are starting from a position where the ECN field is > near-universally not bleached. So to bleach, an operator will > > > have to actively destroy something they currently support. Operators know they would > risk referral to their local regulator for that. > > > 3) The ECN field is part of the Internet's congestion control system, so there is a > higher bar to tampering with ECN than there was for Diffserv. > > Once ECT(1) starts to participate in queue selection in routers, > points 2) and 3) above > > become irrelevant - the network operator owns those router forwarding > resources > > and will exercise complete control over what traffic is allowed to use > them, period. > > Beyond that, I see some optimistic thinking in 1), and while I > encourage optimism > > in the pursuit of innovation, I also suggest a look at the following > message for a > > network operations perspective: > > https://www.ietf.org/mail-archive/web/tsvwg/current/msg14839.html > My point (1) proposes that operators to give themselves exclusivity by using customer addressing /as well as/ the ECN field to determine who gets to use the L4S queue. Addressing /is/ under the local operator's control, so they can leave the ECN field untouched as a "polite request" for the e2e service, which is only "activated" under the local operator's control, based on their contract with their users. I came up with this from my experience of diffserv intercon. From your experience, can you think of any other way(s) that might give stronger grounds for optimism? Cheers Bob > Thanks, --David > > *From:*Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com] > *Sent:* Sunday, December 04, 2016 8:26 AM > *To:* Bob Briscoe; Black, David > *Cc:* iccrg@irtf.org; tsvwg@ietf.org > *Subject:* RE: [iccrg] [tsvwg] Policing and L4S WAS RE: BBR and other > congestion control mechanisms > > HI, > > Just to be clear. I support the ecn work and potential adoption of > this work. > > My comments do not go in the disqualifying the work, rather the opposite. > > Inline below. > > BR, Karen > > *From:*iccrg [mailto:iccrg-bounces@irtf.org > ] *On Behalf Of *Bob Briscoe > *Sent:* 1. december 2016 02:23 > *To:* Black, David >; Karen Elisabeth Egede Nielsen > > > *Cc:* iccrg@irtf.org ; tsvwg@ietf.org > > *Subject:* Re: [iccrg] [tsvwg] Policing and L4S WAS RE: BBR and other > congestion control mechanisms > > David, > > On 19/11/16 04:19, Black, David wrote: > > Commenting as an individual (not WG chair), at least for now ... > > If I read this correctly, that L4S is not compatible with > Diffserv-style bandwidth > > policing and token buckets in particular, > > Well, no. L4S is not incompatible with Diffserv-style bandwidth policing. > > Because, on loss the L4S requirements say a source must fall back to a > Classic loss-response (e.g. Reno, Cubic, or something equivalent if > it's a real-time transport). So a tb bandwidth policer (2-colour, > 3-colour, 1-rate, 2-rate, etc) will work just fine to limit an L4S source. > > I think what Karen meant was the other way round: That an L4S source > will not get L4S service from a tb bandwidth policer, > > */[Karen Elisabeth Egede Nielsen] Yes that was what I was addressing./* > > just as it won't get L4S service from a non-L4S bottleneck router or > switch. Precisely because L4S falls back to non-L4S (Classic) > behaviour in both cases; whenever it gets a loss. > > */[Karen Elisabeth Egede Nielsen] And you’re doing a great deal to > provide mechanisms that routers can deploy to support good > interworking with ECN/l4s./* > > */We need the same for policiers./* > > */It is not really enough that ECN/l4s does not do worse than classic > where there is a drop policier, if this often can be the case./* > > > > Interaction with Policing is in the L4S architecture doc (which used > to be the L4S problem statement): > See section 8.1 Traffic (Non-)Policing > , > which is in section 8 'Security Considerations'. > > Section 8.2 'Latency Friendliness' > > explains that some operators might introduce burst policing for L4S. > However, 8.2 recommends that we start without policing and instead we > recommend ways to get a good service while minimizing burstiness. I > call it 'latency friendliness', because it's based on "social > pressure"; somewhat like the traditional approach to TCP friendliness, > where we recommend good algorithms in the expectation they will avoid > the need for policing. But it doesn't preclude operators deploying > policers. > > */[Karen Elisabeth Egede Nielsen/**/] I think that ECN would be much > more powerful if one could device how to make policing interwork with > it./* > > */I would rather like to see ECN not as a replacement of DiffServ, but > as a supplement as also indicated in section 5.2 of the draft (the > underlined parts below):/* > > *//* > > Diffserv: Diffserv addresses the problem of bandwidth apportionment > > for important traffic as well as queuing latency for delay- > > sensitive traffic. L4S solely addresses the problem of queuing > > latency. Diffserv will still be necessary where important traffic > > requires priority (e.g. for commercial reasons, or for protection > > of critical infrastructure traffic). Nonetheless, if there are > > ^^^^^^^^^^^^^^^^^^^^^^ > > Diffserv classes for important traffic, the L4S approach can > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > provide low latency for _all_ traffic within each Diffserv class^ > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > (including the case where there is only one Diffserv class). > > */Something else, suddenly in this paragraph it is written > that:/**/“L4S solely addresses the problem of queuing/* > > */latency. “ /**/As also indicated elsewhere in the draft, keeping > loss down is also a primary part of L4s and a prerequisite for that > l4s works well./* > > *//* > > */I think that the draft could better motivate the issue with the > policiers and the necessity to deploy L4S friendly policies (as you > discuss below)./* > > */This was my point./* > > *//* > > */BR, Karen/* > > *//* > > then the assertion that L4S is universally > > applicable to all Internet traffic just took a serious hit. > > I guess you're referring to the opening sentence of the abstract of > the L4S architecture: "...a new service that the Internet could > provide to eventually replace best efforts for all traffic...". That > doesn't mean that when a sender turns on the ECT(1) codepoint it > magically creates an L4S implementation in every bottleneck and every > policer that the sender traverses. > > Nonetheless, the point of L4S is for performance to be so good, that > it magically makes operators want to deploy an L4S AQM at their > bottlenecks (and to deploy more L4S-friendly policers). > > I might suggest considering > > which PHBs are more vs. less appropriate for L4S, as token buckets > are rather > > common out there and will have to be dealt with as part of incremental > > deployment of L4S. Karen - thank you for pointing this out. > > I think you have got the wrong end of the stick. When we said "for all > traffic", we meant the default L4S service could give the service that > the traffic requires (that is, for example, the EF or AF /service/, > not the EF or AF /per hop behaviour/). We didn't mean the traffic has > to be marked EF or AF to get that service, we just meant that the > default L4S service would be /roughly/ as good as EF or AF, without > having to implement EF or AF. > > The inclusion of EF is probably an overclaim - there's no explicit > mechanism in L4S to give any guarantee of EF-like service. > Nonetheless, I included EF in my list, because the Internet has always > proved good at meeting performance goals without being able to > guarantee that it will. > > That said, L4S gives only the low queueing delay feature of Diffserv, > but not the "priority over bandwidth during anomalies" feature that > some Differv classes give over others. We will need to make that clear > - it's not clear at the moment. > > For bandwidth priority, it would be appropriate to use relevant > non-default Diffserv PHBs, and it would be appropriate to use L4S > within those classes. I have analysed this for the specific case of > the classes used by my previous employer, but not for all the Diffserv > classes that the IETF has ever dreamed of. So yes, we need to suggest > which PHBs are appropriate for L4S. I'd be happy to work with someone > doing that, but it's not my priority at the moment. I'll certainly add > an open issues section in the architecture doc and include this so it > doesn't get lost. > > In addition to Karen's concern, I have another concern with the > text quoted from > > the L4S architecture draft - it contains an assertion that > networks ought to just > > ignore the L4S identifier and pass that identifier through > unchanged for traffic that > > does not receive L4S service. The analogous exhortation for DSCPs > has failed > > miserably for operational reasons - bleaching to zero is entirely > too common so > > that traffic is marked for the service it is supposed to > (authorized to) receive from > > the network, or as stated in Section 2 of See > draft-ietf-tsvwg-diffserv-intercon: > > RFC2474's recommendation to forward traffic with unrecognized DSCPs > > with Default (best effort) service without rewriting the DSCP has > > proven to be a poor operational practice. Network operation and > > management are simplified when there is a 1-1 match between the > DSCP > > marked on the packet and the forwarding treatment (PHB) applied by > > network nodes. When this is done, CS0 (the all-zero DSCP) is the > > only DSCP used for Default forwarding of best effort traffic, and a > > common practice is to remark to CS0 any traffic received with > > unrecognized or unsupported DSCPs at network edges. > > If the L4S identifier selects a distinct low latency network > service, it will become a > > good network operational practice to remove that identifier from > traffic that is > > not authorized to receive that low latency service. > > Bleaching ECT(1) cannot be ruled out as a future scenario. But we have > tried to do as much as we can to head-off this possibility: > 1) By explaining exactly how operators can offer exclusivity without > needing to bleach > 2) We are starting from a position where the ECN field is > near-universally not bleached. So to bleach, an operator will have to > actively destroy something they currently support. Operators know they > would risk referral to their local regulator for that. > 3) The ECN field is part of the Internet's congestion control system, > so there is a higher bar to tampering with ECN than there was for > Diffserv. > > That last point is subtle. > L4S is not a "network service" like Diffserv. L4S is a service largely > induced by the sender behaviour, with the network playing a minor but > important complementary role (by notifying congestion at a shallow > queue threshold). So, unlike Diffserv, the ECN field is not just a > request down the layers asking the network for a particular service. > It is also the place where congestion notification is carried up the > layers, from network to transport. > > > Sorry this reply took a while. When you sent it, I had no laptop (my > charger failed on the Wed of the IETF). I got it fixed, but I'm only > just getting back to those emails I missed. > > Cheers > > > Bob > > > Thanks, --David > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen > Elisabeth > > Egede Nielsen > > Sent: Friday, November 18, 2016 4:55 AM > > To: in@bobbriscoe.net > > Cc: iccrg@irtf.org ; tsvwg@ietf.org > ; Michael Welzl > > Subject: Re: [tsvwg] Policing and L4S WAS RE: [iccrg] BBR and > other congestion > > control mechanisms > > HI Bob, > > Yes, well aware that L4S will only be as good as the best > ISP on the path. > > [Karen Elisabeth Egede Nielsen] yes. > > One would hope that an operator deploying an L4S AQM would > ensure its > > policers were compatible, but of course your point is that > traffic can > > traverse > > other operators too. > > [Karen Elisabeth Egede Nielsen] I wish :-). Not close to > having that grand > > overview at all, simply trying to > > understand the dependencies and how to make this work in a > product. > > Using token bucket policing with drop to enforce SLAs pops up > as an obvious > > issue then. > > This is perfectly fine and as it should be, BUT it is actually > a very > > important point looking at the QOS features being developed > for products, > > e.g., smart NICs, If we have token buckets there or don't get > ECN in there > > in the Shaper logic, then really > > the interworking of Diff Server QoS and ECN will not be > possible as > > indicated in the draft. > > I am generally assuming that operators would initially > want to provide > > exclusive access to L4S for their own (probably paying) > customers. > > l4s-arch says: > > Certain network operators might choose to restict > access to the L4S > > class, perhaps only to customers who have paid a > premium. In the > > packet classifer (item 2 in Figure 1), they could > identify such > > customers using some other field than ECN (e.g. source > address > > range), and just ignore the L4S identifier for > non-paying customers. > > This would ensure that the L4S identifier survives > end-to-end even > > though the service does not have to be supported at > every hop. Such > > arrangements would only require simple > registered/not-registered > > packet classification, rather than the managed > application-specific > > traffic policing against customer-specific traffic > contracts that > > Diffserv requires. > > [Karen Elisabeth Egede Nielsen] Yes I saw this text but it > doesn't really > > say that ECN l4s service requires that > > the operators do not ingress BW police the traffic - sure > this is clear > > from a technical point (also finally even for me now ..) but > > as BW policing is really a basic part of Diff Serv and QoS > arch I think that > > it could be good to stress that point in Section 5.2. > > You may use l4s to regulate traffic within a diff serv class > but the traffic > > must not be subject to non ECN regulated drop at any point > > not in potential prior diff serv classification steps either. > > As an example, if you like, then in OPenstack QoS API there is > (only yet) a > > simple BW policier function. Products are being build > > on this. If we want to provide l4s better be aware either to > disable the > > function or that it need be done proper (..). > > Virtual services that are afforded l4s may not have a physical > NIC at their > > sole disposal and BW policing for control of the shared > > access to the NIC resources is being used. Better make clear > from the start > > that if one want ever to be able to provide l4s then > > these BW policing functions must eventually implement ECN > enabled AQM. > > BR, Karen > > Bob > > On Thu, November 17, 2016 12:36 pm, Karen Elisabeth Egede > Nielsen wrote: > > HI Bob, All, > > Very interesting from my perspective. Thanks a lot for > this > > presentation and mail discussion. > > With the point of view of acc ECN/l4s then I wonder if > it was worth to > > include some text about token bucket policing and L4S > in the L4S > > Architecture draft, draft-briscoe-tsvwg-l4s-arch-00. > > There is some considerations there already in section > 5.2 and section > > 8.1, but would it be relevant to make it more explicit > that the > > following statement (section 5.2) > > Nonetheless, if there are > > Diffserv classes for important traffic, the L4S > approach can provide > > low latency for _all_ traffic within each Diffserv > class (including > > the case where there is only one Diffserv class). > > Is only really truly valid if ingress diff serv > > classification/policing/shaping it self - e.g., a BW > policier - does > > not implement drop and in case of a shaper (and > queuing) then ECN must > > be implemented by the shaper as well. I suppose the > latter somehow > > falls into ECN recommendations for AQM, so perhaps these > > considerations (end the differences to a policier that do > > drop) are already totally clear to everybody. > > ECN sort of is the alternative to let the CC be > latency increase > > aware, but as pointed out here then with bold drop > token bucket > > policing we really have neither. > > Thanks > > BR, Karen > > -----Original Message----- > > From: iccrg [mailto:iccrg-bounces@irtf.org] On > Behalf Of Bob Briscoe > > Sent: 17. november 2016 08:35 > > To: Michael Welzl > > > Cc: iccrg@irtf.org ; > Yuchung Cheng > > > Subject: Re: [iccrg] BBR and other congestion > control mechanisms > > Michael, > > On Thu, November 17, 2016 1:49 am, Michael Welzl > wrote: > > Hi, > > An add-on to my previous email below: > > Mechanisms like Veno and CTCP, if I get this > right, only decide that > > a loss is due to congestion when it also comes > with delay growth. I > > just witnessed your presentation in MAPRG > about policing, and how > > BBR interacts with it: > > https://www.ietf.org/proceedings/97/slides/slides-97-maprg-traffic-p > > o lici > ng-in-the-internet-yuchung-cheng-and-neal-cardwell-00.pdf > > > > p olic > ing-in-the-internet-yuchung-cheng-and-neal-cardwell-00.pdf> > ( > > Thanks for giving this presentation, this was > very interesting. ) > > So this would mean that Veno, CTCP etc. would > get it wrong in the > > face of a token bucket - there would be loss > without delay growth, > > yet it IS due to a rate limit. Given the > prevalence of policing that > > you have shown, and how BBR nicely interacts > with it, I find this > > very interesting (and good); I’m not sure if > this has been > > considered in the design of any congestion > control before? Does > > anyone know of any other examples? > > 1/ I would be interested if there is enough data > in the BBR dataset > > to zoom in on clients in specific ISPs. I know at > least one traffic > > management vendor uses a congestion policer that > limits the rate of > > heavy users, but the rate at which it limits > varies all the time, > > because it is the outcome congestion limit, not a > rate limit. More > > precisely, it enforces a "congestion rate token > bucket" limit on the > > per-user contribution to shared congestion. > > This would look similar to the varying capacity of > a scheduler, but > > distinguished from 3G/LTE or WiFi by only tiny > additional delay, > > because the measurement of shared congestion in > the policer is based > > on an AQM on a very high bandwidth link (typically > 10G or 40Gb/s), so > > queuing delay is very low before loss appears. > > 2/ HULL (High throughput, utra-low latency) uses > DCTCP at the sender. > > In > > the network it marks ECN on the real packets based > on the length of a > > 'phantom' queue, which is a number incremented by > the size of every > > arriving packet, and decremented slightly more > slowly than the drain > > rate of the real queue. This keeps the real queue > extremely short. > > This is an example where there is zero delay > build-up before the > > intended operating point. Because of the lack of > delay, it also uses > > hardware pacing on the sender NIC, because there > is no queuing delay > > to space out TCP's ACK clock otherwise. > > I don't know whether any DC operators are using > HULL (does anyone?). > > You would not want to put Not-ECT packets (like > current BBR) into > > such a queue structure. > > Bob > > Cheers, > > Michael > > On Nov 17, 2016, at 9:57 AM, Michael Welzl > > > > wrote: > > Hi Yuchung, > > On Nov 17, 2016, at 8:22 AM, Yuchung > Cheng > > > > wrote: > > On Wed, Nov 16, 2016 at 5:14 PM, > Michael Welzl > > > > wrote: > > Dear all, > > Thanks very much to the authors of > BBR for an interesting > > presentation yesterday! (see > > https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr- > > cong estion-control-01.pdf > > > > -con > > > gestion-control-01.pdf> > if > you missed it). > > I’d be interested to know how BBR > compares to some other TCP > > variants. For example, TIMELY: > > http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p537.pdf > > > > > Any idea, anyone? > > ( I tried, honestly, I did - but I > just can’t manage to hold back > > a tiny bit of sarcasm here: ...is > BBR also 133 times faster than > > TIMELY? :-) ) > > I'd like to explain further about 133x > result of BBR vs Cubic > > first. > > This is a spot-test. It is not a > general quantification of BBR's > > improvement on our B4 network (we'll > publish that data in a > > separate report). This is a 8MB RPC > every 30s on a warmed > > connection on east-US <-> west-EU > using the lowest QoS (best > > effort). That particular path has > quite a bit of burst induced > > losses. In this case, Cubic just died > due to 1/sqrt(p). Notice the > > network path is fairly different from > the typical Internet access: > > it's +10G from start to end, with > little buffers (compared to BDP) > > on the way to build persistent large > queues. The losses are caused > > by burst traffic (of same or higher > QoS). What the number 133x > > highlighted was when loss does not > indicate a persistent queue, > > using it as a sole congestion signal > is brittle. It is not to say > > loss signal is completely useless, but > it does not always indicate > > self-induced queues. > > Thanks for this information! > > Comparing TIMELY and BBR are at one > level comparing apples to > > oranges. TIMELY is designed for a very > specific hw/transport > > (RDMA/kernel-bypass) and networks > (intra-DC) with the goal to > > reduce tail latency. Hence it uses > specific NIC features like HW > > timestamps to perform its control. > > Well … I understand it was made for > intra-DC communication, and it > > uses these features to get the necessary > timer granularity. I can’t > > see why this wouldn’t make it applicable > to networks with larger > > RTTs? > > BBR is designed to be a generic good > transport to achieve high > > tput with adequate queue. It faces an > unknown network and sole > > feedback is TCP-acks hence it must > first perform a exponential > > search to get a basic sense of the > network. It also needs to deal > > with all sorts of adverse issues in > the wild Internet as we'v > > described. > > Right… E.g. I guess Timely wouldn’t work > so well when facing > > losses. > > A more interesting comparison would be > vs other Internet-CC like > > Vegas (which we are working on). > > No, I think that’s a terribly > uninteresting comparison to do. I’d > > even call it ridiculous, as many many MANY > mechanisms work better > > than Vegas, after all it's now 16 years old. > > May I propose comparing against the state > of the art, not the state > > of 2000? > > Some of the direct follow-ups on Vegas for > example, like FAST? Or > > delay-based algorithms that also use a bit > more information than > > just delay? > > E.g. Westwood comes to mind, as a > mechanism that also looks at the > > rate at which ACKs arrive. AFAIK this one > is readily available in > > Linux for comparison. > > Also, some TCP variants try to distinguish > between random packet > > loss and congestion-induced packet loss - > so similar to BBR, you > > wouldn’t overreact to random losses with > them. Veno is an example, > > and CTCP (Coded TCP, not Compound TCP) too. > > Cheers, > > Michael > > _______________________________________________ > > iccrg mailing list iccrg@irtf.org > > > https://www.irtf.org/mailman/listinfo/iccrg > > _______________________________________________ > > iccrg mailing list iccrg@irtf.org > > > https://www.irtf.org/mailman/listinfo/iccrg > > _______________________________________________ > > iccrg mailing list iccrg@irtf.org > > > https://www.irtf.org/mailman/listinfo/iccrg > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------0E31D5A25FEEBB2CC249E896 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit David, Karen,

While updating the L4S arch draft with stuff about policing, I just discovered that this email thread continued after I stopped watching.
Sorry I missed it at the time. Inline...

On 09/12/16 02:32, Black, David wrote:

A few follow-up comments as an individual:

 

> [Karen Elisabeth Egede Nielsen] And you’re doing a great deal to provide mechanisms

> that routers can deploy to support good interworking with ECN/l4s.

> We need the same for policers.

> It is not really enough that ECN/l4s does not do worse than classic where there

> is a drop policer, if this often can be the case.

I've done a lot of work on this in this past. But as I said earlier in the thread, I'm not convinced it's a priority for L4S right now, at least not until it's clear what (if any) policing requirements there are.

Most simply, you could
* either introduce an ECN marking threshold part way down a tb rate policer.
* or use a dual tb as in a 3-colour (red/amber/green) marker, but with ECN marking instead of the amber colouring.

Nonetheless, I prefer to consume tokens with the bytes dropped or ECN marked by the AQM, rather than with all bytes. This subtle change gives a huge improvement.
The basic design is shown on slide 5 of the link below.
    http://www.bobbriscoe.net/presents/1210isoc/1210isoc-briscoe.pdf
To address your concern, you could add a second threshold in each tb, at which extra ECN marking would start to be focused on a heavy user before they reach the threshold for focused drop.

For heavy users it becomes a bandwidth policer, enforcing weighted shares of capacity rather than a fixed capacity threshold.
But, unlike fq or WRR, it has just one queue. The improvement shown on slide 10 also prevents users from causing delay spikes in the shared queue.

 

+1 - I expect this to be more difficult to specify and deployed than was the case for

ECN support in routers, as ECN-based AQM is not close to what policers currently do. 

I'm not sure you need ECN-based AQM in a policer. I think you just need to add ECN to the dropping functions policers already have (tb's etc). As in my simple suggestions above.

But I think the best approach is to bolt a policing module onto an AQM, then you can use the info the AQM gives you.
It's not exactly a bandwidth policer, but Rong Pan's AFD works like that and it is apparently deployed quite widely.

Similarly, the design on slide 5 above is a policer module designed as a bolt-on to most AQMs.
And it is very close to how a tb policer works.

It has been implemented by at least one traffic management vendor.
They found it was still going strong at 4Gb/s line rate (as a software implementation), well beyond line rates when their other solutions could no longer keep up.

There of course great scope for new mechanisms here - I'm not saying this has all been done before.


 

>  So yes, we need to suggest which PHBs are appropriate for L4S. I'd be happy to work

> with someone doing that, but it's not my priority at the moment. I'll certainly add an

> open issues section in the architecture doc and include this so it doesn't get lost.

Good - IMHO, that’s important, as at the very least, guidance ought to be provided on

which PHBs SHOULD vs. SHOULD NOT be used for (initial) experimental deployments

of L4S.  There may even be some prohibitions on L4S usage with certain PHBs -

VOICE-ADMIT and the network control traffic (e.g., routing) that typically uses CS6

spring to mind as possibilities.

I think this is running ahead of ourselves a bit. This is experimental work. We need to get trials started in the default class first. Then, once there's some implementations, operators and vendors can try them in various combinations to build new services.

I don't think now is the right time to write down prohibitions on what can be done in experiments.

 

>> I have another concern with the text quoted from
>> the L4S architecture draft -  it contains an assertion that networks ought to just
>> ignore the L4S identifier and pass that identifier through unchanged for traffic that
>> does not receive L4S service.  The analogous exhortation for DSCPs has failed
>> miserably for operational reasons
 

[... snip ...]

 
>> If the L4S identifier selects a distinct low latency network service, it will become a
>> good network operational practice to remove that identifier from traffic that is
>> not authorized to receive that low latency service.

 

> Bleaching ECT(1) cannot be ruled out as a future scenario But we have tried to do as much as we can to head-off this possibility:
> 1) By explaining exactly how operators can offer exclusivity without needing to bleach
> 2) We are starting from a position where the ECN field is near-universally not bleached. So to bleach, an operator will

> have to actively destroy something they currently support. Operators know they would risk referral to their local regulator for that.

> 3) The ECN field is part of the Internet's congestion control system, so there is a higher bar to tampering with ECN than there was for Diffserv.

 

Once ECT(1) starts to participate in queue selection in routers, points 2) and 3) above

become irrelevant - the network operator owns those router forwarding resources

and will exercise complete control over what traffic is allowed to use them, period.

 

Beyond that, I see some optimistic thinking in 1), and while I encourage optimism

in the pursuit of innovation, I also suggest a look at the following message for a

network operations perspective:

 

https://www.ietf.org/mail-archive/web/tsvwg/current/msg14839.html

My point (1) proposes that operators to give themselves exclusivity by using customer addressing /as well as/ the ECN field to determine who gets to use the L4S queue.
Addressing /is/ under the local operator's control, so they can leave the ECN field untouched as a "polite request" for the e2e service, which is only "activated" under the local operator's control, based on their contract with their users.

I came up with this from my experience of diffserv intercon.
From your experience, can you think of any other way(s) that might give stronger grounds for optimism?

Cheers


Bob


 

Thanks, --David

 

From: Karen Elisabeth Egede Nielsen [mailto:karen.nielsen@tieto.com]
Sent: Sunday, December 04, 2016 8:26 AM
To: Bob Briscoe; Black, David
Cc: iccrg@irtf.org; tsvwg@ietf.org
Subject: RE: [iccrg] [tsvwg] Policing and L4S WAS RE: BBR and other congestion control mechanisms

 

HI,

 

Just to be clear. I support the ecn work and potential adoption of this work.

My comments do not go in the disqualifying the work, rather the opposite.

 

Inline below.

 

BR, Karen

 

From: iccrg [mailto:iccrg-bounces@irtf.org] On Behalf Of Bob Briscoe
Sent: 1. december 2016 02:23
To: Black, David <David.Black@dell.com>; Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
Cc: iccrg@irtf.org; tsvwg@ietf.org
Subject: Re: [iccrg] [tsvwg] Policing and L4S WAS RE: BBR and other congestion control mechanisms

 

David,

On 19/11/16 04:19, Black, David wrote:

Commenting as an individual (not WG chair), at least for now ...
 
If I read this correctly, that L4S is not compatible with Diffserv-style bandwidth
policing and token buckets in particular,

Well, no. L4S is not incompatible with Diffserv-style bandwidth policing.

Because, on loss the L4S requirements say a source must fall back to a Classic loss-response (e.g. Reno, Cubic, or something equivalent if it's a real-time transport). So a tb bandwidth policer (2-colour, 3-colour, 1-rate, 2-rate, etc) will work just fine to limit an L4S source.

I think what Karen meant was the other way round: That an L4S source will not get L4S service from a tb bandwidth policer,

[Karen Elisabeth Egede Nielsen] Yes that was what I was addressing.

just as it won't get L4S service from a non-L4S bottleneck router or switch. Precisely because L4S falls back to non-L4S (Classic) behaviour in both cases; whenever it gets a loss.

[Karen Elisabeth Egede Nielsen] And you’re doing a great deal to provide mechanisms that routers can deploy to support good interworking with ECN/l4s.

We need the same for policiers.

It is not really enough that ECN/l4s does not do worse than classic where there is a drop policier, if this often can be the case.



Interaction with Policing is in the L4S architecture doc (which used to be the L4S problem statement):
See section 8.1 Traffic (Non-)Policing, which is in section 8 'Security Considerations'.

Section 8.2 'Latency Friendliness' explains that some operators might introduce burst policing for L4S. However, 8.2 recommends that we start without policing and instead we recommend ways to get a good service while minimizing burstiness. I call it 'latency friendliness', because it's based on "social pressure"; somewhat like the traditional approach to TCP friendliness, where we recommend good algorithms in the expectation they will avoid the need for policing. But it doesn't preclude operators deploying policers.

[Karen Elisabeth Egede Nielsen] I think that ECN would be much more powerful if one could device how to make policing interwork with it.

I would rather like to see ECN not as a replacement of DiffServ, but as a supplement as also indicated in section 5.2 of the draft (the underlined parts below):

 

Diffserv:  Diffserv addresses the problem of bandwidth apportionment

      for important traffic as well as queuing latency for delay-

      sensitive traffic.  L4S solely addresses the problem of queuing

      latency.  Diffserv will still be necessary where important traffic

      requires priority (e.g. for commercial reasons, or for protection

      of critical infrastructure traffic).  Nonetheless, if there are

                                                                        ^^^^^^^^^^^^^^^^^^^^^^

      Diffserv classes for important traffic, the L4S approach can

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

      provide low latency for _all_ traffic within each Diffserv class^

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

      (including the case where there is only one Diffserv class).

 

Something else, suddenly in this paragraph it is written that: “L4S solely addresses the problem of queuing

      latency.  “ As also indicated elsewhere in the draft, keeping loss down is also a primary part of L4s and a prerequisite for that l4s works well.

 

I think that the draft could better motivate the issue with the policiers and the necessity to deploy L4S friendly policies (as you discuss below).

This was my point.

 

BR, Karen

 

then the assertion that L4S is universally
applicable to all Internet traffic just took a serious hit. 

I guess you're referring to the opening sentence of the abstract of the L4S architecture: "...a new service that the Internet could provide to eventually replace best efforts for all traffic...". That doesn't mean that when a sender turns on the ECT(1) codepoint it magically creates an L4S implementation in every bottleneck and every policer that the sender traverses.

Nonetheless, the point of L4S is for performance to be so good, that it magically makes operators want to deploy an L4S AQM at their bottlenecks (and to deploy more L4S-friendly policers). 

I might suggest considering
which PHBs are more vs. less appropriate for L4S, as token buckets are rather
common out there and will have to be dealt with as part of incremental
deployment of L4S.  Karen - thank you for pointing this out.

I think you have got the wrong end of the stick. When we said "for all traffic", we meant the default L4S service could give the service that the traffic requires (that is, for example, the EF or AF /service/, not the EF or AF /per hop behaviour/). We didn't mean the traffic has to be marked EF or AF to get that service, we just meant that the default L4S service would be /roughly/ as good as EF or AF, without having to implement EF or AF.

The inclusion of EF is probably an overclaim - there's no explicit mechanism in L4S to give any guarantee of EF-like service. Nonetheless, I included EF in my list, because the Internet has always proved good at meeting performance goals without being able to guarantee that it will.

That said, L4S gives only the low queueing delay feature of Diffserv, but not the "priority over bandwidth during anomalies" feature that some Differv classes give over others. We will need to make that clear - it's not clear at the moment.

For bandwidth priority, it would be appropriate to use relevant non-default Diffserv PHBs, and it would be appropriate to use L4S within those classes. I have analysed this for the specific case of the classes used by my previous employer, but not for all the Diffserv classes that the IETF has ever dreamed of. So yes, we need to suggest which PHBs are appropriate for L4S. I'd be happy to work with someone doing that, but it's not my priority at the moment. I'll certainly add an open issues section in the architecture doc and include this so it doesn't get lost.

 
 
In addition to Karen's concern, I have another concern with the text quoted from
the L4S architecture draft -  it contains an assertion that networks ought to just
ignore the L4S identifier and pass that identifier through unchanged for traffic that
does not receive L4S service.  The analogous exhortation for DSCPs has failed
miserably for operational reasons - bleaching to zero is entirely too common so
that traffic is marked for the service it is supposed to (authorized to) receive from
the network, or as stated in Section 2 of See draft-ietf-tsvwg-diffserv-intercon:
 
   RFC2474's recommendation to forward traffic with unrecognized DSCPs
   with Default (best effort) service without rewriting the DSCP has
   proven to be a poor operational practice.  Network operation and
   management are simplified when there is a 1-1 match between the DSCP
   marked on the packet and the forwarding treatment (PHB) applied by
   network nodes.  When this is done, CS0 (the all-zero DSCP) is the
   only DSCP used for Default forwarding of best effort traffic, and a
   common practice is to remark to CS0 any traffic received with
   unrecognized or unsupported DSCPs at network edges.
 
If the L4S identifier selects a distinct low latency network service, it will become a
good network operational practice to remove that identifier from traffic that is
not authorized to receive that low latency service.

Bleaching ECT(1) cannot be ruled out as a future scenario. But we have tried to do as much as we can to head-off this possibility:
1) By explaining exactly how operators can offer exclusivity without needing to bleach
2) We are starting from a position where the ECN field is near-universally not bleached. So to bleach, an operator will have to actively destroy something they currently support. Operators know they would risk referral to their local regulator for that.
3) The ECN field is part of the Internet's congestion control system, so there is a higher bar to tampering with ECN than there was for Diffserv.

That last point is subtle.
L4S is not a "network service" like Diffserv. L4S is a service largely induced by the sender behaviour, with the network playing a minor but important complementary role (by notifying congestion at a shallow queue threshold). So, unlike Diffserv, the ECN field is not just a request down the layers asking the network for a particular service. It is also the place where congestion notification is carried up the layers, from network to transport.


Sorry this reply took a while. When you sent it, I had no laptop (my charger failed on the Wed of the IETF). I got it fixed, but I'm only just getting back to those emails I missed.

Cheers


Bob


 
 
Thanks, --David
 
-----Original Message-----
From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen Elisabeth
Egede Nielsen
Sent: Friday, November 18, 2016 4:55 AM
To: in@bobbriscoe.net
Cc: iccrg@irtf.org; tsvwg@ietf.org; Michael Welzl
Subject: Re: [tsvwg] Policing and L4S WAS RE: [iccrg] BBR and other congestion
control mechanisms
 
HI Bob,
 
Yes, well aware that L4S will only be as good as the best ISP on the path.
 
[Karen Elisabeth Egede Nielsen] yes.
 
One would hope that an operator deploying an L4S AQM would ensure its
policers were compatible, but of course your point is that traffic can
traverse
other operators too.
 
[Karen Elisabeth Egede Nielsen] I wish :-). Not close to having that grand
overview at all, simply trying to
understand the dependencies and how to make this work in a product.
 
Using token bucket policing with drop to enforce SLAs pops up as an obvious
issue then.
 
This is perfectly fine and as it should be, BUT it is actually a very
important point looking at the QOS features being developed for products,
 e.g., smart NICs, If we have token buckets there or don't get ECN in there
in the Shaper logic, then really
the interworking of Diff Server QoS and ECN will not be possible as
indicated in the draft.
 
I am generally assuming that operators would initially want to provide
exclusive access to L4S for their own (probably paying) customers.
l4s-arch says:
 
   Certain network operators might choose to restict access to the L4S
   class, perhaps only to customers who have paid a premium.  In the
   packet classifer (item 2 in Figure 1), they could identify such
   customers using some other field than ECN (e.g. source address
   range), and just ignore the L4S identifier for non-paying customers.
   This would ensure that the L4S identifier survives end-to-end even
   though the service does not have to be supported at every hop.  Such
   arrangements would only require simple registered/not-registered
   packet classification, rather than the managed application-specific
   traffic policing against customer-specific traffic contracts that
   Diffserv requires.
 
 
[Karen Elisabeth Egede Nielsen] Yes I saw this text but it doesn't really
say that ECN l4s service requires that
the operators do not ingress BW police the traffic  - sure this is clear
from a technical point (also finally even for me now ..) but
as BW policing is really a basic part of Diff Serv and QoS arch I think that
it could be good to stress that point in Section 5.2.
You may use l4s to regulate traffic within a diff serv class but the traffic
must not be subject to non ECN regulated drop at any point
not in potential prior diff serv classification steps either.
 
As an example, if you like, then in OPenstack QoS API there is (only yet) a
simple BW policier function. Products are being build
on this. If we want to provide l4s better be aware either to disable the
function or that it need be done proper (..).
Virtual services that are afforded l4s may not have a physical NIC at their
sole disposal and BW policing for control of the shared
access to the NIC resources is being used. Better make clear from the start
that if one want ever to be able to provide l4s then
these BW policing functions must eventually implement ECN enabled AQM.
 
BR, Karen
 
Bob
 
 
On Thu, November 17, 2016 12:36 pm, Karen Elisabeth Egede Nielsen wrote:
HI Bob, All,
 
 
Very interesting from my perspective. Thanks a lot for this
presentation and mail discussion.
 
With the point of view of acc ECN/l4s then I wonder if it was worth to
include some text about token bucket policing and L4S in the L4S
Architecture draft, draft-briscoe-tsvwg-l4s-arch-00.
 
 
There is some considerations there already in section 5.2 and section
8.1, but would it be relevant to make it more explicit that the
following statement (section 5.2)
 
Nonetheless, if there are
Diffserv classes for important traffic, the L4S approach can provide
low latency for _all_ traffic within each Diffserv class (including
the case where there is only one Diffserv class).
 
Is only really truly valid if ingress diff serv
classification/policing/shaping  it self - e.g., a BW policier - does
not implement drop and in case of a shaper (and queuing) then ECN must
be implemented by the shaper as well. I suppose the latter somehow
falls into ECN recommendations for AQM, so perhaps these
considerations (end the differences to a policier that do
drop) are already totally clear to everybody.
 
ECN sort of is the alternative to let the CC be latency increase
aware, but as pointed out here then with bold drop token bucket
policing we really have neither.
 
Thanks
 
 
BR, Karen
 
 
-----Original Message-----
From: iccrg [mailto:iccrg-bounces@irtf.org] On Behalf Of Bob Briscoe
Sent: 17. november 2016 08:35
To: Michael Welzl <michawe@ifi.uio.no>
Cc: iccrg@irtf.org; Yuchung Cheng <ycheng@google.com>
Subject: Re: [iccrg] BBR and other congestion control mechanisms
 
 
Michael,
 
 
On Thu, November 17, 2016 1:49 am, Michael Welzl wrote:
 
Hi,
 
 
 
An add-on to my previous email below:
 
 
 
Mechanisms like Veno and CTCP, if I get this right, only decide that
a loss is due to congestion when it also comes with delay growth. I
just witnessed your presentation in MAPRG about policing, and how
BBR interacts with it:
https://www.ietf.org/proceedings/97/slides/slides-97-maprg-traffic-p
o lici ng-in-the-internet-yuchung-cheng-and-neal-cardwell-00.pdf
<https://www.ietf.org/proceedings/97/slides/slides-97-maprg-traffic-
p olic ing-in-the-internet-yuchung-cheng-and-neal-cardwell-00.pdf> (
Thanks for giving this presentation, this was very interesting. )
 
So this would mean that Veno, CTCP etc. would get it wrong in the
face of a token bucket - there would be loss without delay growth,
yet it IS due to a rate limit. Given the prevalence of policing that
you have shown, and how BBR nicely interacts with it, I find this
very interesting (and good); I’m not sure if this has been
considered in the design of any congestion control before?  Does
anyone know of any other examples?
1/ I would be interested if there is enough data in the BBR dataset
to zoom in on clients in specific ISPs. I know at least one traffic
management vendor uses a congestion policer that limits the rate of
heavy users, but the rate at which it limits varies all the time,
because it is the outcome congestion limit, not a rate limit. More
precisely, it enforces a "congestion rate token bucket" limit on the
per-user contribution to shared congestion.
 
This would look similar to the varying capacity of a scheduler, but
distinguished from 3G/LTE or WiFi by only tiny additional delay,
because  the measurement of shared congestion in the policer is based
on an AQM on a very high bandwidth link (typically 10G or 40Gb/s), so
queuing delay is very low before loss appears.
 
 
2/ HULL (High throughput, utra-low latency) uses DCTCP at the sender.
In
the network it marks ECN on the real packets based on the length of a
'phantom' queue, which is a number incremented by the size of every
arriving packet, and decremented slightly more slowly than the drain
rate of the real queue. This keeps the real queue extremely short.
 
This is an example where there is zero delay build-up before the
intended operating point. Because of the lack of delay, it also uses
hardware pacing on the sender NIC, because there is no queuing delay
to space out TCP's ACK clock otherwise.
 
 
I don't know whether any DC operators are using HULL (does anyone?).
 
 
You would not want to put Not-ECT packets (like current BBR) into
such a queue structure.
 
 
Bob
 
 
Cheers,
Michael
 
 
 
 
 
On Nov 17, 2016, at 9:57 AM, Michael Welzl <michawe@ifi.uio.no>
wrote:
 
 
 
Hi Yuchung,
 
 
 
 
On Nov 17, 2016, at 8:22 AM, Yuchung Cheng <ycheng@google.com
<mailto:ycheng@google.com>> wrote:
 
 
 
 
 
On Wed, Nov 16, 2016 at 5:14 PM, Michael Welzl <michawe@ifi.uio.no
<mailto:michawe@ifi.uio.no>> wrote:
 
 
Dear all,
 
 
 
Thanks very much to the authors of BBR for an interesting
presentation yesterday! (see
https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-
cong estion-control-01.pdf
<https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr
-con
gestion-control-01.pdf> if you missed it).
 
I’d be interested to know how BBR compares to some other TCP
variants. For example, TIMELY:
 
http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p537.pdf
 
<http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p537.pdf>
 
 
Any idea, anyone?
 
 
 
( I tried, honestly, I did - but I just can’t manage to hold back
a tiny bit of sarcasm here:  ...is BBR also 133 times faster than
TIMELY?  :-)  )
 
 
I'd like to explain further about 133x result of BBR vs Cubic
first.
 
 
This is a spot-test. It is not a general quantification of BBR's
improvement on our B4 network (we'll publish that data in a
separate report). This is a 8MB RPC every 30s on a warmed
connection on east-US <-> west-EU using the lowest QoS (best
effort). That particular path has quite a bit of burst induced
losses. In this case, Cubic just died due to 1/sqrt(p). Notice the
network path is fairly different from the typical Internet access:
it's +10G from start to end, with little buffers (compared to BDP)
on the way to build persistent large queues. The losses are caused
by burst traffic (of same or higher QoS). What the number 133x
highlighted was when loss does not indicate a persistent queue,
using it as a sole congestion signal is brittle. It is not to say
loss signal is completely useless, but it does not always indicate
self-induced queues.
Thanks for this information!
 
 
 
 
Comparing TIMELY and BBR are at one level comparing apples to
oranges. TIMELY is designed for a very specific hw/transport
(RDMA/kernel-bypass) and networks (intra-DC) with the goal to
reduce tail latency. Hence it uses specific NIC features like HW
timestamps to perform its control.
Well … I understand it was made for intra-DC communication, and it
uses these features to get the necessary timer granularity. I can’t
see why this wouldn’t make it applicable to networks with larger
RTTs?
 
 
 
BBR is designed to be a generic good transport to achieve high
tput with adequate queue. It faces an unknown network and sole
feedback is TCP-acks hence it must first perform a exponential
search to get a basic sense of the network. It also needs to deal
with all sorts of adverse issues in the wild Internet as we'v
described.
Right… E.g. I guess Timely wouldn’t work so well when facing
losses.
 
 
 
A more interesting comparison would be vs other Internet-CC like
Vegas (which we are working on).
 
 
No, I think that’s a terribly uninteresting comparison to do. I’d
even call it ridiculous, as many many MANY mechanisms work better
than Vegas, after all it's now 16 years old.
May I propose comparing against the state of the art, not the state
of 2000?
 
 
 
Some of the direct follow-ups on Vegas for example, like FAST? Or
delay-based algorithms that also use a bit more information than
just delay?
 
E.g. Westwood comes to mind, as a mechanism that also looks at the
rate at which ACKs arrive. AFAIK this one is readily available in
Linux for comparison.
 
Also, some TCP variants try to distinguish between random packet
loss and congestion-induced packet loss - so similar to BBR, you
wouldn’t overreact to random losses with them. Veno is an example,
and CTCP (Coded TCP, not Compound TCP) too.
 
 
 
Cheers,
Michael
 
 
 
_______________________________________________
iccrg mailing list iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg
 
 
_______________________________________________
iccrg mailing list iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg
 
 
 
 
_______________________________________________
iccrg mailing list iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg
 
 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------0E31D5A25FEEBB2CC249E896-- From nobody Mon Mar 13 10:49:00 2017 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 2F953129986 for ; Mon, 13 Mar 2017 10:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 HXkZp5PlkmS7 for ; Mon, 13 Mar 2017 10:48:58 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 183A9129993 for ; Mon, 13 Mar 2017 10:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:Subject:Sender:Reply-To: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=etklmn9PHHKjSU1rlgkvJPmp2NDFQB34qYJtM2D5SwA=; b=GCcvovrY3UNxwJ1IvgTbd+hnd PKwND4TiDK2iwJFe9c/bp9bwe+wzyfWD9+YGDOK1ofnDxB+CVlZ0H3FDg6cPjdQYJ+vxgtwhFueDm q+pRsdJhliOK4e4SBElHPrJXWhuDN2LQTxrIoCz0EfVP6Dc9QcDVxrOKP4r6BdX29qEb6HbYx8yzk aVMVuKQdSXTE9YwRJwpIJGOitlwSlxg0eLTzBV2fpFQtay0lf7Y9c5RCgMFtlCis83AQvhzh+QA6h FXf+qKPdMOXi+clRw5yBh6Gm0BSFYns74Eajg1mkxtyIT7m76tsEUCNGrPPc/fWlQkMJ8XGcwG+YQ GdFlSxPpQ==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:35482 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cnU5Y-0003s1-Hl for tsvwg@ietf.org; Mon, 13 Mar 2017 17:48:56 +0000 References: Cc: "tsvwg@ietf.org" From: Bob Briscoe Message-ID: Date: Mon, 13 Mar 2017 17:48:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------762348653FFEDA218464B94D" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:48:59 -0000 This is a multi-part message in MIME format. --------------762348653FFEDA218464B94D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Wes/tsvwg list, I guess I ought to say I support this work, and I'm still interested in contributing. I've been pushing forward on some next research steps, so sorry for the belated reply. Bob On 16/02/17 19:33, Pat Thaler wrote: > I'm supportive of this going forward in TSVWG and interested in > contributing. > > On Thu, Feb 16, 2017 at 12:09 AM, Ingemar Johansson S > > wrote: > > Hi > > Yes, I am very interested in this work and will contribute to the > work. > > /Ingemar > > > > > Message: 1 > > Date: Mon, 6 Feb 2017 23:13:32 -0500 > > From: Wesley Eddy > > > To: "tsvwg@ietf.org " > > > Subject: [tsvwg] L4S work in TSVWG > > Message-ID: > <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com > > > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hello, as a co-chair, I'm checking to make sure we have the > critical mass to go > > forward with L4S in TSVWG. > > > > Over time, there has been good discussion on this spread across several lists > > and groups (ICCRG, AQM, TCP-Prague, etc.). The ADs have asked > that going > > forward TSVWG be the home for this work, so I think we can limit > discussion > > to TSVWG now (assuming relevant parties are on-list). > > > > The three documents at present around this are: > > > > 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 > > > > > 2. > https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00 > > > > > 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 > > > > > There was interest in working these in TSVWG at the last IETF > meeting > > (noted in the minutes), and we want that discussion to continue > on the > > mailing list. > > > > Please respond if you're interested in participating in this > work by helping to > > review, analyze, implement, test, simulate, deploy, etc. and > agree that > > TSVWG should add milestones on the L4S problem, based on the current > > drafts. Or if you have other thoughts, those would be > interesting too. > > > > Thanks! > > > > > > > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------762348653FFEDA218464B94D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Wes/tsvwg list,
I guess I ought to say I support this work, and I'm still interested in contributing.
I've been pushing forward on some next research steps, so sorry for the belated reply.
Bob

On 16/02/17 19:33, Pat Thaler wrote:
I'm supportive of this going forward in TSVWG and interested in contributing.

On Thu, Feb 16, 2017 at 12:09 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

Yes, I am very interested in this work and will contribute to the work.

/Ingemar

>
> Message: 1
> Date: Mon, 6 Feb 2017 23:13:32 -0500
> From: Wesley Eddy <wes@mti-systems.com>
> To: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: [tsvwg] L4S work in TSVWG
> Message-ID: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello, as a co-chair, I'm checking to make sure we have the critical mass to go
> forward with L4S in TSVWG.
>
> Over time, there has been good discussion on this spread across several lists
> and groups (ICCRG, AQM, TCP-Prague, etc.).  The ADs have asked that going
> forward TSVWG be the home for this work, so I think we can limit discussion
> to TSVWG now (assuming relevant parties are on-list).
>
> The three documents at present around this are:
>
> 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00
>
> 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00
>
> 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02
>
> There was interest in working these in TSVWG at the last IETF meeting
> (noted in the minutes), and we want that discussion to continue on the
> mailing list.
>
> Please respond if you're interested in participating in this work by helping to
> review, analyze, implement, test, simulate, deploy, etc. and agree that
> TSVWG should add milestones on the L4S problem, based on the current
> drafts.  Or if you have other thoughts, those would be interesting too.
>
> Thanks!
>
>
>



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------762348653FFEDA218464B94D-- From nobody Mon Mar 13 11:09:12 2017 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 A6DF51299A8 for ; Mon, 13 Mar 2017 11:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] 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 JMPdTLNCZOBb for ; Mon, 13 Mar 2017 11:09:10 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 31133129985 for ; Mon, 13 Mar 2017 11:09:10 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m27so33661416iti.0 for ; Mon, 13 Mar 2017 11:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=1GqkrRn/SGDNQti1sjjmfAKIGmBjSDQINhfaFZFjd+I=; b=r0vJa/9dOmrhP7t1xf19mMKA5ILU0faldFQTdHIiftW0GA15bovswOfbE8+ZTBi68y NMWY508nvsUjnwPZTaZrlMu0VrBG3YxZ/M685TCU1SYe9OF+jilJ4wB6OAmkDgpFgM7+ izTQ2ROF00cuPw6eUPSR1Dpw/UeL0HDYT8AsllSH04vCBWIZnU1vibsscFn+n/9TT+UJ gLQhiXrfzSd1uvSmkcsJk2MJO32J8smBnsN+ayrOVUE2tyi0ZS4Ng4KAs8PqZIF8TbYW PoKD/NeaPoizS46ZMqbEXvZSeEKRYYavyF+gcb1WUbrrnhC1UM1cQfr55dhoAKlQ3Uv3 Wxbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=1GqkrRn/SGDNQti1sjjmfAKIGmBjSDQINhfaFZFjd+I=; b=FUdR5aeDxQmRjyabQdKvyOh7/L1J1gKh2YXd/GzPY46vqLh8APw8h9sdbxCgxKkqAb 2xSFzzlDMBaU8k79b4Get6iFubuFy1eKfXxbdp3KpTwZU5yeQpK1TS2xxEGZge0myNjM QXZqx3xAW5NvPHZDQ2Hm4iUvCo1hTN8OTCpg/bkLp7hlqmmzhyToWsNGzJfrIheB48z3 E4BATZaqBexVyCF6sI03aIrWABDcSUNW56YO8QSex+UAJRat14ArSn5kVKy8OUoBb+KO lCctMC9H5QxxZNglmMqoSxOV3URCceznj7COE+zPrN7/kW+aDfg4Hco8hRsgqCfxtSKS bTKQ== X-Gm-Message-State: AFeK/H1GWTKUDreOmIx0Oxn6EbTrtHH+Rg+BIls6Wv89qjoDOj2/RWuIHt7/AXJHF8nFHQ== X-Received: by 10.36.13.83 with SMTP id 80mr11035125itx.49.1489428549412; Mon, 13 Mar 2017 11:09:09 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id u191sm3963537ita.15.2017.03.13.11.09.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:09:08 -0700 (PDT) To: tsvwg@ietf.org, Bob Briscoe References: From: Wesley Eddy Message-ID: <261f2bc5-8083-316d-f205-411548c7886f@mti-systems.com> Date: Mon, 13 Mar 2017 14:09:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6C370ABBD4AD2A907FC86C32" Archived-At: Subject: Re: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:09:11 -0000 This is a multi-part message in MIME format. --------------6C370ABBD4AD2A907FC86C32 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A good number of people seem interested in L4S, and I haven't noticed any comments against adopting work on it, based on the current 3 drafts. We are planning time for L4S within the agenda for the 2nd TSVWG session in Chicago: https://datatracker.ietf.org/meeting/98/agenda/tsvwg/ Please let us (chairs) know who would like to speak on this (Bob, Koen, etc.) so we can coordinate timing, etc. On 3/13/2017 1:48 PM, Bob Briscoe wrote: > Wes/tsvwg list, > I guess I ought to say I support this work, and I'm still interested > in contributing. > I've been pushing forward on some next research steps, so sorry for > the belated reply. > Bob > > On 16/02/17 19:33, Pat Thaler wrote: >> I'm supportive of this going forward in TSVWG and interested in >> contributing. >> >> On Thu, Feb 16, 2017 at 12:09 AM, Ingemar Johansson S >> > > wrote: >> >> Hi >> >> Yes, I am very interested in this work and will contribute to the >> work. >> >> /Ingemar >> >> > >> > Message: 1 >> > Date: Mon, 6 Feb 2017 23:13:32 -0500 >> > From: Wesley Eddy > > >> > To: "tsvwg@ietf.org " > > >> > Subject: [tsvwg] L4S work in TSVWG >> > Message-ID: >> <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com >> > >> > Content-Type: text/plain; charset=utf-8; format=flowed >> > >> > Hello, as a co-chair, I'm checking to make sure we have the >> critical mass to go >> > forward with L4S in TSVWG. >> > >> > Over time, there has been good discussion on this spread across several lists >> > and groups (ICCRG, AQM, TCP-Prague, etc.). The ADs have asked >> that going >> > forward TSVWG be the home for this work, so I think we can >> limit discussion >> > to TSVWG now (assuming relevant parties are on-list). >> > >> > The three documents at present around this are: >> > >> > 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 >> >> > >> > 2. >> https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00 >> >> > >> > 3. >> https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 >> >> > >> > There was interest in working these in TSVWG at the last IETF >> meeting >> > (noted in the minutes), and we want that discussion to continue >> on the >> > mailing list. >> > >> > Please respond if you're interested in participating in this >> work by helping to >> > review, analyze, implement, test, simulate, deploy, etc. and >> agree that >> > TSVWG should add milestones on the L4S problem, based on the >> current >> > drafts. Or if you have other thoughts, those would be >> interesting too. >> > >> > Thanks! >> > >> > >> > >> >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ --------------6C370ABBD4AD2A907FC86C32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

A good number of people seem interested in L4S, and I haven't noticed any comments against adopting work on it, based on the current 3 drafts.

We are planning time for L4S within the agenda for the 2nd TSVWG session in Chicago: https://datatracker.ietf.org/meeting/98/agenda/tsvwg/

Please let us (chairs) know who would like to speak on this (Bob, Koen, etc.) so we can coordinate timing, etc.



On 3/13/2017 1:48 PM, Bob Briscoe wrote:
Wes/tsvwg list,
I guess I ought to say I support this work, and I'm still interested in contributing.
I've been pushing forward on some next research steps, so sorry for the belated reply.
Bob

On 16/02/17 19:33, Pat Thaler wrote:
I'm supportive of this going forward in TSVWG and interested in contributing.

On Thu, Feb 16, 2017 at 12:09 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

Yes, I am very interested in this work and will contribute to the work.

/Ingemar

>
> Message: 1
> Date: Mon, 6 Feb 2017 23:13:32 -0500
> From: Wesley Eddy <wes@mti-systems.com>
> To: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: [tsvwg] L4S work in TSVWG
> Message-ID: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello, as a co-chair, I'm checking to make sure we have the critical mass to go
> forward with L4S in TSVWG.
>
> Over time, there has been good discussion on this spread across several lists
> and groups (ICCRG, AQM, TCP-Prague, etc.).  The ADs have asked that going
> forward TSVWG be the home for this work, so I think we can limit discussion
> to TSVWG now (assuming relevant parties are on-list).
>
> The three documents at present around this are:
>
> 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00
>
> 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00
>
> 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02
>
> There was interest in working these in TSVWG at the last IETF meeting
> (noted in the minutes), and we want that discussion to continue on the
> mailing list.
>
> Please respond if you're interested in participating in this work by helping to
> review, analyze, implement, test, simulate, deploy, etc. and agree that
> TSVWG should add milestones on the L4S problem, based on the current
> drafts.  Or if you have other thoughts, those would be interesting too.
>
> Thanks!
>
>
>



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

--------------6C370ABBD4AD2A907FC86C32-- From nobody Mon Mar 13 14:39:03 2017 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 DEE09129B52; Mon, 13 Mar 2017 14:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 PRqhu7t9HfyJ; Mon, 13 Mar 2017 14:39:00 -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 81808129BA9; Mon, 13 Mar 2017 14:39:00 -0700 (PDT) Received: from [IPv6:2003:cd:6bd5:6500:2837:f2f1:d6d0:dd0d] (p200300CD6BD565002837F2F1D6D0DD0D.dip0.t-ipconnect.de [IPv6:2003:cd:6bd5:6500:2837:f2f1:d6d0:dd0d]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 35C43721E280C; Mon, 13 Mar 2017 22:38:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: Date: Mon, 13 Mar 2017 22:38:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <80868DBB-3A10-4C25-A5B5-6D4FCE4C737C@lurchi.franken.de> References: To: Magnus Westerlund X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Gorry Fairhurst , tsvwg@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:39:03 -0000 > On 20 Dec 2016, at 16:05, Magnus Westerlund = wrote: Hi Magnus, thank you very much for the review. Please find my comments in-line. Best regards Michael >=20 > Hi, >=20 > I have reviewed -08 in this WG last call and have the following = comments. >=20 > 1. Section 2.1: "Therefore a sender MUST NOT have more than > 2**31 - 1 fragments of a single user message in flight." >=20 > This document uses in "in flight" at three places. I fail to find a = definition of this in this document nor in RFC 4960, that also use it in = a couple of places. I think the right way forward here is probably to = include this issue as one that should be clear in the updated=20 I added a clarification for in flight for messages: A message is considered in flight, if at least on of its I-DATA chunks = is not acknowledged in a non-renegable way. And for fragments: A fragment is considered in flight, if it is not acknowledged in a non-renegable way. > version of RFC 4960. I do consider this a clarity issue if not = addressed. Even if I wonder if it is at all possible to violate it, as = the TSN is not larger field than the FSN. You could have TSN wrap arounds. >=20 > 2. Section 2.2.2: >=20 > The sender MUST NOT be fragmenting more than one user message in any > given stream at any time. At any time, a sender MAY fragment > multiple user messages, each of them on different streams. >=20 > If I have read this document correctly, the above implies something = that maybe should be made more clear. If one has unordered messages, one = could in fact have a transmission schedule for a single stream that = looks like this (MID/FSN): >=20 > 0/0 > 1/0 > 0/1 > 2/0 > 0/3 >=20 > In other words on the same stream have one large fragmented messages, = and multiple non-fragemented messessages overtaking the large fragmented = one? >=20 > I wonder if this should be clarified as being allowed. It is not intended to interleave messages of the same stream. The = intention is to allow interleaving of messages from different streams. So the example you are giving is not allowed. Section 2.2.2 says: This way messages from other streams may be interleaved with the = fragmented message. Please note that this is the only form of interleaving support. For = example, it is not possible to interleave multiple ordered or unordered user messages from the same = stream. To make things clearer, I have added to section 2: The protocol mechanisms described in this document allow the = interleaving of user messages sent on different streams. They do not support the = interleaving of multiple messages (ordered or unordered) sent on the same stream. > 3. Section 2.2.3: >=20 > Upon reception of an SCTP packet containing an I-DATA chunk if the > message needs to be reassembled, then the receiver MUST use the FSN > for reassembly of the message and not the TSN. >=20 > This above assumes that one has identified first the stream based on = SID, and then using the MID of the I-DATA to determine the message the = chunk actually contains. It might be a point to clarify these = assumptions going into the above sentence. OK. Done. Text changed to: Upon reception of an SCTP packet containing an I-DATA chunk whose user message needs to be reassembled, the receiver MUST first use the = SID to identify the stream, consider the U bit to determine if it is part of an = ordered or unordered message, find the user message identified by the MID and = finally use the FSN for reassembly of the message and not the TSN. >=20 > 4. Section 3: >=20 > There appear to be an assumption here that isn't made clear. Namely = that the sender side implementation and the application using the SCTP = implementation instance is the one that selects which stream scheduler = to use. There is no negotiation, not even protocol level indication to = the receiver for what is being used. That means that for applications = that has dependency on what stream scheduling behaviors the far sender = has, needs to communicate that out-of-band or on top of the established = association between the instances. You are right. The receiver doesn't know what scheduler is used by the = peer. It can even change during the lifetime of the association. In the WebRTC use case it is simple. The specification = tells both sides which scheduler to use. >=20 > To be clear I don't have a pressing case where this would be a = problem, but I think it should be made explicit these assumptions. I added the following clarification: The selection of the stream scheduler is done at the sender side. = There is no mechanism provided for signalling the stream scheduler being used to the receiver side or even let the receiver side influence the = selection of the stream scheduler used at the sender side. >=20 > 5. Section 3.2: >=20 > When not using user message interleaving, this scheduler provides a > fair scheduling based on the number of user messages by cycling > around non-empty stream queues. When using user message > interleaving, this scheduler provides a fair scheduling based on the > number of I-DATA chunks by cycling around non-empty stream queues. >=20 > I think this description is insufficient to produce a behaviour that = is consistent between implementors. I find it lacking in explanation on = a couple of different aspects. >=20 > A. Ordering of the stream specific queues. When a message is added to = a stream that had nothing queued, is that stream handled in stream ID = order, or is the stream added as the last in the list/ cyclic queue of = the current streams having data to send? I think you can do either. It results in the same overall behaviour. So = it is left implementation specific. >=20 > B. The behaviour when adding chunks to a packet. For non interleaved, = I assume this one will add a DATA chunk from the next stream, assuming = it will fit within in MTU boundaries, else send. For I-DATA should one = fill up the packet to the MTU boundary and then send the=20 If you have space in the packet you can even put a DATA chunk in the = packet, which contains the beginning of the next user message. It doesn't have to be a complete user message. > packet, independently how many bytes of message data that fits? When using I-DATA, you just select the next stream after sending each = I-DATA chunk. >=20 >=20 > 6. Section 3.3: >=20 > This is a round-robin scheduler but bundles only DATA or I-DATA > chunks referring to the same stream in a packet. This minimizes > head-of-line blocking when a packet is lost because only a single > stream is affected. >=20 > In this case, for non-interleaved, am I allowed to fit the next = message into the SCTP packet, if it can fit in the remaining size before = MTU, or does this scheduler result in under utilized packets? As long as the next message belongs to the same stream, you can put it = in. >=20 > For fragmented, I will assume that I am allowed to fill one packet = worth of chunks from this stream, independent of how many messages that = implies? Yes. >=20 > 7. Section 3.5: >=20 > This > scheduler considers the lengths of the messages of each stream and > schedules them in a certain way to maintain an equal bandwidth for > all streams. >=20 > Is the above taking only the scheduled for transmission into account, = or is also past transmissions relevant in the scheduling decision = between streams? That is left implementation dependent. The goal is that all streams get = an equal bandwidth within some time constraints. >=20 > 8. Section 4.3.1: >=20 > Some implementations might > therefore put some restrictions on setting combinations of these > values. >=20 > This doesn't appear to be sound API definitions. Wouldn't it be = clearer to actually either require to option to be set prior, or = alternatively, setting this, causing the other to also be set to avoid = issues? Implementations might do this differently or have different principles = of protecting the user. In FreeBSD, for example, we fail the enabling of the user message = interleaving if the interleaving level is not set to 2. The automatic change of other variables is = something I'm not preferring. I have added a sentence which describes a save way to enable it: Setting the interleaving level to at least 2 before enabling the = negotiation of user message interleaving should work on all platforms. >=20 > 9. Section 6: >=20 > This document does not add any additional security considerations in > addition to the ones given in [RFC4960] and [RFC6458]. >=20 > It should be noted that the application has to consent that it is > willing to do the more complex reassembly support required for user > message interleaving. >=20 > I think this is an insufficient security consideration section. It = hints at a receiver resource exhaustion attack. I think that should be = made clear what this attacks entail, and what mitigations that can be = considered. OK. I changed the text to: It should be noted that the application has to consent that it is = willing to do the more complex reassembly support required for user message interleaving. When doing so, an application has to provide up to two = reassembly buffers (one for ordered messages, one for unordered messages) for each = incoming stream. It has to protect itself against these buffers taking too many = resources. If user message interleaving is not used, only a single reassembly = buffer needs to be provided. But the application has to protect itself for excessive = resource usages there too. > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Mon Mar 13 14:42:44 2017 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 ED6E5127058; Mon, 13 Mar 2017 14:42:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944136394.20353.7281870486630242181@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:42:43 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:42:44 -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 of the IETF. Title : Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol Authors : Randall R. Stewart Michael Tuexen Salvatore Loreto Robin Seggelmann Filename : draft-ietf-tsvwg-sctp-ndata-09.txt Pages : 20 Date : 2017-03-13 Abstract: The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-09 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 Mar 13 14:49:22 2017 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 7271C129477; Mon, 13 Mar 2017 14:49:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944176045.20385.4408697945662176057@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:49:20 -0700 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:49: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 of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Address Translation Support Authors : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-natsupp-10.txt Pages : 44 Date : 2017-03-13 Abstract: The Stream Control Transmission Protocol (SCTP) provides a reliable communications channel between two end-hosts in many ways similar to the Transmission Control Protocol (TCP). With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). This document describes the protocol extensions required for the SCTP endpoints and the mechanisms for NATs necessary to provide similar features of NAPT in the single-point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-natsupp-10 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 Mar 13 15:43:34 2017 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 E7BF9129BC6 for ; Mon, 13 Mar 2017 15:43:32 -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, 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=bobbriscoe.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 18xdc2k5IBiZ for ; Mon, 13 Mar 2017 15:43:27 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 B283C129BA7 for ; Mon, 13 Mar 2017 15:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject: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=4GWlMAq6OMmSjvuusKMhThah8G24cstNN9pIBPUHeo0=; b=Sda+UBhc3R1Ym8zGLWfp5Twgx wJzguIhzXKNUxa7G2CHvLtOSaT/dV+iDiVdCIwNUCRNGBmUL65lbswhoy6JfrnmwZ1FJOkadaUVmJ u9HzmOLBBCEgiIUE954gHz53TD38xka4uytfzjDYDJGnwd4tCkRTkdhDXQhnbEgfBQxlwLaWpa4+9 cPKtkm7dhT8Bo/l79efU0ZN0JA25HHZdP90oTJrwj1KUKXtJHEKQFh9pcT8HUMMqRXugwbzR2+LB0 Bs5RJ9uaghVAy9UDXzw2k73BGKwqN61/8scDGv0xpKScGOrSmBc+YoqZIgUp3qZGg+ULUKcvQBeeW vh8Q9F6pg==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:36548 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cnYgW-0003rs-5v; Mon, 13 Mar 2017 22:43:24 +0000 To: Wesley Eddy , "tsvwg@ietf.org" References: From: Bob Briscoe Message-ID: <5f82ba36-0d7b-a208-d53d-b034beef51f5@bobbriscoe.net> Date: Mon, 13 Mar 2017 22:43:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9B08D48BD7136865E13243D4" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] comments on L4S architecture draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:43:33 -0000 This is a multi-part message in MIME format. --------------9B08D48BD7136865E13243D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Wes, Thank you v much for these comments. Inline... On 07/02/17 04:48, Wesley Eddy wrote: > I have some comments to share on the architecture draft: > https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 > > These are mostly positive comments, and many can be considered > longer-term, in my opinion, not urgent nor blocking adopting in TSVWG. > > 1. It seems to me that L4S can address some pain points that operators > have. I'm sure the authors have got some input on this from > operators, but it might be good to include more of a deployment > walkthrough in the draft. It mentions incremental deployment as being > possible, but I think there could be a more clear discussion of what > incremental utility there is, how to start, etc. I've addressed all your other points, but I would have needed to be in a more relaxed and creative mood to write this well, so I've just added some place-holder bullets for the next revision. > > 2. I think the real "selling point" is that operators won't need to > provision separate transport underlays for certain high-performance > applications (e.g. that might use DCTCP) versus other traffic. L4S > can enable better performance with less pre-configuration, baked-in > settings, or twiddling with knobs. The draft doesn't really seem to > directly attack the current practices of partitioning resources and > how labor-intensive and fragile this can be. L4S could be a big > improvement for some people. In S. 5.2 we said Also, because L4S is for all traffic, it needs none of the management baggage (traffic policing, traffic contracts) associated with favouring some packets over others. This baggage has held Diffserv back from widespread end-to-end deployment. But I've assumed you are saying you want to see something about zero config in the Intro. Done. > > 3. In addition to being an architecture description, the draft also > serves as a bit of a "work plan" for what needs to be done (e.g. in > Section 4). The wording is a bit strong sometimes, saying things > "need" to be done, but really the benefits of L4S can accrue > incrementally as some of that work happens, and some of the work items > mentioned may not really be needed at all. For instance, DCCP > scalable CC doesn't need to be in place for L4S to have benefit, and > L4S wouldn't fail just because none of the existing mostly-unused DCCP > codebases implement the new CCID. What truly "needs" to happen to > start showing benefits could be better distinguished from what > ultimately could happen. Agreed, and dealt with. > > 4. The caption on Figure 1 has incorrect numbering with regard to the > figure (number 1 and 2 are swapped in the caption, I believe). > Additionally, in the text above the figure, bullet numbering order of > 2, 1, 3 is stressful to read (though I think was probably done on > purpose for left-right relation to the diagram?). Yeah. Originally the numbering lined up with the requirements in the Appendix. But the requirements got renumbered in subsequent edits, so I've destressed the bullet numbering for you. > > 5. In the discussion of ECN at the beginning of section 5.1, it could > be more clear that this is in regard to traffic in the L4S class, and > that other traffic using the "classic" queue doesn't need to use ECN. Done. > > 6. Some of the comparison/contrast statements with fq_codel don't seem > quite right, since FQ is achieving a different goal than simply > enabling scalable and classic traffic to coexist. For instance, FQ is > also limiting impact of very bad-behaving flows on other flows (e.g. > bad flows may follow neither the scalable nor classic paradigms of CC!). I have altered it to clarify that fq regulates the interplay between flows by default whereas, in the L4S approach, policing can be added as a separate policy choice. > > 7. Another possible use case for section 6 might be networks where > service function chaining is prevalent and delay across the network > needs to be minimized because traffic is criss-crossing through > possibly odd paths that are much different than just the shortest set > of physical hops between source and destination. I haven't said it this way, because it's a bit negative. Paraphrasing, you're saying, if your delay due to routing is rubbish, you've got less delay budget left for queuing delay. Instead, I've generalized and given a more positive spin: "Applications with a fixed delay budget can communicate over longer distances, or via a longer chain of service functions or onion routers, if queuing delay is lower." > > 8. Virtual switch implementations may be important in addition to > physical. Not added. I don't think it would add anything to list all the different types of implementation that might be necessary - nothing L4S specific about such a list. > > 9. Would onion routing systems also be a potential beneficiary of L4S, > if they used scalable transports? They normally have a lot of delay > and delay variation. > > 10. The benefits and descriptions in the document make sense to me, > but I also know of the history and related work that the document > builds upon. I wonder if it's as clear to other people coming fresh? > For many operations type of people, this may be the case, so feedback > there would be useful, I think. OK. I won't add anything yet. We'll try to get wider review - probably at least during IESG processing. > > 11. Some of the text represents a state of affairs that will change > (e.g. page 7 discussing progress), and it should be considered whether > this stuff would be of value to go into an RFC or not. Yeah. I've started to try to make it more timeless. But as new things come up, I am adding them (e.g. possibility of L4S variant of QUIC). So as all the related stuff matures, it should gradually take the form of a list of pointers to related components, without having to comment on their maturity. Thanks for this nice set of points. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------9B08D48BD7136865E13243D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Wes,

Thank you v much for these comments. Inline...

On 07/02/17 04:48, Wesley Eddy wrote:
I have some comments to share on the architecture draft: https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00

These are mostly positive comments, and many can be considered longer-term, in my opinion, not urgent nor blocking adopting in TSVWG.

1. It seems to me that L4S can address some pain points that operators have.  I'm sure the authors have got some input on this from operators, but it might be good to include more of a deployment walkthrough in the draft.  It mentions incremental deployment as being possible, but I think there could be a more clear discussion of what incremental utility there is, how to start, etc.
I've addressed all your other points, but I would have needed to be in a more relaxed and creative mood to write this well, so I've just added some place-holder bullets for the next revision.

2. I think the real "selling point" is that operators won't need to provision separate transport underlays for certain high-performance applications (e.g. that might use DCTCP) versus other traffic.  L4S can enable better performance with less pre-configuration, baked-in settings, or twiddling with knobs. The draft doesn't really seem to directly attack the current practices of partitioning resources and how labor-intensive and fragile this can be.  L4S could be a big improvement for some people.
In S. 5.2 we said
      Also, because L4S
      is for all traffic, it needs none of the management baggage
      (traffic policing, traffic contracts) associated with favouring
      some packets over others.  This baggage has held Diffserv back
      from widespread end-to-end deployment.
But I've assumed you are saying you want to see something about zero config in the Intro. Done.

3. In addition to being an architecture description, the draft also serves as a bit of a "work plan" for what needs to be done (e.g. in Section 4).  The wording is a bit strong sometimes, saying things "need" to be done, but really the benefits of L4S can accrue incrementally as some of that work happens, and some of the work items mentioned may not really be needed at all.  For instance, DCCP scalable CC doesn't need to be in place for L4S to have benefit, and L4S wouldn't fail just because none of the existing mostly-unused DCCP codebases implement the new CCID. What truly "needs" to happen to start showing benefits could be better distinguished from what ultimately could happen.
Agreed, and dealt with.

4. The caption on Figure 1 has incorrect numbering with regard to the figure (number 1 and 2 are swapped in the caption, I believe).  Additionally, in the text above the figure, bullet numbering order of 2, 1, 3 is stressful to read (though I think was probably done on purpose for left-right relation to the diagram?).
Yeah. Originally the numbering lined up with the requirements in the Appendix. But the requirements got renumbered in subsequent edits, so I've destressed the bullet numbering for you.

5. In the discussion of ECN at the beginning of section 5.1, it could be more clear that this is in regard to traffic in the L4S class, and that other traffic using the "classic" queue doesn't need to use ECN.
Done.

6. Some of the comparison/contrast statements with fq_codel don't seem quite right, since FQ is achieving a different goal than simply enabling scalable and classic traffic to coexist.  For instance, FQ is also limiting impact of very bad-behaving flows on other flows (e.g. bad flows may follow neither the scalable nor classic paradigms of CC!).
I have altered it to clarify that fq regulates the interplay between flows by default whereas, in the L4S approach, policing can be added as a separate policy choice.

7. Another possible use case for section 6 might be networks where service function chaining is prevalent and delay across the network needs to be minimized because traffic is criss-crossing through possibly odd paths that are much different than just the shortest set of physical hops between source and destination.
I haven't said it this way, because it's a bit negative. Paraphrasing, you're saying, if your delay due to routing is rubbish, you've got less delay budget left for queuing delay.

Instead, I've generalized and given a more positive spin:
"Applications with a fixed delay budget can communicate over longer distances, or via a longer chain of service functions or onion routers, if queuing delay is lower."

8. Virtual switch implementations may be important in addition to physical.
Not added. I don't think it would add anything to list all the different types of implementation that might be necessary - nothing L4S specific about such a list.


9. Would onion routing systems also be a potential beneficiary of L4S, if they used scalable transports?  They normally have a lot of delay and delay variation.

10. The benefits and descriptions in the document make sense to me, but I also know of the history and related work that the document builds upon.  I wonder if it's as clear to other people coming fresh?  For many operations type of people, this may be the case, so feedback there would be useful, I think.
OK. I won't add anything yet. We'll try to get wider review - probably at least during IESG processing.

11. Some of the text represents a state of affairs that will change (e.g. page 7 discussing progress), and it should be considered whether this stuff would be of value to go into an RFC or not.
Yeah. I've started to try to make it more timeless. But as new things come up, I am adding them (e.g. possibility of L4S variant of QUIC). So as all the related stuff matures, it should gradually take the form of a list of pointers to related components, without having to comment on their maturity.

Thanks for this nice set of points.

Cheers



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------9B08D48BD7136865E13243D4-- From nobody Wed Mar 15 08:36:39 2017 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 6DF191316A4 for ; Wed, 15 Mar 2017 08:36:37 -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, RP_MATCHES_RCVD=-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 CMEGzJmncNfO for ; Wed, 15 Mar 2017 08:36:36 -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 143DD1316A1 for ; Wed, 15 Mar 2017 08:36:36 -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 8EAB31B018B8 for ; Wed, 15 Mar 2017 17:33:49 +0000 (GMT) Message-ID: <58C95F69.6000803@erg.abdn.ac.uk> Date: Wed, 15 Mar 2017 15:36:09 +0000 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.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] TSVWG Draft Agenda, for Chicago IETF 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, 15 Mar 2017 15:36:37 -0000 Hi all, We have uploaded a draft agenda to https://www.ietf.org/proceedings/98/agenda/agenda-98-tsvwg-05. This is a *draft* and is not final, so do feel free to bash, and/or confirm your presentation if you have not yet done so ;-) Gorry, David and Wes (TSVWG Co-Chairs) From nobody Fri Mar 17 18:10:19 2017 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 26146129671 for ; Fri, 17 Mar 2017 18:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 evHe_CqYyTxV for ; Fri, 17 Mar 2017 18:10:16 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 7F7A61296E7 for ; Fri, 17 Mar 2017 18:04:03 -0700 (PDT) Received: from [128.9.184.195] ([128.9.184.195]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2I13icr002086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Mar 2017 18:03:44 -0700 (PDT) To: "C. M. Heard" References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> Cc: Mark Smith , tsvwg From: Joe Touch Message-ID: Date: Fri, 17 Mar 2017 18:03:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v2I13icr002086 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Sat, 18 Mar 2017 01:10:18 -0000 Hi, all, The queue has closed, but I have a new version of UDP options 06 that will post as soon as it opens (why do we still do this?) Here's a pointer in the meantime: http://www.isi.edu/touch/pubs/draft-touch-tsvwg-udp-options-06.txt It includes Mike's nice observation about combining FRAG and LITE, clarifies some nits about what happens in each order, etc. I tried to keep things simple, so LITE comes first when it's used, FRAG stops processing until reassembly, and things pick up after reassembly with options included after the last fragment. I think that's clean... Thanks all - Gorry will be presenting this (I hope it's not gotten too complex), Feedback welcome, of course, Joe From nobody Mon Mar 20 23:16:42 2017 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 BB33012953F for ; Mon, 20 Mar 2017 23:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 m_KQiFT0fCpB for ; Mon, 20 Mar 2017 23:16:36 -0700 (PDT) Received: from mail.mera.ru (mail.mera.ru [195.98.57.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C476D129532 for ; Mon, 20 Mar 2017 23:16:35 -0700 (PDT) Received: from cmail.merann.ru ([192.168.50.122]) by mail.mera.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1cqD4X-000Psy-Jg; Tue, 21 Mar 2017 09:15:09 +0300 Received: from e16srv02.merann.ru (192.168.50.32) by cmail.merann.ru (192.168.50.122) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 21 Mar 2017 09:16:30 +0300 Received: from e16srv02.merann.ru (2001:67c:2344:50::32) by e16srv02.merann.ru (2001:67c:2344:50::32) with Microsoft SMTP Server (TLS) id 15.1.225.42; Tue, 21 Mar 2017 09:16:30 +0300 Received: from e16srv02.merann.ru ([fe80::a02c:8709:f287:d16c]) by e16srv02.merann.ru ([fe80::a02c:8709:f287:d16c%12]) with mapi id 15.01.0225.041; Tue, 21 Mar 2017 09:16:30 +0300 From: "Proshin, Maksim" To: Michael Tuexen CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 Thread-Index: AQHSWgChCkg2HCaxb0Ww0RyyFOJkOaEPTU0BgIOeMwCAC2VfkA== Date: Tue, 21 Mar 2017 06:16:30 +0000 Message-ID: <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> References: <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> In-Reply-To: <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.201.113] x-inside-org: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 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, 21 Mar 2017 06:16:40 -0000 Hi Michael, Basically I'm ok with all your answers and updates.=20 I don't have any major comments but I have a few proposals below inline (by= [Maksim] tag). BR, Maksim -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Sent: Monday, March 13, 2017 14:00 To: Proshin, Maksim Cc: tsvwg@ietf.org Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 = Dec 2016 > On 19 Dec 2016, at 17:16, Proshin, Maksim wrote: >=20 > Hi, >=20 > Thanks for the document! Please find below some comments. Only major comm= ents are included while editorial/minor comments have been sent directly to= Michael. Hi Maxim, thanks a lot for the review. I addresses the minor comments and responded t= o your mail. See my comments in-line. Best regards Michael >=20 > 1. Section 1.1: "DATA chunks are not > permitted when I-DATA support has been negotiated." > What exactly does it mean for implementation (both sending and=20 > receiving sides)? I think to avoid any problems with the sending side=20 > it should be "MUST NOT" in the sentence. For the receiving side I=20 > suppose it means stop processing of the packet and silently discard=20 > all further chunks in the packet, right? I think this should be=20 > clearly stated. It could also be good to clearly state that after=20 > association I think it is clearly stated in 2.2.1: If I-DATA support has been negotiated for an association, I-DATA chunks MUS= T be used for all user messages and DATA-chunks MUST NOT be used. If I-DATA= support has not been negotiated for an association, DATA chunks MUST be us= ed for all user messages and I-DATA chunks MUST NOT be used. [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the sender.= Can the same be explained for the receiver? So if these rules are violated, I think sending an ABORT with protocol viol= ation might be appropriate. [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it would be g= ood to state that such case should be treated as a protocol violation. I al= so wonder that it should be mentioned that the restart case is different an= d should not be treated as a violation.=20 > restart which was with DATA previously but became with I-DATA after the r= estart, SCTP still may receive packets with DATA and they should be silentl= y discarded due to VTag mismatch following the rules of Section 8.5. from R= FC4960 (I suppose this is important to avoid any "protocol violation" react= ion).=20 Sure. But this is normal restart behavior. [Maksim] The reason I've asked it is because the statement is that this is = "permitted" while in the restart case it is still possible to receive DATA = while I-DATA was already negotiated. >=20 > 2. Section 2.1:=20 > The only differences between the I-DATA chunk in Figure 3 and the > DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the > new Message Identifier (MID) and Fragment Sequence Number (FSN) and > the removal of the Stream Sequence Number (SSN). > The B bit now has a different (extended) purpose and also specifies if PP= ID or FSN is used. I think it should be stated. OK. I added: The Payload Protocol Identifier (PPID) and the FSN are stored at the same l= ocation of the packet using the B-bit to determine which value is stored at= the location. >=20 > 3. I suppose the draft assumes that SCTP still MAY (i.e. not SHOULD/MUST)= support fragmentation even with I-DATA and MUST (i.e. not MAY/SHOULD) supp= ort re-assembling. If so, I suggest to clearly state it. Yes, this hasn't changed. I think we don't need to repeat this point. Espec= ially since I have not see an implementation not supporting fragmentation..= . >=20 > 4. Is RFC6096 impacted by new chunks? No. It only deals with old chunks. When defining a new chunk, you have to d= efine the corresponding flags registry as we do in this document. >=20 > 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated durin= g the SCTP > association setup via the Supported Extensions Parameter as defined > in [RFC5061]. Only if both end points support the I-DATA chunk and > the I-FORWARD-TSN chunk, the partial reliability extension can be > used in combination with user message interleaving. > Not sure how implementation should behave if either of these chunks is un= supported. I think it should be clearly stated. > Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the partia= l reliability functionality should be completely off, i.e. not fallback to = FORWARD-TSN.=20 > If I-DATA is not supported but I-FORWARD-TSN is supported (strange implem= entation but still according to the draft as it does not prohibit the oppos= ite), it seems both functionalities message interleaving and partial reliab= ility should be off, i.e. there is no way to fallback to FORWARD-TSN, right= ? =20 Right. > Should the draft state something like "If I-DATA chunk is not used, I-FOR= WARD-TSN chunk MUST NOT be used."? There is already text there: The FORWARD-TSN chunk MUST be used in combination with the DATA chunk and M= UST NOT be used in combination with the I-DATA chunk. The I- FORWARD-TSN c= hunk MUST be used in combination with the I-DATA chunk and MUST NOT be used= in combination with the DATA chunk. >=20 > 6. Section 4.1:=20 > MID is 32 bits while SSN is 16 bits so why a new SCTP Receive Information= Structure cannot be introduced instead of using the existing one? One could add such a structure, but is it needed? I don't see a use-case... [Maksim] Isn't the drawback of the current approach is that 16 bits are los= t? > If the new SCTP Receive Information Structure is introduced then a new me= ssage receive function should also be introduced (instead of recv_msg() ). = Is that the main problem? recvmsg() is generic. It doesn't need to be changed. You would add another = CMSG. > Of course, it would also be a problem if the interleaving functionality r= equires enabling only on the sender side (see the next comment). No, it is required to be enabled on both sides. >=20 >=20 > 7. Section 4.3.1: > User message interleaving is disabled per default. > I'm not sure about it. First of all I think it should be clearly stated w= hat does it mean for the sender and for the receiver. > If the intention was that I-DATA is included to INIT and INIT ACK only wh= en the user enabled this functionality then I think this is not a good way = because then it impacts not only the sender but also the receiver.=20 > In other words, if the feature is disabled by default on both sides while= SCTP on both sides support it then it is not enough to just enable it on o= ne side, it requires enabling it on the other side. =20 Exactly. I think this is stated in the first sentence of 2.2.1. [Maksim] I think it is not clearly stated in the document. "Supported" does= not really mean "enabled". I would clearly state that this functionality s= hould be enabled on both sides and only in this case it could be successful= ly negotiated. Especially it is important to state for the receiver side be= cause Section 2.2.1 has the following statement "A sender MUST NOT use the = I-DATA chunk unless the user has requested its use (e.g. via the socket API= , see Section 4.3)."=20 >=20 > 7. Section 4.3.1: Why don't specify exactly value 1 for the enabled feat= ure? Otherwise, in the future it will be difficult to use another value of = this parameter for a different purpose as it will be non-backward compatibl= e (old application and new SCTP may work improperly). Since it is the standard way of encoding a flag in an int... >=20 > 8. Section 5 does not cover I-FORWARD-TSN. Good point. I added corresponding text. >=20 > 9. Section 6: In case of DTLS over SCTP support of the message interleavi= ng functionality may increase the risk of receiving messages with new epoch= after ChangeCipherSpec message and before Finished message. Possibly. But implementations have to deal with it anyway. So what is the p= oint? [Maksim] Mainly my point was that it could be clarified so that future SCTP= implementations of this draft/RFC supporting DTLS could consider it.=20 >=20 >=20 > BR, Maksim >=20 >> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk: >>=20 >>=20 >> This mail announces a TSVWG Working Group Last Call (WGLC) on: >>=20 >> Stream Schedulers and User Message Interleaving forSCTP >> draft-ietf-tsvwg-sctp-ndata=20 >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata >>=20 >> This WGLC will last for 2 weeks weeks. >>=20 >> Comments should be sent to the tsvwg@ietf.org list, although purely=20 >> editorial comments may be sent directly to the authors. Please cc:=20 >> the WG chairs at tsvwg-chairs@ietf.org if you would like the chairs=20 >> to track such editorial comments as part of the WGLC process. >>=20 >> No IPR disclosures have been submitted directly on=20 >> draft-ietf-tsvwg-sctp-ndata. >>=20 >> Thanks, >> Gorry >> (TSVWG Co-Chair) From nobody Wed Mar 22 02:51:28 2017 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 919E413167B for ; Wed, 22 Mar 2017 02:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 3TCWImxDmkvM for ; Wed, 22 Mar 2017 02:51:25 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA56E129471 for ; Wed, 22 Mar 2017 02:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1490176285; x=1521712285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/ctDtE0bVtiNVDf+RFtl1GDBtjbM87lHB6cQNL288jQ=; b=7Gz5FGpb0XCM5ZGIK+BzI2Qzck+tfivtui95Zca57oiDDdiNtRcMRNJP nP/3wCp+VpwhMWwVna2NX1ktV5l6j9ll8EWATGrr7p5nZHIGrN/AZNvgV 1PdRuAmgtv7ibRm5ljxUfleUqmM5utyao/9MS4IE7mRgLW2uhz8g4Xech 2Nyszbz9MQ3V3tedNiXspMN084FYFMMDFOLC1nQYoTJXt/rMqoPXK1UFY XaW20vaCxnbOnbKWDceOaLBznM1olLNIl/0j4CYpZ07jbqVms0ieRRd6p 0VjrNjSnvplIcborwU/0gCeZv1GKgRCJ+hcIFK3ul4FiHmyq7B6YQK58g g==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 22 Mar 2017 10:51:23 +0100 X-IronPort-AV: E=Sophos;i="5.36,204,1486422000"; d="scan'208";a="1288421315" Received: from he101659.emea1.cds.t-internal.com ([10.134.226.19]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2017 10:51:22 +0100 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101659.emea1.cds.t-internal.com (10.134.226.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 22 Mar 2017 10:51:22 +0100 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Wed, 22 Mar 2017 10:51:22 +0100 From: To: Thread-Topic: LE PHB -01 draft comments (from David Black) Thread-Index: AdKUeigkfiSLH844TRKlBvACYyszEQOa++Cw Date: Wed, 22 Mar 2017 09:51:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.203.41.223] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] LE PHB -01 draft comments (from David Black) 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, 22 Mar 2017 09:51:27 -0000 Hallo Roland, the draft reads better now. David commented version 01 and I'd like to pick= up some of his content related comments (marked [DB]) and add some own one= s (marked [RG]). Regards, Ruediger -- Section 1 [DB] The last bullet in Section 1.1. contains some discussion of "downgrade= d"=20 that goes beyond an example, and ought to be merged into the last paragraph= =20 on p.3. [RG] I share David's point of view. -- Section 1.2 [RG] OLD: No harm to other traffic: since the LE PHB has got the lowest forwarding priority it does not consume resources from other PHBs. Deployment across different provider domains causes no trust issues or attack vectors to existing traffic. NEW No harm to traffic of other PHBs: since packets marked for LE PHB=20 are dropped prior to packets of any other PHB, they don't consume=20 resources required by other PHBs. Deployment across different=20 provider domains causes no trust issues or attack vectors to=20 traffic of other PHBs. ----------------------- [DB] I wonder whether the 2nd and 3rd bullets are overstated.=A0 There is s= ome=20 network switch/router configuration required and something like a low prior= ity=20 queue has to be set up to drop LE traffic when there are other competing us= es.=A0=A0=20 I don't think the bullets are actually wrong, but some additional text to p= oint=20 out what does have to be done to use the LE PHB would be helpful. [RG] I share David's point of view. -- Section 2 [DB] OLD =A0=A0 Ideally, LE packets SHOULD be forwarded only if no best- =A0=A0 effort packet is waiting for its transmission. NEW =A0=A0 Ideally, LE packets SHOULD be forwarded only if no packet =A0=A0 with any other PHB is awaiting transmission. [DB] Understated - should apply to all PHBs, not just default. [RG] Agree with David. ---------- [RG] There are more options to produce LE: a router may offer=20 a committed/excess traffic configuration. committed rate/weight=20 could be 0 for LE, only an excess rate/weight may be configured.=20 If the default PHB has a committed rate above 0 and the default=20 PHB excess weight is bigger than LE, LE shouldn't be able to=20 seize capacity from default PHB. If RED is deployed, Default PHB and LE may be produced using=20 the same queue. All LE traffic should be dropped by RED prior=20 to the first Default PHB packet. --Section 5 [RG] I wonder, whether ECN related aspects should be discussed: - should any LE traffic be dropped prior to ECN marks for any=20 other PHB? I think, that is true if ECN is used to indicate=20 congestion. - should LE be able to support ECN? Or are LE packet drops the=20 only reaction in the case of congestion. -- Section 8 [RG] Unauthorised marking of traffic as LE may be regarded as=20 a kind of denial of service.=20 On the other hand, may re-marking traffic which is assumed to=20 be dDoS traffic as LE be an alternative to dropping this=20 traffic (I can't judge that, may be in some special cases?). From nobody Wed Mar 22 18:52:47 2017 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 53DDA1293FD for ; Wed, 22 Mar 2017 18:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 S4NoWNkFrOQ8 for ; Wed, 22 Mar 2017 18:52:43 -0700 (PDT) Received: from sasl.smtp.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 5E5BA128AB0 for ; Wed, 22 Mar 2017 18:52:43 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 55F46826FD for ; Wed, 22 Mar 2017 21:52:42 -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=c7HUDIen5IJ1acr03PlR9SvI99M=; b=vcSz0x mlJY67r60mTBxgYabjl5LxokGjTZGYliIfS7X5cyBk7BW7Sgnr1zdJAPCEwZ9/CG rMyWlKNbFf8IzGtaiZvcL+oFAnNr6zLEwnMm/iq2bYBRb3JmxkGkchcb5UKiVjwa E2VpwiAfqvv418dANL9TuSLjiPZ/BRGxXWRcs= 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=AIBP2y0JfitWBI4EoqQAeTzfyVivCDJv oMSh8IPxHwwKoSx+3Q+b5UrVnA3fi+IlHI8gAGdt6JzuhAPJVQPl3YEjNQ/taUtv 3Vc8bYnWlc5h1LWqbgRcQ17+P9FtGhycPUXHbfnNw0CwRnoFfzoMDXax82ot+0oa AwS00qfPAgs= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 4F7CF826FC for ; Wed, 22 Mar 2017 21:52:42 -0400 (EDT) Received: from mail-qt0-f182.google.com (unknown [209.85.216.182]) (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 DF683826FB for ; Wed, 22 Mar 2017 21:52:41 -0400 (EDT) Received: by mail-qt0-f182.google.com with SMTP id x35so164433815qtc.2 for ; Wed, 22 Mar 2017 18:52:41 -0700 (PDT) X-Gm-Message-State: AFeK/H2zMPaJ8ZYqSOJ/4BAeGUbpdciHo2lCoDz4Bo2QVFIgQFg/qX41Z94VNxU+EHNvp9xqL5Bv5mdp/2x6VA== X-Received: by 10.200.53.45 with SMTP id y42mr10414qtb.267.1490233961370; Wed, 22 Mar 2017 18:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Wed, 22 Mar 2017 18:52:20 -0700 (PDT) In-Reply-To: References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> From: "C. M. Heard" Date: Wed, 22 Mar 2017 18:52:20 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: Mark Smith , tsvwg Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 66D52A5E-0F6B-11E7-8604-97B1B46B9B0B-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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, 23 Mar 2017 01:52:45 -0000 On Fri, Mar 17, 2017 at 6:03 PM, Joe Touch wrote: > The queue has closed, but I have a new version of UDP options 06 that > will post as soon as it opens (why do we still do this?) > > Here's a pointer in the meantime: > > http://www.isi.edu/touch/pubs/draft-touch-tsvwg-udp-options-06.txt > > It includes Mike's nice observation about combining FRAG and LITE, > clarifies some nits about what happens in each order, etc. > > I tried to keep things simple, so LITE comes first when it's used, FRAG > stops processing until reassembly, and things pick up after reassembly > with options included after the last fragment. I think that's clean... Agreed, I like the way you have done this, with the final fragment being indicated by including a checksum. That said, the following text: >> A host SHOULD indicate FRAG support by transmitting an unfragmented datagram using the Fragmentation option (e.g., with Offset and M both zero), except when encoded as LITE. needs to be adjusted owing to elimination of the M bit in favor of a whole-datagram checksum. Regarding the whole-datagram checksum: it would IMHO be appropriate to be very specific as to what it is. I would propose the standard Internet checksum without a pseudo-header, with the value 0x0000 indicating the absence of a checksum. Other comments: In section 5.4, was a decision made as to what the CRC16 is? Details will be needed in order to ensure interoperability. In Section 9, third paragraph, you may want to make the following change: OLD: This feature is also inconsistent with the UDP application interface [RFC768] [RFC1122]. NEW: This feature is also inconsistent with the UDP application interface [RFC1122]. in view of the following text in RFC 768: IP Interface ------------- The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header. One possible UDP/IP interface would return the whole internet datagram including all of the internet header in response to a receive operation. Such an interface would also allow the UDP to pass a full internet datagram complete with header to the IP to send. The IP would verify certain fields for consistency and compute the internet header checksum. Thanks and regards, Mike Heard From nobody Wed Mar 22 22:43:59 2017 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 BE5EB1293DF for ; Wed, 22 Mar 2017 22:43:57 -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, RP_MATCHES_RCVD=-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 OBzWlxSddkbV for ; Wed, 22 Mar 2017 22:43:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 336EC120227 for ; Wed, 22 Mar 2017 22:43:56 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2N5hKdI021429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Mar 2017 22:43:22 -0700 (PDT) To: "C. M. Heard" References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> Cc: Mark Smith , tsvwg From: Joe Touch Message-ID: <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> Date: Wed, 22 Mar 2017 22:43:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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, 23 Mar 2017 05:43:58 -0000 Hi, Mike, On 3/22/2017 6:52 PM, C. M. Heard wrote: > On Fri, Mar 17, 2017 at 6:03 PM, Joe Touch wrote: >> The queue has closed, but I have a new version of UDP options 06 that >> will post as soon as it opens (why do we still do this?) >> >> Here's a pointer in the meantime: >> >> http://www.isi.edu/touch/pubs/draft-touch-tsvwg-udp-options-06.txt >> >> It includes Mike's nice observation about combining FRAG and LITE, >> clarifies some nits about what happens in each order, etc. >> >> I tried to keep things simple, so LITE comes first when it's used, FRA= G >> stops processing until reassembly, and things pick up after reassembly= >> with options included after the last fragment. I think that's clean...= > Agreed, I like the way you have done this, with the final fragment bein= g > indicated by including a checksum. That said, the following text: > >>> A host SHOULD indicate FRAG support by transmitting an > unfragmented datagram using the Fragmentation option (e.g., with > Offset and M both zero), except when encoded as LITE. > > needs to be adjusted owing to elimination of the M bit in favor of a > whole-datagram checksum. Thanks for the catch. I'll fix that in -06. > Regarding the whole-datagram checksum: it would IMHO be appropriate to > be very specific as to what it is. I would propose the standard Interne= t > checksum without a pseudo-header, with the value 0x0000 indicating the > absence of a checksum. It does say "IP checksum over the reassembled payload", which could be "optional Internet checksum over the reassembled UDP payload (i.e., excluding the IP pseudoheader, UDP header, and UDP options), where a value of 0x0000 indicates no checksum." And a warning that "This reassembly checksum SHOULD be used unless a stronger application layer integrity protection is used." (or something close to that). > > Other comments: > > In section 5.4, was a decision made as to what the CRC16 is? Details > will be needed in order to ensure interoperability. That's on my to-do list (I was a bit distracted by these other issues). There are three obvious possibilities: CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) CRC-16-IBM used by USB (4 terms -- 0x8005) CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) There are other analyses that point to other polynomials: https://users.ece.cmu.edu/~koopman/crc/ Any suggestions? > In Section 9, third paragraph, you may want to make the following chang= e: > > OLD: > This feature is also inconsistent with the UDP application interface= > [RFC768] [RFC1122]. > NEW: > This feature is also inconsistent with the UDP application interface= > [RFC1122]. > > in view of the following text in RFC 768: > > IP Interface > ------------- > > The UDP module must be able to determine the source and destinatio= n > internet addresses and the protocol field from the internet header. On= e > possible UDP/IP interface would return the whole internet datagra= m > including all of the internet header in response to a receive operation= =2E > Such an interface would also allow the UDP to pass a full interne= t > datagram complete with header to the IP to send. The IP would verif= y > certain fields for consistency and compute the internet header checksum= =2E I read that section as defining the interface below UDP, not above UDP. I.e., it's the IP API that UDP expects, not the interface UDP expects users to utilize. Can you double-check? Thanks again, Joe From nobody Thu Mar 23 01:34:16 2017 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 AF8DB12946F for ; Thu, 23 Mar 2017 01:34:15 -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, RP_MATCHES_RCVD=-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 i6HLh-GgLOTN for ; Thu, 23 Mar 2017 01:34:13 -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 3993D12955B for ; Thu, 23 Mar 2017 01:34:13 -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 36D1E1B0154A; Thu, 23 Mar 2017 10:31:42 +0000 (GMT) Message-ID: <58D3887D.5060603@erg.abdn.ac.uk> Date: Thu, 23 Mar 2017 08:34:05 +0000 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.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch CC: "C. M. Heard" , Mark Smith , tsvwg References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> In-Reply-To: <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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, 23 Mar 2017 08:34:15 -0000 On 23/03/2017, 05:43, Joe Touch wrote: > Hi, Mike, > > > On 3/22/2017 6:52 PM, C. M. Heard wrote: >> On Fri, Mar 17, 2017 at 6:03 PM, Joe Touch wrote: >>> The queue has closed, but I have a new version of UDP options 06 that >>> will post as soon as it opens (why do we still do this?) >>> >>> Here's a pointer in the meantime: >>> >>> http://www.isi.edu/touch/pubs/draft-touch-tsvwg-udp-options-06.txt >>> >>> It includes Mike's nice observation about combining FRAG and LITE, >>> clarifies some nits about what happens in each order, etc. >>> >>> I tried to keep things simple, so LITE comes first when it's used, FRAG >>> stops processing until reassembly, and things pick up after reassembly >>> with options included after the last fragment. I think that's clean... >> Agreed, I like the way you have done this, with the final fragment being >> indicated by including a checksum. That said, the following text: >> >>>> A host SHOULD indicate FRAG support by transmitting an >> unfragmented datagram using the Fragmentation option (e.g., with >> Offset and M both zero), except when encoded as LITE. >> >> needs to be adjusted owing to elimination of the M bit in favor of a >> whole-datagram checksum. > Thanks for the catch. I'll fix that in -06. > >> Regarding the whole-datagram checksum: it would IMHO be appropriate to >> be very specific as to what it is. I would propose the standard Internet >> checksum without a pseudo-header, with the value 0x0000 indicating the >> absence of a checksum. > It does say "IP checksum over the reassembled payload", which could be > "optional Internet checksum over the reassembled UDP payload (i.e., > excluding the IP pseudoheader, UDP header, and UDP options), where a > value of 0x0000 indicates no checksum." > > And a warning that "This reassembly checksum SHOULD be used unless a > stronger application layer integrity protection is used." (or something > close to that). >> Other comments: >> >> In section 5.4, was a decision made as to what the CRC16 is? Details >> will be needed in order to ensure interoperability. > That's on my to-do list (I was a bit distracted by these other issues). > There are three obvious possibilities: > > CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) > CRC-16-IBM used by USB (4 terms -- 0x8005) > CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) > > There are other analyses that point to other polynomials: > https://users.ece.cmu.edu/~koopman/crc/ > > Any suggestions? I suggest using CRC-16-CCITT, it's common (and fairly strong) and there is lookup-based code published. >> In Section 9, third paragraph, you may want to make the following change: >> >> OLD: >> This feature is also inconsistent with the UDP application interface >> [RFC768] [RFC1122]. >> NEW: >> This feature is also inconsistent with the UDP application interface >> [RFC1122]. >> >> in view of the following text in RFC 768: >> >> IP Interface >> ------------- >> >> The UDP module must be able to determine the source and destination >> internet addresses and the protocol field from the internet header. One >> possible UDP/IP interface would return the whole internet datagram >> including all of the internet header in response to a receive operation. >> Such an interface would also allow the UDP to pass a full internet >> datagram complete with header to the IP to send. The IP would verify >> certain fields for consistency and compute the internet header checksum. > I read that section as defining the interface below UDP, not above UDP. > I.e., it's the IP API that UDP expects, not the interface UDP expects > users to utilize. > > Can you double-check? > > Thanks again, > > Joe > Gorry From nobody Thu Mar 23 17:01:16 2017 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 E51D0128B4E; Thu, 23 Mar 2017 17:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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=bobbriscoe.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 hC7igNsjZSWq; Thu, 23 Mar 2017 17:01:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C414B1288B8; Thu, 23 Mar 2017 17:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4R5bWXdKmR298kj1rF0bOoguGSq7llARF57Q8bCfoAU=; b=gwETugiL4LnlQ4egwLaYbqsALn HdH6UYNB3aRDOdN+jLR43vIbkwonxX0FEw1RU8DK2dKAL4eNrjOgzenY/cE3M8yle+Ch0w3Hzj6r4 BBXpY4VvnqmMtwzzHr3UEwkMH5YKS2E3aN606cHFYAwcFS9xBpcgJ7pRwABqJwF+/dAcrN2bfYB7+ m7v9Y6+Kg3QxNjT6tG1I+V3Qjs/oK6LxbJapOyQxEePAl27J7W5UzxADZsHEt6x+okvVvfoUeIx2E Xy4hUt6xGYb9QUTQuG3XJNKaPfA0Gxq7B8ERL10hyx7a/x6KqzJu8DLxtX8XHAfPuyOvA6MDNeEc1 PX23dqkg==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:35334 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1crCf7-00015A-Ro; Fri, 24 Mar 2017 00:01:02 +0000 From: Bob Briscoe To: "Rong Pan (ropan)" , Greg White , FredBaker.IETF@gmail.com, prenatar@cisco.com Cc: "De Schepper, Koen (Koen)" , AQM IETF list , tsvwg IETF list Message-ID: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> Date: Fri, 24 Mar 2017 00:01:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tsvwg] Questioning each PIE heuristic 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, 24 Mar 2017 00:01:08 -0000 Rong, Preethi, Greg, Fred, and others involved in PIE, You may recall that when we wrote PI2 we didn't include any of PIE's heuristics. Mostly because PI2 solved the issues they addressed intrinsically. But we left some until we had checked their benefit, which is what I'm doing now... My first question is about this heuristic in PIE: //Safeguard PIE to be work conserving if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { return ENQUE; } If it tests true, this block doesn't stop the calculation of drop_prob_ evolving, but it disables it being able to lead to any random packet drop. I can understand why you want to disable packet drop when the queue is no more than 2 packets. My question is about the first half of the logical OR. The drop_prob_ < 20% test will be true under normal non-overloaded conditions. So I have just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off random drop very often. I would expect this to radically impact the behaviour of PIE. It seems to be overriding the PI controller as if you are thinking "actually we don't really trust the PI controller to leave it to do its thing, so we've overridden it a lot of the time." For instance, whenever a single long-running TCP flow with RTT about the same as the target delay is saw-toothing, this test will disable random drop completely during the lower half of every saw-tooth in the queue. Maybe that's OK, but... Without this test, the PI controller should reduce drop probability as the queue sawtooths down anyway. If another flow causes the queue to rise rapidly while it is under half the target, the PI controller is designed to detect such an increase and translate it into drop. But this heuristic suppresses any drop until the queue has exceeded half the target. So my questions are: Q1. What were the reasons for introducing such a frequent suppression of the PI algorithm (the RFC just says what this code does, not why)? Q2. Why use qdelay_old_ in the test? This seems to drive suppression of drop using stale state. Q3. Having said that it looks like this heuristic will significantly alter PIE's behaviour, in tests under a very wide range of traffic conditions, link rates, mixed RTTs, traffic models etc, we have found that removing the heuristics makes no measurable difference to PIE's performance. So if you added this heuristic for a specific scenario, please describe it, so we can test for it. Cheers Bob -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ From nobody Fri Mar 24 02:22:04 2017 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 CD0D11294EE for ; Fri, 24 Mar 2017 02:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 50c_Mfz4y9K7 for ; Fri, 24 Mar 2017 02:21:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 49A3B129567 for ; Fri, 24 Mar 2017 02:21:58 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-62-58d4e535de40 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id AC.92.11640.435E4D85; Fri, 24 Mar 2017 10:21:57 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 24 Mar 2017 10:22:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rc8cHl9UQ+rUT2fMeX6Fy8nKR35NrukH4Da/oIbJtU8=; b=MVce52Go8bDO7eMaW3oFMv99IxwWCylPKywrRFsH+rjLia4S8I5OABJ0GddM+gFT2Pu76imehoyPQG6AMA5GJ3ot7tCmaSbs+mHUQCq3tigO3t+SO81qAzskLbQCkdN8hvuMdficrKNuIhgSMt9MoRfkPT/a+zguJ+0EpSErAUE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 09:21:53 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0991.018; Fri, 24 Mar 2017 09:21:53 +0000 From: Ingemar Johansson S To: "tsvwg@ietf.org" Thread-Topic: L4S in GSMA report Thread-Index: AdKkfrMk4XhbKq5dQD+0m4cA2mix5A== Date: Fri, 24 Mar 2017 09:21:52 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:9v/VJwuhQeUJ71LZhd+CMR+w2NbHvSLmu+NMC5WAqV6pKPa4SFHveAhZ/oZ7M39jSkOeIiUExUw4NHOKqVOHvbl8TzJvLWODFVXwiTRNSJY9XPz1Dhycl0fmU7oPgZStpJ4yZEifDw7YwCqJp0AzURSPgxuQSMOJdbYYvHZNSzu5R71/5e4CBWD/U73bqa+d6AkohWZM9Hu9UTEbcqMyNAeh90rTYKCtk0L7nTepeJQ12nTZarxCfjz4kxRn7xU4pDXKWIZhCbYxN8NH2eDQfyXin0whMMNOinaeugeWQGDL7gK7Hkmhd/H4b76tKjKMXLsVloZmsG6HFvOR5usxMw== x-ms-office365-filtering-correlation-id: eddfc4cb-d87a-4392-bc97-08d472973592 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(160794256991155)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39850400002)(39410400002)(8936002)(236005)(66066001)(50986999)(33656002)(2900100001)(966004)(9326002)(1730700003)(2351001)(54896002)(6306002)(9686003)(53936002)(5630700001)(5640700003)(54356999)(6436002)(55016002)(8676002)(99286003)(122556002)(77096006)(5660300001)(606005)(6506006)(102836003)(7736002)(38730400002)(6116002)(3846002)(7906003)(110136004)(790700001)(81166006)(189998001)(2906002)(25786009)(2501003)(7696004)(74316002)(3280700002)(3660700001)(86362001)(19609705001)(6916009)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348A72C6F5F3ACF317B7247C23E0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 09:21:52.8077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGfXfv3a7DwW0qnqZFzEZQuEotJIZoXxRhCRFNC2zpRUc6164f LQL3R6JpkZqjuUozptCXX6gJadTQZVh+a9o2w9JKk7IMhlba5muw/37vc87znHPgpQlxFSWh 1ZosVqdRpUv5QrJC+eRI2K7pYeWOngZxlG3OyY9BhyyWRV48ShQqUth0dQ6r2x59RphmurWC tJO7L9hmaygDqg8vQr40MJEwXT9NFCEhLWbqEPxd+cbDj24En273Is+DZK4R8Lm3QIArRh7M jg+seWwIGgZmeJ4wPqOA+1YX8nAAI4Ohwseruj8TDPZ5uwDrm6CtZI7ELIdWyw93P+0eIYP+ h8EeWcQkgnmia7UdMRvgvWtitZ1gguDdVBUP782Apb2PwBwIMx+XKc8+iClGMF85yvNkgnvW ZMtRjw5MMQED1w0UNsSBo7MLYT4FVY78tSA1GEdvktibDqWPsrHXxIOr9oU1bwj0dA9SuNBD wejIEh8fKQHn8BWEOQS+ODoovHUmNLYa+PiydfCqYorEQfHQ5BoTlCCZ2es4s5fF7GXBuhzG jOV8zNugtvorgTkMTMtW0lu/iwQPUCDHcmczUsMj5KxOncxxmRq5hs1qQu5v86L5t6wNDc3F WhFDI6mfSFs6qBRTqhxOn2FFQBPSAFFcsVsSpaj0F1ldZpIuO53lrCiYJqVBothn/Uoxk6rK Ys+xrJbV/a/yaF+JASXonQpjXvvTagVtDD1snyq9N/k2f4HMDa20lUefKOz1sb2k9q6vEzlP J5ku+Z+f5DqWY07uqcnVHLiRPHLs9b7Oy8cl1tmDG9VLEb/C8oq+j29p0qvkfxyBfj4rts1D d543aiObRYsfEnx+lk2g2paosoLSuMg3rj42pWt/7dCMlOTSVDu3EjpO9Q/tCFQUMgMAAA== Archived-At: Subject: [tsvwg] L4S in GSMA report 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, 24 Mar 2017 09:22:02 -0000 --_000_DB4PR07MB348A72C6F5F3ACF317B7247C23E0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi L4S gets a few seconds of fame in this report http://www.gsma.com/newsroom/wp-content/uploads//WWG.16-v1.0.pdf /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348A72C6F5F3ACF317B7247C23E0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

L4S gets a few seconds of fam= e in this report

http://www.gsma.com/newsroom= /wp-content/uploads//WWG.16-v1.0.pdf

 

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348A72C6F5F3ACF317B7247C23E0DB4PR07MB348eurprd_-- From nobody Sat Mar 25 06:26:43 2017 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 31A40129452 for ; Sat, 25 Mar 2017 06:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 3A8tz9ly5sq8 for ; Sat, 25 Mar 2017 06:26:39 -0700 (PDT) Received: from sasl.smtp.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 D490D12944E for ; Sat, 25 Mar 2017 06:26:38 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A73F9805C7 for ; Sat, 25 Mar 2017 09:26:37 -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=t+6rAwFvPB+hx6FB5FX1IimNMRE=; b=mw5dMf 5qus9Sg/qKRJBLCikBTaWYtO/T+dRzR36dr8czIr1uaSK994zuc4wdifZ/cqqM9m RhluecQeLQhfEoCsDyo3ar50mjhilMCRrCvU8gparZ++d//KT/sVxrYVufGkCee5 vbvpotV0RWe44mQonceQTz+2vmIlcMkL71f+4= 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=aPwaeymwxbEJbsfuLRNsx7QDFGBoqbjk ilBVtJrPSjNc5UtPWj4BCYTXNOgLrDUIcLQPrP69PaE3BEVO0MLpoPnYgWUI2HT7 iesRncOrgI1046zzb8J42HaNnLWd7JmX8XM1s4hMA6o6e+pV6UEetsrJoO5j263v OUf05XFN3m4= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 9FC28805C6 for ; Sat, 25 Mar 2017 09:26:37 -0400 (EDT) Received: from mail-qk0-f175.google.com (unknown [209.85.220.175]) (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 36D07805C4 for ; Sat, 25 Mar 2017 09:26:37 -0400 (EDT) Received: by mail-qk0-f175.google.com with SMTP id d10so4300784qke.1 for ; Sat, 25 Mar 2017 06:26:37 -0700 (PDT) X-Gm-Message-State: AFeK/H2zjFOTc+FGDAjrz9Nawb0EoF/LoI0OP2HxK/dgQeC294EkNHwJKhwUDcOpDARQAlJ2ZuuTTjxbLZyaMA== X-Received: by 10.55.119.65 with SMTP id s62mr11819311qkc.130.1490448396759; Sat, 25 Mar 2017 06:26:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Sat, 25 Mar 2017 06:26:16 -0700 (PDT) In-Reply-To: <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> From: "C. M. Heard" Date: Sat, 25 Mar 2017 06:26:16 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: Mark Smith , tsvwg Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: AC3CF424-115E-11E7-8FD7-FC50AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Sat, 25 Mar 2017 13:26:41 -0000 On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch wrote: > > In section 5.4, was a decision made as to what the CRC16 is? Details > > will be needed in order to ensure interoperability. > > That's on my to-do list (I was a bit distracted by these other issues). > There are three obvious possibilities: > > CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) > CRC-16-IBM used by USB (4 terms -- 0x8005) > CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) > > There are other analyses that point to other polynomials: > https://users.ece.cmu.edu/~koopman/crc/ > > Any suggestions? Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation) and are in a sense optimal for random error patterns. They detect all triple errors (and all error patterns of odd weight) for data lengths of 4093 bytes or less. The CRC-16-CDMA2000 has a single factor, which is a primitive degree 16 polynomial (*p in Koopman's notation), and it will detect all double errors for data lengths of 8189 bytes or less. By data length I mean of course the length of the data protected by the CRC (not including the CRC itself). There are generic fast table lookup algorithms for all CRC-16 polynomials, including automated methods for generating the lookup tables, so that is not really a factor in choosing a polynomial. > > In Section 9, third paragraph, you may want to make the following change: > > > > OLD: > > This feature is also inconsistent with the UDP application interface > > [RFC768] [RFC1122]. > > NEW: > > This feature is also inconsistent with the UDP application interface > > [RFC1122]. > > > > in view of the following text in RFC 768: > > > > IP Interface > > ------------- > > > > The UDP module must be able to determine the source and destination > > internet addresses and the protocol field from the internet header. One > > possible UDP/IP interface would return the whole internet datagram > > including all of the internet header in response to a receive operation. > > Such an interface would also allow the UDP to pass a full internet > > datagram complete with header to the IP to send. The IP would verify > > certain fields for consistency and compute the internet header checksum. > > I read that section as defining the interface below UDP, not above UDP. > I.e., it's the IP API that UDP expects, not the interface UDP expects > users to utilize. > > Can you double-check? You are of course correct on this point, and I withdraw the comment. Mike Heard From nobody Sat Mar 25 15:07:40 2017 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 D729E1292F5 for ; Sat, 25 Mar 2017 15:07:38 -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, RP_MATCHES_RCVD=-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 d91TUdjXCS9k for ; Sat, 25 Mar 2017 15:07:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 725EB1293F5 for ; Sat, 25 Mar 2017 15:07:37 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2PM6xdT004308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 25 Mar 2017 15:07:01 -0700 (PDT) To: "C. M. Heard" References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> Cc: Mark Smith , tsvwg From: Joe Touch Message-ID: Date: Sat, 25 Mar 2017 15:06:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Sat, 25 Mar 2017 22:07:39 -0000 I that case should we go with CRC-16-CDMA2000? Or is there a better/stronger one from the table that's more useful? Joe On 3/25/2017 6:26 AM, C. M. Heard wrote: > On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch wrote: >>> In section 5.4, was a decision made as to what the CRC16 is? Details >>> will be needed in order to ensure interoperability. >> That's on my to-do list (I was a bit distracted by these other issues). >> There are three obvious possibilities: >> >> CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) >> CRC-16-IBM used by USB (4 terms -- 0x8005) >> CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) >> >> There are other analyses that point to other polynomials: >> https://users.ece.cmu.edu/~koopman/crc/ >> >> Any suggestions? > Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product > of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation) > and are in a sense optimal for random error patterns. They detect all triple > errors (and all error patterns of odd weight) for data lengths of 4093 bytes > or less. The CRC-16-CDMA2000 has a single factor, which is a primitive > degree 16 polynomial (*p in Koopman's notation), and it will detect all > double errors for data lengths of 8189 bytes or less. By data length I > mean of course the length of the data protected by the CRC (not > including the CRC itself). > > There are generic fast table lookup algorithms for all CRC-16 polynomials, > including automated methods for generating the lookup tables, so that is > not really a factor in choosing a polynomial. > >>> In Section 9, third paragraph, you may want to make the following change: >>> >>> OLD: >>> This feature is also inconsistent with the UDP application interface >>> [RFC768] [RFC1122]. >>> NEW: >>> This feature is also inconsistent with the UDP application interface >>> [RFC1122]. >>> >>> in view of the following text in RFC 768: >>> >>> IP Interface >>> ------------- >>> >>> The UDP module must be able to determine the source and destination >>> internet addresses and the protocol field from the internet header. One >>> possible UDP/IP interface would return the whole internet datagram >>> including all of the internet header in response to a receive operation. >>> Such an interface would also allow the UDP to pass a full internet >>> datagram complete with header to the IP to send. The IP would verify >>> certain fields for consistency and compute the internet header checksum. >> I read that section as defining the interface below UDP, not above UDP. >> I.e., it's the IP API that UDP expects, not the interface UDP expects >> users to utilize. >> >> Can you double-check? > You are of course correct on this point, and I withdraw the comment. > > Mike Heard From nobody Sat Mar 25 19:37:32 2017 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 2A4831294BF for ; Sat, 25 Mar 2017 19:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, 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 smHRgZqDtVMu for ; Sat, 25 Mar 2017 19:37:29 -0700 (PDT) Received: from sasl.smtp.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 4954D1294BB for ; Sat, 25 Mar 2017 19:37:29 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B9DBC86268 for ; Sat, 25 Mar 2017 22:37:25 -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=7MtweHp9/ujVr5dqpVdC0LZ8F54=; b=NTOsXp tSK1AhzPic0FTAg0vPjYIOZ+qBo8T358I1bC36DKWBISXXuCeTL2hUUwwpWss1Jz 7nZrZ84/BZxQe5E0fSgQ1mHwHs6OqYDsaebJDwYd7hAXH2zz+F4RW4l1+Af/gLjt WOoIzvpq82SgRpqnE5TfqkWECA/lu2xHXNo7o= 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=EzrU8op1Rew2Ev7Gt2q2U/hfJGkrYpxm iCYXRgJesNSSmEjV5KwYO+hzAtb+NF7gvUTA028IqlkvTwQLIvCrfKjDLaQeosTy qzmYazMJsRdegi8zE5XV6ux+1dmzw2tGpZ9tUtXt/SrHmPWuDvOPzeE6AY6dUa5r zmgFgv2qchY= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B226186267 for ; Sat, 25 Mar 2017 22:37:25 -0400 (EDT) Received: from mail-qk0-f175.google.com (unknown [209.85.220.175]) (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 4B29386266 for ; Sat, 25 Mar 2017 22:37:25 -0400 (EDT) Received: by mail-qk0-f175.google.com with SMTP id p22so16694966qka.3 for ; Sat, 25 Mar 2017 19:37:25 -0700 (PDT) X-Gm-Message-State: AFeK/H3g/9l+s65NtB1ik5TmYiOiwFK+mRMtEB+lN8FBgN4nl7TfxGgHhywAlUQqPQXsU5fMODQT2eApBBzhJA== X-Received: by 10.55.68.66 with SMTP id r63mr13990028qka.116.1490495844842; Sat, 25 Mar 2017 19:37:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Sat, 25 Mar 2017 19:37:04 -0700 (PDT) In-Reply-To: References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> From: "C. M. Heard" Date: Sat, 25 Mar 2017 19:37:04 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: Mark Smith , tsvwg Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 257FB5BA-11CD-11E7-8C7B-97B1B46B9B0B-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Sun, 26 Mar 2017 02:37:31 -0000 On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch wrote: > On 3/25/2017 6:26 AM, C. M. Heard wrote: > > On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch wrote: > >>> In section 5.4, was a decision made as to what the CRC16 is? Details > >>> will be needed in order to ensure interoperability. > >> That's on my to-do list (I was a bit distracted by these other issues). > >> There are three obvious possibilities: > >> > >> CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) > >> CRC-16-IBM used by USB (4 terms -- 0x8005) > >> CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) > >> > >> There are other analyses that point to other polynomials: > >> https://users.ece.cmu.edu/~koopman/crc/ > >> > >> Any suggestions? > > Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product > > of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation) > > and are in a sense optimal for random error patterns. They detect all triple > > errors (and all error patterns of odd weight) for data lengths of 4093 bytes > > or less. The CRC-16-CDMA2000 has a single factor, which is a primitive > > degree 16 polynomial (*p in Koopman's notation), and it will detect all > > double errors for data lengths of 8189 bytes or less. By data length I > > mean of course the length of the data protected by the CRC (not > > including the CRC itself). > > > > There are generic fast table lookup algorithms for all CRC-16 polynomials, > > including automated methods for generating the lookup tables, so that is > > not really a factor in choosing a polynomial. > > I that case should we go with CRC-16-CDMA2000? > > Or is there a better/stronger one from the table that's more useful? Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent) are ***stronger** than CRC-16-CDMA2000 for datagram payloads up to 32751 bits (i.e., CRC + data length = 32767 bits), when errors are random. For datagrams of that exact length It can be proven (again for random errors) that the undetected error rate is no worse than 1/65536, and for lesser lengths simulations bear this out (see, for example, http://doc.utwente.nl/64267/1/schiphorst.pdf). The only reason I can see to choose CRC-16-CDMA2000 would be to provide protection for datagrams longer than 4K bytes, in which case a better choice would be a 32-bit CRC. The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1 Although it is a primitive polynomial (without a factor of x+1) it will protect against all triple error patters for datagram lengths of 11450 bytes, according to simulations that I ran about 14 years ago, and its undetected error rate (for random errors) can be expected to be under 2^-32. So that's what I would be inclined to recommend. Regards, Mike Heard From nobody Mon Mar 27 05:39:57 2017 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 B0FD412953C; Mon, 27 Mar 2017 05:39:54 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149061839467.30631.3920618169304811475@ietfa.amsl.com> Date: Mon, 27 Mar 2017 05:39:54 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-encap-guidelines-08.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, 27 Mar 2017 12:39:55 -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 of the IETF. Title : Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP Authors : Bob Briscoe John Kaippallimalil Pat Thaler Filename : draft-ietf-tsvwg-ecn-encap-guidelines-08.txt Pages : 34 Date : 2017-03-27 Abstract: The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-08 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-encap-guidelines-08 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 Mar 27 05:46:01 2017 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 D4796129534; Mon, 27 Mar 2017 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=bobbriscoe.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 pqSYJnQlZr4C; Mon, 27 Mar 2017 05:45:56 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 AEC07124D37; Mon, 27 Mar 2017 05:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject: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=/lQqXozDvACd71jGDVq+U9d9Zr2MWegL5QbAW4/zGEY=; b=qvfOwj5SQ9e16//r10fd0WTelt ZQZt2EnQYnM1Yab45eaOUnzAlsZxs+Yxm7sVk5Fv3v1B/5Llmd2StJ5r0eKBXPFJxWt2EghReZ88b 8txCvCnYy3Av/oPa21vJQnyVTtwCvNJ9RLh9sAWOhSxyJk2PXCmbp6+p/EIEDgakzROTPsXM1JqMh v0wjWtJ/ELj0ts9IvNTITqiMyY5qJxNcz9yVrJJmglcRpG/un62SSrEGG78OZ7C//Jv1cggnPR4OR nu5wG8S2jBdMwbBny+1svJcc1vhrWLmPvB+TaVeYYN5BzL791VEYTKrkzQ338zgQwZXvK/3NRb6aO 3aT5y+2A==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:55756 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1csU1x-0003CN-J0; Mon, 27 Mar 2017 13:45:53 +0100 To: "Black, David" References: <649e7cf1-f487-1215-a6fc-c25124824418@bobbriscoe.net> Cc: "draft-ietf-tsvwg-ecn-encap-guidelines@ietf.org" , "draft-ietf-tsvwg-rfc6040update-shim@ietf.org" , "tsvwg-chairs@ietf.org" , tsvwg IETF list From: Bob Briscoe Message-ID: <56ea7bdb-faf5-56db-2d4c-afc6832f1ca1@bobbriscoe.net> Date: Mon, 27 Mar 2017 13:45:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] TSVWG: Proposed plan for ecn-encap-guidelines and rfc6040update-shim drafts 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, 27 Mar 2017 12:45:59 -0000 David, As promised, we've rev'd it to draft-ietf-tsvwg-ecn-encap-guidelines-08 now that the servers are open. As already explained, since summarizing the outcome of the 3GPP liaison, the draft has been finished and ready. So no major changes, just reference updates. As you want to take this through in tandem with draft-ietf-tsvwg-rfc6040update-shim, we will just leave it sitting until the shim draft is done. Bob, John & Pat -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Mar 27 06:22:46 2017 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 5CA3112953F for ; Mon, 27 Mar 2017 06:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=bobbriscoe.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 jydiYQiJ40_Q for ; Mon, 27 Mar 2017 06:22:42 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 3B99E127333 for ; Mon, 27 Mar 2017 06:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:To:Cc:References:Subject: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=S1nXKBaYajGfv8ncMxGjwsRF+zkdPwWpFc/lzCKTZnU=; b=la/OK830rr4j7Eobv/ErKjLtGa AXHvHG60V944vkqVhObODkiQPPjWRFGiqRwEwtNeHY2cIRdW8HDvvxhO5CkuG7TLSbCuI4ENxJFLh afPJAzG9QzLDdIkGfIOqiFc8zMjNIkUWrWsWyDyqK4Gs93g3wCj/XXdHIGLMDCYZ3ZX0hq3XJphYC Oq4ul3UPSKE3qSKkBtZeH8E5i9Is0CPrQ6d3toApvepynNochQOuvg1U6/P5/OY3Ra3HebZUZ3afn uLeA9gewLuuhIPUaHk/LL9NhoIu+H75o3e1GYUemxQRwLby3SXhKeJVyTemEJqW72A5zCF4KLNxKJ 6TJhhkkw==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:55832 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1csUbY-0007FA-M1; Mon, 27 Mar 2017 14:22:40 +0100 References: <261f2bc5-8083-316d-f205-411548c7886f@mti-systems.com> <0a836ed7-7e56-5317-711b-2586af26bd6a@bobbriscoe.net> <070d08c0-51d2-4fe2-0522-4772adf7cb1e@mti-systems.com> <218817b8-53c0-7d6f-54b3-ef6d4df84fb7@bobbriscoe.net> <91ebe46d-3206-eeab-01fe-66c6d7cf1b7d@mti-systems.com> <9dc5409e-e7b3-def4-94fe-4d4a13a61326@bobbriscoe.net> <3773e2b6-fea3-70dd-63c1-910a993690f3@mti-systems.com> Cc: Wesley Eddy , "De Schepper, Koen (Nokia - BE/Antwerp)" , marcelo bagnulo braun , tsvwg IETF list To: Ingemar Johansson S From: Bob Briscoe Message-ID: <83f5810e-9c54-859e-11b1-51079a50e8b7@bobbriscoe.net> Date: Mon, 27 Mar 2017 14:22:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3773e2b6-fea3-70dd-63c1-910a993690f3@mti-systems.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tsvwg] Milestones for L4S work in TSVWG 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, 27 Mar 2017 13:22:44 -0000 Ingemar, Wes has been asking what are sensible milestones for the L4S work in TSVWG. It occurred to me that there might be a particularly important deadline in the 3GPP's release schedule for introducing new queue management technology into eNodeB's. Can you (or any other 3GPP-savvy person on this list) point us at where this schedule is, if it's public? And if necessary interpret the significance of any stages. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Mar 27 08:38:52 2017 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 1391812955F for ; Mon, 27 Mar 2017 08:38:51 -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, RP_MATCHES_RCVD=-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 F_Rn6fg4NZI2 for ; Mon, 27 Mar 2017 08:38:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 CF599129465 for ; Mon, 27 Mar 2017 08:38:48 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2RFbYXN020738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Mar 2017 08:37:36 -0700 (PDT) To: "C. M. Heard" References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> Cc: Mark Smith , tsvwg From: Joe Touch Message-ID: <8e7bc6cc-d61f-89d4-c6b1-a5e6135fc0b3@isi.edu> Date: Mon, 27 Mar 2017 08:37:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Mon, 27 Mar 2017 15:38:51 -0000 So do we want to recommend a 16-bit value or jump to the 32-bit one? IMO, for UDP, anything reasonably stronger than the Internet checksum should be fine. I was hoping for a 16-bit selection to leave the result 32-bit aligned... Joe On 3/25/2017 7:37 PM, C. M. Heard wrote: > On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch wrote: >> On 3/25/2017 6:26 AM, C. M. Heard wrote: >>> On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch wrote: >>>>> In section 5.4, was a decision made as to what the CRC16 is? Details >>>>> will be needed in order to ensure interoperability. >>>> That's on my to-do list (I was a bit distracted by these other issues). >>>> There are three obvious possibilities: >>>> >>>> CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) >>>> CRC-16-IBM used by USB (4 terms -- 0x8005) >>>> CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) >>>> >>>> There are other analyses that point to other polynomials: >>>> https://users.ece.cmu.edu/~koopman/crc/ >>>> >>>> Any suggestions? >>> Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product >>> of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation) >>> and are in a sense optimal for random error patterns. They detect all triple >>> errors (and all error patterns of odd weight) for data lengths of 4093 bytes >>> or less. The CRC-16-CDMA2000 has a single factor, which is a primitive >>> degree 16 polynomial (*p in Koopman's notation), and it will detect all >>> double errors for data lengths of 8189 bytes or less. By data length I >>> mean of course the length of the data protected by the CRC (not >>> including the CRC itself). >>> >>> There are generic fast table lookup algorithms for all CRC-16 polynomials, >>> including automated methods for generating the lookup tables, so that is >>> not really a factor in choosing a polynomial. >> I that case should we go with CRC-16-CDMA2000? >> >> Or is there a better/stronger one from the table that's more useful? > Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent) > are ***stronger** than CRC-16-CDMA2000 for datagram payloads up to 32751 > bits (i.e., CRC + data length = 32767 bits), when errors are random. For > datagrams of that exact length It can be proven (again for random errors) > that the undetected error rate is no worse than 1/65536, and for lesser > lengths simulations bear this out (see, for example, > http://doc.utwente.nl/64267/1/schiphorst.pdf). The only reason I can see > to choose CRC-16-CDMA2000 would be to provide protection for datagrams > longer than 4K bytes, in which case a better choice would be a 32-bit CRC. > The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is > > x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1 > > Although it is a primitive polynomial (without a factor of x+1) it will > protect against all triple error patters for datagram lengths of 11450 > bytes, according to simulations that I ran about 14 years ago, and > its undetected error rate (for random errors) can be expected to be > under 2^-32. So that's what I would be inclined to recommend. > > Regards, > > Mike Heard From nobody Mon Mar 27 09:02:51 2017 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 CD16F12945D for ; Mon, 27 Mar 2017 09:02:50 -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, RP_MATCHES_RCVD=-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 hSSgEj4ofNcn for ; Mon, 27 Mar 2017 09:02:47 -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 6D74C129482 for ; Mon, 27 Mar 2017 09:02:45 -0700 (PDT) Received: from dhcp-84da.meeting.ietf.org (t2001067c037001287c16711262d0b5f7.v6.meeting.ietf.org [IPv6:2001:67c:370:128:7c16:7112:62d0:b5f7]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E73211B017FA; Mon, 27 Mar 2017 18:59:54 +0100 (BST) Message-ID: <58D9378A.7010504@erg.abdn.ac.uk> Date: Mon, 27 Mar 2017 11:02:18 -0500 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.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch CC: "C. M. Heard" , Mark Smith , tsvwg References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> <8e7bc6cc-d61f-89d4-c6b1-a5e6135fc0b3@isi.edu> In-Reply-To: <8e7bc6cc-d61f-89d4-c6b1-a5e6135fc0b3@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Mon, 27 Mar 2017 16:02:51 -0000 I'd think CRC-16 is likely to be a good proposal. 32b alignment is always good. Gorry On 27/03/2017, 10:37, Joe Touch wrote: > So do we want to recommend a 16-bit value or jump to the 32-bit one? > > IMO, for UDP, anything reasonably stronger than the Internet checksum > should be fine. I was hoping for a 16-bit selection to leave the result > 32-bit aligned... > > Joe > > > On 3/25/2017 7:37 PM, C. M. Heard wrote: >> On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch wrote: >>> On 3/25/2017 6:26 AM, C. M. Heard wrote: >>>> On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch wrote: >>>>>> In section 5.4, was a decision made as to what the CRC16 is? Details >>>>>> will be needed in order to ensure interoperability. >>>>> That's on my to-do list (I was a bit distracted by these other issues). >>>>> There are three obvious possibilities: >>>>> >>>>> CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - 0x1021) >>>>> CRC-16-IBM used by USB (4 terms -- 0x8005) >>>>> CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) >>>>> >>>>> There are other analyses that point to other polynomials: >>>>> https://users.ece.cmu.edu/~koopman/crc/ >>>>> >>>>> Any suggestions? >>>> Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product >>>> of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation) >>>> and are in a sense optimal for random error patterns. They detect all triple >>>> errors (and all error patterns of odd weight) for data lengths of 4093 bytes >>>> or less. The CRC-16-CDMA2000 has a single factor, which is a primitive >>>> degree 16 polynomial (*p in Koopman's notation), and it will detect all >>>> double errors for data lengths of 8189 bytes or less. By data length I >>>> mean of course the length of the data protected by the CRC (not >>>> including the CRC itself). >>>> >>>> There are generic fast table lookup algorithms for all CRC-16 polynomials, >>>> including automated methods for generating the lookup tables, so that is >>>> not really a factor in choosing a polynomial. >>> I that case should we go with CRC-16-CDMA2000? >>> >>> Or is there a better/stronger one from the table that's more useful? >> Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent) >> are ***stronger** than CRC-16-CDMA2000 for datagram payloads up to 32751 >> bits (i.e., CRC + data length = 32767 bits), when errors are random. For >> datagrams of that exact length It can be proven (again for random errors) >> that the undetected error rate is no worse than 1/65536, and for lesser >> lengths simulations bear this out (see, for example, >> http://doc.utwente.nl/64267/1/schiphorst.pdf). The only reason I can see >> to choose CRC-16-CDMA2000 would be to provide protection for datagrams >> longer than 4K bytes, in which case a better choice would be a 32-bit CRC. >> The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is >> >> x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1 >> >> Although it is a primitive polynomial (without a factor of x+1) it will >> protect against all triple error patters for datagram lengths of 11450 >> bytes, according to simulations that I ran about 14 years ago, and >> its undetected error rate (for random errors) can be expected to be >> under 2^-32. So that's what I would be inclined to recommend. >> >> Regards, >> >> Mike Heard From nobody Mon Mar 27 10:42:00 2017 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 B1197128BBB for ; Mon, 27 Mar 2017 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 Gf5ZlRCckAVk for ; Mon, 27 Mar 2017 10:41:57 -0700 (PDT) Received: from sasl.smtp.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 98EE3124BFA for ; Mon, 27 Mar 2017 10:41:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A7D1C7F907 for ; Mon, 27 Mar 2017 13:41:56 -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=UPLnzC7GsotvKRqnyk/zPtMNY8Y=; b=viwPbM /Dt2qHT5wN0GJRoIKD05oOppaXhjEiy+lZ/JklMyfHdyQ0zYdLmvN+iN8eemfLLj hpE5VLcy+AIw4oYXa6ezIY2pK0cLqVGvGncC+C3EXtpCPd4WV6jI/GjajnI2dBJ6 IvQH17/byvWHR7imUUp4FTG+x0O7o8DmIrA9k= 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=yHZ66m6z1o11IktR/Dej6eHUnW6N2y7t VoMnZVqzD5AT0c94tAl23Y02e/Rxtl5AqfFQac3bYeg92+q9mkfvvbjGuSnIJzyn Z5KBWlutquRUSipWLRWSlKZji9Kd3OGs7Boq6PqfFXJ1VVFFzOfpIIGqsgWjePwc ENzEP1b0qeU= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A13677F905 for ; Mon, 27 Mar 2017 13:41:55 -0400 (EDT) Received: from mail-qt0-f169.google.com (unknown [209.85.216.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 294E87F901 for ; Mon, 27 Mar 2017 13:41:55 -0400 (EDT) Received: by mail-qt0-f169.google.com with SMTP id r45so43985718qte.3 for ; Mon, 27 Mar 2017 10:41:55 -0700 (PDT) X-Gm-Message-State: AFeK/H0sy/82pkB24ROJgY151vvgx8wIN6FbF/PAh1fUmy2Cs7sImpwvFH7bMg/6DcaUpDjFVm6mh7acoPcorA== X-Received: by 10.200.54.161 with SMTP id a30mr20857060qtc.167.1490636514559; Mon, 27 Mar 2017 10:41:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Mon, 27 Mar 2017 10:41:34 -0700 (PDT) In-Reply-To: <58D9378A.7010504@erg.abdn.ac.uk> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> <8e7bc6cc-d61f-89d4-c6b1-a5e6135fc0b3@isi.edu> <58D9378A.7010504@erg.abdn.ac.uk> From: "C. M. Heard" Date: Mon, 27 Mar 2017 10:41:34 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Gorry Fairhurst Cc: Joe Touch , "C. M. Heard" , Mark Smith , tsvwg Content-Type: multipart/alternative; boundary=001a114925daf08f18054bb9dbce X-Pobox-Relay-ID: AB459C9E-1314-11E7-839D-FC50AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Mon, 27 Mar 2017 17:41:59 -0000 --001a114925daf08f18054bb9dbce Content-Type: text/plain; charset=UTF-8 I have no objections to that. As for the selection of the specific polynomial: - If you think protection of long payloads ~8K bytes is of overriding importance, choose CRC-16-CDMA2000 - If you think protection of shorter payloads (less than 4K bytes) is more important, choose CRC-16-CCITT or CRC-16-IBM My sense is that CRC-16-CCITT is more widely used than CRC-16-IBM and may be preferable for that reason. Mike Heard On Mon, Mar 27, 2017 at 9:02 AM, Gorry Fairhurst wrote: > I'd think CRC-16 is likely to be a good proposal. 32b alignment is always > good. > > Gorry > > > On 27/03/2017, 10:37, Joe Touch wrote: > >> So do we want to recommend a 16-bit value or jump to the 32-bit one? >> >> IMO, for UDP, anything reasonably stronger than the Internet checksum >> should be fine. I was hoping for a 16-bit selection to leave the result >> 32-bit aligned... >> >> Joe >> >> >> On 3/25/2017 7:37 PM, C. M. Heard wrote: >> >>> On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch wrote: >>> >>>> On 3/25/2017 6:26 AM, C. M. Heard wrote: >>>> >>>>> On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch wrote: >>>>> >>>>>> In section 5.4, was a decision made as to what the CRC16 is? Details >>>>>>> will be needed in order to ensure interoperability. >>>>>>> >>>>>> That's on my to-do list (I was a bit distracted by these other >>>>>> issues). >>>>>> There are three obvious possibilities: >>>>>> >>>>>> CRC-16-CCITT used by Bluetooth, X.25, HDLC (4 terms - >>>>>> 0x1021) >>>>>> CRC-16-IBM used by USB (4 terms -- 0x8005) >>>>>> CRC-16-CDMA2000 used by CDMA mobile nets (8 terms - 0xC867) >>>>>> >>>>>> There are other analyses that point to other polynomials: >>>>>> https://users.ece.cmu.edu/~koopman/crc/ >>>>>> >>>>>> Any suggestions? >>>>>> >>>>> Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the >>>>> product >>>>> of x+1 times a primitive polynomial of degree 15 (*op in Koopman's >>>>> notation) >>>>> and are in a sense optimal for random error patterns. They detect all >>>>> triple >>>>> errors (and all error patterns of odd weight) for data lengths of 4093 >>>>> bytes >>>>> or less. The CRC-16-CDMA2000 has a single factor, which is a primitive >>>>> degree 16 polynomial (*p in Koopman's notation), and it will detect all >>>>> double errors for data lengths of 8189 bytes or less. By data length I >>>>> mean of course the length of the data protected by the CRC (not >>>>> including the CRC itself). >>>>> >>>>> There are generic fast table lookup algorithms for all CRC-16 >>>>> polynomials, >>>>> including automated methods for generating the lookup tables, so that >>>>> is >>>>> not really a factor in choosing a polynomial. >>>>> >>>> I that case should we go with CRC-16-CDMA2000? >>>> >>>> Or is there a better/stronger one from the table that's more useful? >>>> >>> Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent) >>> are ***stronger** than CRC-16-CDMA2000 for datagram payloads up to 32751 >>> bits (i.e., CRC + data length = 32767 bits), when errors are random. For >>> datagrams of that exact length It can be proven (again for random errors) >>> that the undetected error rate is no worse than 1/65536, and for lesser >>> lengths simulations bear this out (see, for example, >>> http://doc.utwente.nl/64267/1/schiphorst.pdf). The only reason I can see >>> to choose CRC-16-CDMA2000 would be to provide protection for datagrams >>> longer than 4K bytes, in which case a better choice would be a 32-bit >>> CRC. >>> The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is >>> >>> x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1 >>> >>> Although it is a primitive polynomial (without a factor of x+1) it will >>> protect against all triple error patters for datagram lengths of 11450 >>> bytes, according to simulations that I ran about 14 years ago, and >>> its undetected error rate (for random errors) can be expected to be >>> under 2^-32. So that's what I would be inclined to recommend. >>> >>> Regards, >>> >>> Mike Heard >>> >> > --001a114925daf08f18054bb9dbce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have no objections to that. As for the selection of= the specific polynomial:
  • If you think protection of long payl= oads ~8K bytes is of overriding importance, choose CRC-16-CDMA2000
  • = If you think protection of shorter payloads (less than 4K bytes) is more im= portant,=C2=A0choose CRC-16-CCITT=C2=A0or CRC-16-IBM
My sense is that CRC-16-CCITT=C2=A0is more widely used tha= n=C2=A0CRC-16-IBM and may be preferable for that reason.

Mike Heard

On Mon, Mar 27, 201= 7 at 9:02 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrot= e:
I'd think CRC-16 is likely to be a good proposal= . 32b alignment is always good.

Gorry


On 27/03/2017, 10:37, Joe Touch wrote:
So do we want to recommend a 16-bit value or jump to the 32-bit one?

IMO, for UDP, anything reasonably stronger than the Internet checksum
should be fine. I was hoping for a 16-bit selection to leave the result
32-bit aligned...

Joe


On 3/25/2017 7:37 PM, C. M. Heard wrote:
On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch<touch@isi.edu>=C2=A0 wrote:
On 3/25/2017 6:26 AM, C. M. Heard wrote:
On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch<touch@isi.edu>=C2=A0 wrote:
In section 5.4, was a decision made as to what the CRC16 is? Details
will be needed in order to ensure interoperability.
That's on my to-do list (I was a bit distracted by these other issues).=
There are three obvious possibilities:

CRC-16-CCITT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used by Bluetooth, X.= 25, HDLC (4 terms - 0x1021)
CRC-16-IBM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used by US= B (4 terms -- 0x8005)
CRC-16-CDMA2000=C2=A0 =C2=A0 used by CDMA=C2=A0 mobile nets (8 terms - 0xC8= 67)

There are other analyses that point to other polynomials:
https://users.ece.cmu.edu/~koopman/crc/

Any suggestions?
Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product of x+1 times a primitive polynomial of degree 15 (*op in Koopman's nota= tion)
and are in a sense optimal for random error patterns. They detect all tripl= e
errors (and all error patterns of odd weight) for data lengths of 4093 byte= s
or less. The CRC-16-CDMA2000 has a single factor, which is a primitive
degree 16 polynomial (*p in Koopman's notation), and it will detect all=
double errors for data lengths of 8189 bytes or less. By data length I
mean of course the length of the data protected by the CRC (not
including the CRC itself).

There are generic fast table lookup algorithms for all CRC-16 polynomials,<= br> including automated methods for generating the lookup tables, so that is not really a factor in choosing a polynomial.
I that case should we go with CRC-16-CDMA2000?

Or is there a better/stronger one from the table that's more useful?
Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent) are ***stronger** than CRC-16-CDMA2000=C2=A0 for datagram payloads up to 32= 751
bits (i.e., CRC + data length =3D 32767 bits), when errors are random. For<= br> datagrams of that exact length It can be proven (again for random errors) that the undetected error rate is no worse than 1/65536, and for lesser
lengths simulations bear this out (see, for example,
http://doc.utwente.nl/64267/1/schiphorst.pdf). = The only reason I can see
to choose CRC-16-CDMA2000 would be to provide protection for datagrams
longer than 4K bytes, in which case a better choice would be a 32-bit CRC.<= br> The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is

x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1=

Although it is a primitive polynomial (without a factor of x+1) it will
protect against all triple error patters for datagram lengths of 11450
bytes, according to simulations that I ran about 14 years ago, and
its undetected error rate (for random errors) can be expected to be
under 2^-32. So that's what I would be inclined to recommend.

Regards,

Mike Heard


--001a114925daf08f18054bb9dbce-- From nobody Mon Mar 27 10:54:08 2017 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 7AC811294F8 for ; Mon, 27 Mar 2017 10:54:07 -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, RP_MATCHES_RCVD=-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 eCtkhHUOyNeU for ; Mon, 27 Mar 2017 10:54:05 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 ECF3E1292CE for ; Mon, 27 Mar 2017 10:54:03 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2RHr3NH014446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Mar 2017 10:53:04 -0700 (PDT) To: "C. M. Heard" , Gorry Fairhurst References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <81ad1cd3-197b-1b19-6358-43e4390fb722@isi.edu> <8e7bc6cc-d61f-89d4-c6b1-a5e6135fc0b3@isi.edu> <58D9378A.7010504@erg.abdn.ac.uk> Cc: Mark Smith , tsvwg From: Joe Touch Message-ID: <342aceb8-a985-f15e-ad7f-6ef36cf85ff3@isi.edu> Date: Mon, 27 Mar 2017 10:53:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------383C51EE044E48E9752DC5FB" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-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: Mon, 27 Mar 2017 17:54:07 -0000 This is a multi-part message in MIME format. --------------383C51EE044E48E9752DC5FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Mike, I don't know if we have a sense of what the future will evolve into, but the likely more immediate use is packets too large for the path MTU but not all that big overall - which suggests we ought to use CRC-16-CCITT. I'll roll that in and issue the update shortly. Joe On 3/27/2017 10:41 AM, C. M. Heard wrote: > I have no objections to that. As for the selection of the specific > polynomial: > > * If you think protection of long payloads ~8K bytes is of > overriding importance, choose CRC-16-CDMA2000 > * If you think protection of shorter payloads (less than 4K bytes) > is more important, choose CRC-16-CCITT or CRC-16-IBM > > My sense is that CRC-16-CCITT is more widely used than CRC-16-IBM and > may be preferable for that reason. > > Mike Heard > > On Mon, Mar 27, 2017 at 9:02 AM, Gorry Fairhurst > wrote: > > I'd think CRC-16 is likely to be a good proposal. 32b alignment is > always good. > > Gorry > > > On 27/03/2017, 10:37, Joe Touch wrote: > > So do we want to recommend a 16-bit value or jump to the > 32-bit one? > > IMO, for UDP, anything reasonably stronger than the Internet > checksum > should be fine. I was hoping for a 16-bit selection to leave > the result > 32-bit aligned... > > Joe > > > On 3/25/2017 7:37 PM, C. M. Heard wrote: > > On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch > wrote: > > On 3/25/2017 6:26 AM, C. M. Heard wrote: > > On Wed, Mar 22, 2017 at 10:43 PM, Joe > Touch> wrote: > > In section 5.4, was a decision made as to > what the CRC16 is? Details > will be needed in order to ensure > interoperability. > > That's on my to-do list (I was a bit > distracted by these other issues). > There are three obvious possibilities: > > CRC-16-CCITT used by Bluetooth, > X.25, HDLC (4 terms - 0x1021) > CRC-16-IBM used by USB (4 terms > -- 0x8005) > CRC-16-CDMA2000 used by CDMA mobile nets > (8 terms - 0xC867) > > There are other analyses that point to other > polynomials: > https://users.ece.cmu.edu/~koopman/crc/ > > > Any suggestions? > > Both the CRC-16-CCITT and CRC-16-IBM polynomials > factor into the product > of x+1 times a primitive polynomial of degree 15 > (*op in Koopman's notation) > and are in a sense optimal for random error > patterns. They detect all triple > errors (and all error patterns of odd weight) for > data lengths of 4093 bytes > or less. The CRC-16-CDMA2000 has a single factor, > which is a primitive > degree 16 polynomial (*p in Koopman's notation), > and it will detect all > double errors for data lengths of 8189 bytes or > less. By data length I > mean of course the length of the data protected by > the CRC (not > including the CRC itself). > > There are generic fast table lookup algorithms for > all CRC-16 polynomials, > including automated methods for generating the > lookup tables, so that is > not really a factor in choosing a polynomial. > > I that case should we go with CRC-16-CDMA2000? > > Or is there a better/stronger one from the table > that's more useful? > > Actually, CRC-16-CCITT or CRC-16-IBM (which are > theoretically equivalent) > are ***stronger** than CRC-16-CDMA2000 for datagram > payloads up to 32751 > bits (i.e., CRC + data length = 32767 bits), when errors > are random. For > datagrams of that exact length It can be proven (again for > random errors) > that the undetected error rate is no worse than 1/65536, > and for lesser > lengths simulations bear this out (see, for example, > http://doc.utwente.nl/64267/1/schiphorst.pdf > ). The only > reason I can see > to choose CRC-16-CDMA2000 would be to provide protection > for datagrams > longer than 4K bytes, in which case a better choice would > be a 32-bit CRC. > The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is > > x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1 > > Although it is a primitive polynomial (without a factor of > x+1) it will > protect against all triple error patters for datagram > lengths of 11450 > bytes, according to simulations that I ran about 14 years > ago, and > its undetected error rate (for random errors) can be > expected to be > under 2^-32. So that's what I would be inclined to recommend. > > Regards, > > Mike Heard > > > --------------383C51EE044E48E9752DC5FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Mike,

I don't know if we have a sense of what the future will evolve into, but the likely more immediate use is packets too large for the path MTU but not all that big overall - which suggests we ought to use CRC-16-CCITT.

I'll roll that in and issue the update shortly.

Joe


On 3/27/2017 10:41 AM, C. M. Heard wrote:
I have no objections to that. As for the selection of the specific polynomial:
  • If you think protection of long payloads ~8K bytes is of overriding importance, choose CRC-16-CDMA2000
  • If you think protection of shorter payloads (less than 4K bytes) is more important, choose CRC-16-CCITT or CRC-16-IBM
My sense is that CRC-16-CCITT is more widely used than CRC-16-IBM and may be preferable for that reason.

Mike Heard

On Mon, Mar 27, 2017 at 9:02 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
I'd think CRC-16 is likely to be a good proposal. 32b alignment is always good.

Gorry


On 27/03/2017, 10:37, Joe Touch wrote:
So do we want to recommend a 16-bit value or jump to the 32-bit one?

IMO, for UDP, anything reasonably stronger than the Internet checksum
should be fine. I was hoping for a 16-bit selection to leave the result
32-bit aligned...

Joe


On 3/25/2017 7:37 PM, C. M. Heard wrote:
On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch<touch@isi.edu>  wrote:
On 3/25/2017 6:26 AM, C. M. Heard wrote:
On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch<touch@isi.edu>  wrote:
In section 5.4, was a decision made as to what the CRC16 is? Details
will be needed in order to ensure interoperability.
That's on my to-do list (I was a bit distracted by these other issues).
There are three obvious possibilities:

CRC-16-CCITT            used by Bluetooth, X.25, HDLC (4 terms - 0x1021)
CRC-16-IBM               used by USB (4 terms -- 0x8005)
CRC-16-CDMA2000    used by CDMA  mobile nets (8 terms - 0xC867)

There are other analyses that point to other polynomials:
https://users.ece.cmu.edu/~koopman/crc/

Any suggestions?
Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product
of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation)
and are in a sense optimal for random error patterns. They detect all triple
errors (and all error patterns of odd weight) for data lengths of 4093 bytes
or less. The CRC-16-CDMA2000 has a single factor, which is a primitive
degree 16 polynomial (*p in Koopman's notation), and it will detect all
double errors for data lengths of 8189 bytes or less. By data length I
mean of course the length of the data protected by the CRC (not
including the CRC itself).

There are generic fast table lookup algorithms for all CRC-16 polynomials,
including automated methods for generating the lookup tables, so that is
not really a factor in choosing a polynomial.
I that case should we go with CRC-16-CDMA2000?

Or is there a better/stronger one from the table that's more useful?
Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent)
are ***stronger** than CRC-16-CDMA2000  for datagram payloads up to 32751
bits (i.e., CRC + data length = 32767 bits), when errors are random. For
datagrams of that exact length It can be proven (again for random errors)
that the undetected error rate is no worse than 1/65536, and for lesser
lengths simulations bear this out (see, for example,
http://doc.utwente.nl/64267/1/schiphorst.pdf). The only reason I can see
to choose CRC-16-CDMA2000 would be to provide protection for datagrams
longer than 4K bytes, in which case a better choice would be a 32-bit CRC.
The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is

x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1

Although it is a primitive polynomial (without a factor of x+1) it will
protect against all triple error patters for datagram lengths of 11450
bytes, according to simulations that I ran about 14 years ago, and
its undetected error rate (for random errors) can be expected to be
under 2^-32. So that's what I would be inclined to recommend.

Regards,

Mike Heard



--------------383C51EE044E48E9752DC5FB-- From nobody Mon Mar 27 12:19:20 2017 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 401CD1295E9 for ; Mon, 27 Mar 2017 12:19:14 -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, RP_MATCHES_RCVD=-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 lu0iGSdLYuqa for ; Mon, 27 Mar 2017 12:19:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 4C7DD12947E for ; Mon, 27 Mar 2017 12:19:10 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2RJIogA029616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Mar 2017 12:18:53 -0700 (PDT) References: <149064186188.30646.13057160298078965889.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <149064186188.30646.13057160298078965889.idtracker@ietfa.amsl.com> Message-ID: <34a27961-b57b-2a8f-338d-c72138856f6f@isi.edu> Date: Mon, 27 Mar 2017 12:18:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149064186188.30646.13057160298078965889.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------466060F93749A18CC75D8AFB" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-06.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, 27 Mar 2017 19:19:14 -0000 This is a multi-part message in MIME format. --------------466060F93749A18CC75D8AFB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, Here is the announcement for the 06 update, which I posted on my website for review during the (laughably out of date) ID submission blackout period. The document is dated today for the (similarly incomprehensible) restriction on dates on submission in the ID submission tool. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-06.txt Date: Mon, 27 Mar 2017 12:11:01 -0700 From: internet-drafts@ietf.org To: Joseph Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-06.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 06 Title: Transport Options for UDP Document date: 2017-03-27 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-06.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-06 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-06 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. 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. The IETF Secretariat --------------466060F93749A18CC75D8AFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, all,

Here is the announcement for the 06 update, which I posted on my website for review during the (laughably out of date) ID submission blackout period.

The document is dated today for the (similarly incomprehensible) restriction on dates on submission in the ID submission tool.

Joe



-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-06.txt
Date: Mon, 27 Mar 2017 12:11:01 -0700
From: internet-drafts@ietf.org
To: Joseph Touch <touch@isi.edu>, Joe Touch <touch@isi.edu> 


A new version of I-D, draft-touch-tsvwg-udp-options-06.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	06
Title:		Transport Options for UDP
Document date:	2017-03-27
Group:		Individual Submission
Pages:		25
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-06.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-06

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP by indicating the
   location, syntax, and semantics for UDP transport layer options.

                                                                                  


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.

The IETF Secretariat
--------------466060F93749A18CC75D8AFB-- From nobody Mon Mar 27 12:20:23 2017 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 70FD31295EB for ; Mon, 27 Mar 2017 12:20:21 -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, RP_MATCHES_RCVD=-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 43mMB0Bn9e4V for ; Mon, 27 Mar 2017 12:20:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0F94F12957F for ; Mon, 27 Mar 2017 12:20:18 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2RJJiTu029970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Mar 2017 12:19:46 -0700 (PDT) References: <149064207875.30630.2197908984907064402.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <149064207875.30630.2197908984907064402.idtracker@ietfa.amsl.com> Message-ID: <197c1738-83c9-6bc3-3145-303a47dba087@isi.edu> Date: Mon, 27 Mar 2017 12:19:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149064207875.30630.2197908984907064402.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------4F2C3761FE7CAE40EEF9F87E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-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: Mon, 27 Mar 2017 19:20:21 -0000 This is a multi-part message in MIME format. --------------4F2C3761FE7CAE40EEF9F87E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit And here is the 07 update, which pins down the CRC algorithm and clarifies how these alternate checksums (including the FRAG variant) are computed. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-07.txt Date: Mon, 27 Mar 2017 12:14:38 -0700 From: internet-drafts@ietf.org To: Joseph Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-07.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 07 Title: Transport Options for UDP Document date: 2017-03-27 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-07.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-07 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-07 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. 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. The IETF Secretariat --------------4F2C3761FE7CAE40EEF9F87E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

And here is the 07 update, which pins down the CRC algorithm and clarifies how these alternate checksums (including the FRAG variant) are computed.

Joe



-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-07.txt
Date: Mon, 27 Mar 2017 12:14:38 -0700
From: internet-drafts@ietf.org
To: Joseph Touch <touch@isi.edu>, Joe Touch <touch@isi.edu> 


A new version of I-D, draft-touch-tsvwg-udp-options-07.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	07
Title:		Transport Options for UDP
Document date:	2017-03-27
Group:		Individual Submission
Pages:		25
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-07.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-07

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP by indicating the
   location, syntax, and semantics for UDP transport layer options.

                                                                                  


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.

The IETF Secretariat
--------------4F2C3761FE7CAE40EEF9F87E-- From nobody Mon Mar 27 13:47:21 2017 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 A4FAB12965B for ; Mon, 27 Mar 2017 13:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 2bMPZkGUjkoG for ; Mon, 27 Mar 2017 13:47:16 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6725312964B for ; Mon, 27 Mar 2017 13:47:16 -0700 (PDT) Received: from [192.168.1.121] (p57BB5102.dip0.t-ipconnect.de [87.187.81.2]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9B56F721E280C; Mon, 27 Mar 2017 22:47:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> Date: Mon, 27 Mar 2017 22:47:09 +0200 Cc: "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> To: "Proshin, Maksim" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 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, 27 Mar 2017 20:47:20 -0000 > On 21 Mar 2017, at 07:16, Proshin, Maksim wrote: >=20 > Hi Michael, >=20 > Basically I'm ok with all your answers and updates.=20 > I don't have any major comments but I have a few proposals below = inline (by [Maksim] tag). Hi Maksim, see my comments in-line. I've removed issues which are resolved. Best regards Michael >=20 > BR, Maksim >=20 >=20 > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: Monday, March 13, 2017 14:00 > To: Proshin, Maksim > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, = closes 22 Dec 2016 >=20 >> On 19 Dec 2016, at 17:16, Proshin, Maksim wrote: >>=20 >> Hi, >>=20 >> Thanks for the document! Please find below some comments. Only major = comments are included while editorial/minor comments have been sent = directly to Michael. > Hi Maxim, >=20 > thanks a lot for the review. I addresses the minor comments and = responded to your mail. > See my comments in-line. >=20 > Best regards > Michael >>=20 >> 1. Section 1.1: "DATA chunks are not >> permitted when I-DATA support has been negotiated." >> What exactly does it mean for implementation (both sending and=20 >> receiving sides)? I think to avoid any problems with the sending side=20= >> it should be "MUST NOT" in the sentence. For the receiving side I=20 >> suppose it means stop processing of the packet and silently discard=20= >> all further chunks in the packet, right? I think this should be=20 >> clearly stated. It could also be good to clearly state that after=20 >> association > I think it is clearly stated in 2.2.1: >=20 > If I-DATA support has been negotiated for an association, I-DATA = chunks MUST be used for all user messages and DATA-chunks MUST NOT be = used. If I-DATA support has not been negotiated for an association, DATA = chunks MUST be used for all user messages and I-DATA chunks MUST NOT be = used. >=20 > [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the = sender. Can the same be explained for the receiver? >=20 > So if these rules are violated, I think sending an ABORT with protocol = violation might be appropriate. > [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it would = be good to state that such case should be treated as a protocol = violation. I also wonder that it should be mentioned that the restart = case is different and should not be treated as a violation.=20 >=20 >> restart which was with DATA previously but became with I-DATA after = the restart, SCTP still may receive packets with DATA and they should be = silently discarded due to VTag mismatch following the rules of Section = 8.5. from RFC4960 (I suppose this is important to avoid any "protocol = violation" reaction).=20 > Sure. But this is normal restart behavior. > [Maksim] The reason I've asked it is because the statement is that = this is "permitted" while in the restart case it is still possible to = receive DATA while I-DATA was already negotiated. >>=20 >>=20 >> 6. Section 4.1:=20 >> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive = Information Structure cannot be introduced instead of using the existing = one? > One could add such a structure, but is it needed? I don't see a = use-case... > [Maksim] Isn't the drawback of the current approach is that 16 bits = are lost? >> If the new SCTP Receive Information Structure is introduced then a = new message receive function should also be introduced (instead of = recv_msg() ). Is that the main problem? > recvmsg() is generic. It doesn't need to be changed. You would add = another CMSG. >> Of course, it would also be a problem if the interleaving = functionality requires enabling only on the sender side (see the next = comment). > No, it is required to be enabled on both sides. >>=20 >>=20 >> 7. Section 4.3.1: >> User message interleaving is disabled per default. >> I'm not sure about it. First of all I think it should be clearly = stated what does it mean for the sender and for the receiver. >> If the intention was that I-DATA is included to INIT and INIT ACK = only when the user enabled this functionality then I think this is not a = good way because then it impacts not only the sender but also the = receiver.=20 >> In other words, if the feature is disabled by default on both sides = while SCTP on both sides support it then it is not enough to just enable = it on one side, it requires enabling it on the other side. =20 > Exactly. I think this is stated in the first sentence of 2.2.1. > [Maksim] I think it is not clearly stated in the document. "Supported" = does not really mean "enabled". I would clearly state that this = functionality should be enabled on both sides and only in this case it = could be successfully negotiated. Especially it is important to state = for the receiver side because Section 2.2.1 has the following statement = "A sender MUST NOT use the I-DATA chunk unless the user has requested = its use (e.g. via the socket API, see Section 4.3)."=20 >>=20 >> 9. Section 6: In case of DTLS over SCTP support of the message = interleaving functionality may increase the risk of receiving messages = with new epoch after ChangeCipherSpec message and before Finished = message. > Possibly. But implementations have to deal with it anyway. So what is = the point? > [Maksim] Mainly my point was that it could be clarified so that future = SCTP implementations of this draft/RFC supporting DTLS could consider = it.=20 From nobody Mon Mar 27 13:48:38 2017 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 9248412964B for ; Mon, 27 Mar 2017 13:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 IbKEP6SMbjcQ for ; Mon, 27 Mar 2017 13:48:34 -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 420A012963D for ; Mon, 27 Mar 2017 13:48:34 -0700 (PDT) Received: from [192.168.1.121] (p57BB5102.dip0.t-ipconnect.de [87.187.81.2]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 02DDD721E280C; Mon, 27 Mar 2017 22:48:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> Date: Mon, 27 Mar 2017 22:48:30 +0200 Cc: "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <808EF3FA-1B1A-4C15-8DCC-060C9BE94A19@lurchi.franken.de> References: <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> To: "Proshin, Maksim" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016 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, 27 Mar 2017 20:48:36 -0000 >=20 It went out too early... Sorry for the noise. Best regards Michael > Hi Michael, >=20 > Basically I'm ok with all your answers and updates.=20 > I don't have any major comments but I have a few proposals below = inline (by [Maksim] tag). Hi Maksim, see my comments in-line. I've removed issues which are resolved. Best regards Michael >=20 > BR, Maksim >=20 >=20 > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: Monday, March 13, 2017 14:00 > To: Proshin, Maksim > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, = closes 22 Dec 2016 >=20 >> On 19 Dec 2016, at 17:16, Proshin, Maksim wrote: >>=20 >> Hi, >>=20 >> Thanks for the document! Please find below some comments. Only major = comments are included while editorial/minor comments have been sent = directly to Michael. > Hi Maxim, >=20 > thanks a lot for the review. I addresses the minor comments and = responded to your mail. > See my comments in-line. >=20 > Best regards > Michael >>=20 >> 1. Section 1.1: "DATA chunks are not >> permitted when I-DATA support has been negotiated." >> What exactly does it mean for implementation (both sending and=20 >> receiving sides)? I think to avoid any problems with the sending side=20= >> it should be "MUST NOT" in the sentence. For the receiving side I=20 >> suppose it means stop processing of the packet and silently discard=20= >> all further chunks in the packet, right? I think this should be=20 >> clearly stated. It could also be good to clearly state that after=20 >> association > I think it is clearly stated in 2.2.1: >=20 > If I-DATA support has been negotiated for an association, I-DATA = chunks MUST be used for all user messages and DATA-chunks MUST NOT be = used. If I-DATA support has not been negotiated for an association, DATA = chunks MUST be used for all user messages and I-DATA chunks MUST NOT be = used. >=20 > [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the = sender. Can the same be explained for the receiver? >=20 > So if these rules are violated, I think sending an ABORT with protocol = violation might be appropriate. > [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it would = be good to state that such case should be treated as a protocol = violation. I also wonder that it should be mentioned that the restart = case is different and should not be treated as a violation.=20 >=20 >> restart which was with DATA previously but became with I-DATA after = the restart, SCTP still may receive packets with DATA and they should be = silently discarded due to VTag mismatch following the rules of Section = 8.5. from RFC4960 (I suppose this is important to avoid any "protocol = violation" reaction).=20 > Sure. But this is normal restart behavior. > [Maksim] The reason I've asked it is because the statement is that = this is "permitted" while in the restart case it is still possible to = receive DATA while I-DATA was already negotiated. >>=20 >>=20 >> 6. Section 4.1:=20 >> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive = Information Structure cannot be introduced instead of using the existing = one? > One could add such a structure, but is it needed? I don't see a = use-case... > [Maksim] Isn't the drawback of the current approach is that 16 bits = are lost? >> If the new SCTP Receive Information Structure is introduced then a = new message receive function should also be introduced (instead of = recv_msg() ). Is that the main problem? > recvmsg() is generic. It doesn't need to be changed. You would add = another CMSG. >> Of course, it would also be a problem if the interleaving = functionality requires enabling only on the sender side (see the next = comment). > No, it is required to be enabled on both sides. >>=20 >>=20 >> 7. Section 4.3.1: >> User message interleaving is disabled per default. >> I'm not sure about it. First of all I think it should be clearly = stated what does it mean for the sender and for the receiver. >> If the intention was that I-DATA is included to INIT and INIT ACK = only when the user enabled this functionality then I think this is not a = good way because then it impacts not only the sender but also the = receiver.=20 >> In other words, if the feature is disabled by default on both sides = while SCTP on both sides support it then it is not enough to just enable = it on one side, it requires enabling it on the other side. =20 > Exactly. I think this is stated in the first sentence of 2.2.1. > [Maksim] I think it is not clearly stated in the document. "Supported" = does not really mean "enabled". I would clearly state that this = functionality should be enabled on both sides and only in this case it = could be successfully negotiated. Especially it is important to state = for the receiver side because Section 2.2.1 has the following statement = "A sender MUST NOT use the I-DATA chunk unless the user has requested = its use (e.g. via the socket API, see Section 4.3)."=20 >>=20 >> 9. Section 6: In case of DTLS over SCTP support of the message = interleaving functionality may increase the risk of receiving messages = with new epoch after ChangeCipherSpec message and before Finished = message. > Possibly. But implementations have to deal with it anyway. So what is = the point? > [Maksim] Mainly my point was that it could be clarified so that future = SCTP implementations of this draft/RFC supporting DTLS could consider = it.=20 From nobody Mon Mar 27 18:05:08 2017 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 E6B0D1297D6; Mon, 27 Mar 2017 18:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wjE3vC5wyqV1; Mon, 27 Mar 2017 18:04:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3FE1297CB; Mon, 27 Mar 2017 18:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3668; q=dns/txt; s=iport; t=1490663097; x=1491872697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iRnV0Hfbc6M2N5vYU9IiIqKxK+LF9Ps4DERtE/n+U/g=; b=eWpxPUq6NnVOic9zOPiLsJ3O9rrexqshvT6E/v6h7z+EQcCK6+AB9OyC z4OFMx9lRMfieKihxv7IZ7lHqO0qOnnBuoPDIQec8p+Lb7urjMHtZJbpW j/DukpUD4zkLrC8AzvHt9BCPlvXzsCfpypcoqiPIqGwUeeycVxGinpw32 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBptdlY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjWqnG4IOHwuFeAKDHj8YAQIBAQEBAQEBayiFFgIBAwE?= =?us-ascii?q?BJS0aCxACAQgOOCcLJQIEAQ0FigcOrXc6ik8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYZOhG+EJ4YSAQScWwGSS4F8hSqKC5NkAR84gQRZFUGEWB2BY3WHMYEvgQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="7590223" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 01:04:56 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2S14u7f016426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 01:04:56 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 20:04:55 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Mon, 27 Mar 2017 20:04:55 -0500 From: "Rong Pan (ropan)" To: Bob Briscoe , Greg White , "FredBaker.IETF@gmail.com" , "prenatar@cisco.com" CC: AQM IETF list , "De Schepper, Koen (Koen)" , tsvwg IETF list Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqA Date: Tue, 28 Mar 2017 01:04:55 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> In-Reply-To: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.35.73] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 01:05:00 -0000 Bob, Sorry for the late reply. I have been traveling. Please see inline=8A Rong On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" wrote: >Rong, Preethi, Greg, Fred, and others involved in PIE, > >You may recall that when we wrote PI2 we didn't include any of PIE's >heuristics. Mostly because PI2 solved the issues they addressed >intrinsically. But we left some until we had checked their benefit, >which is what I'm doing now... > >My first question is about this heuristic in PIE: > > //Safeguard PIE to be work conserving > if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) > || (queue_.byte_length() <=3D 2 * MEAN_PKTSIZE) ) { > return ENQUE; > } > >If it tests true, this block doesn't stop the calculation of drop_prob_ >evolving, but it disables it being able to lead to any random packet drop. > >I can understand why you want to disable packet drop when the queue is >no more than 2 packets. >My question is about the first half of the logical OR. The drop_prob_ < >20% test will be true under normal non-overloaded conditions. So I have >just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off >random drop very often. I would expect this to radically impact the >behaviour of PIE. It seems to be overriding the PI controller as if you >are thinking "actually we don't really trust the PI controller to leave >it to do its thing, so we've overridden it a lot of the time." For >instance, whenever a single long-running TCP flow with RTT about the >same as the target delay is saw-toothing, this test will disable random >drop completely during the lower half of every saw-tooth in the queue. >Maybe that's OK, but... > >Without this test, the PI controller should reduce drop probability as >the queue sawtooths down anyway. If another flow causes the queue to >rise rapidly while it is under half the target, the PI controller is >designed to detect such an increase and translate it into drop. But this >heuristic suppresses any drop until the queue has exceeded half the >target. > >So my questions are: > >Q1. What were the reasons for introducing such a frequent suppression of >the PI algorithm (the RFC just says what this code does, not why)? To be work conserving and avoid any unnecessary drops are the main reasons behind it.=20 Cisco had a not so successful algorithm before that is not work conserving. So we are extra cautious about being work conserving... > >Q2. Why use qdelay_old_ in the test? This seems to drive suppression of >drop using stale state. qdelay_old_ is the latency state currently stored. This is for implementation Considerations as we don=B9t want to calculate qdelay_ on per packet basis. > >Q3. Having said that it looks like this heuristic will significantly >alter PIE's behaviour, in tests under a very wide range of traffic >conditions, link rates, mixed RTTs, traffic models etc, we have found >that removing the heuristics makes no measurable difference to PIE's >performance. So if you added this heuristic for a specific scenario, >please describe it, so we can test for it. Again, to be work conserving and avoid drops are our goal. I don=B9t think it would be hurtful to add those safeguards. > > >Cheers > > >Bob > > > > >--=20 >________________________________________________________________ >Bob Briscoehttp://bobbriscoe.net/ > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm From nobody Mon Mar 27 23:25:36 2017 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 74239129442; Mon, 27 Mar 2017 23:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 yFXJ6hSDeaQx; Mon, 27 Mar 2017 23:25:29 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 3C043128CDB; Mon, 27 Mar 2017 23:25:28 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id h125so32456926lfe.0; Mon, 27 Mar 2017 23:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QKHxQul1VV0ET6/HK1FlJLmyHX3kM590g257eSlc1o=; b=KIgwnyByaQY73NT+OqUEndC6J4Qb1kdjj6DK7eiDxk2MeIMJY6G6e+b5BZG9vfkRNp 9TEjYe6csUVej7He8RwtEC6VDt68dC2wBCMJs5+VdV1wXJip9AZroaWBF/xkFF7AxKvf eQlNC79Zhn4ABG2dVMf2yr/OEa2s1sAQIQiEdshlEd6Es4FivLQ7nSeseBoTbHgS70FJ C7WA/+FlkXVBQ/mZPbeQmiPVloIx7VZNCMxYkV4mAG7aL/3Rb9Sw6fTYQ1bqQfBuZN/Z OPABEafo7NRjz9Jhpgn56jikDpYMEJF0k5O7LBdsHZGUJ/bbNGu2LBeux5giWoPsE/cC eFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QKHxQul1VV0ET6/HK1FlJLmyHX3kM590g257eSlc1o=; b=i4F+7IhLrK0JfFhqBBxKNnyaXeTFEqQ1qmF3keyT95i525vndhLXPGy5mMUlfkvZuh IwTSEHgb9D82EfgaTyY71x4ZWtgD/1sIAizQqVy2wYzitsQobm0a12qQ8OhTBSzAiQ7m ++dexbHoTw2zovECbs6gTWH+t1xBLbv4AU1o6PDNoLyBYvWO1a1KUdOMSvdU3OascsyH LVvVI6kCmC/LRIp878vxoOBS2tpnv6t1PfkUOIvheGgXC0/jG++ZYEghsmN5ARpGOn0a am0obDL9YUwuZ64alMfFkMpqk7/AYa02nlz6G0emW1yXKYCh3fJ42xhBlXtZ+RQddN/o DF4A== X-Gm-Message-State: AFeK/H2udH0WeEGdmClqJgsm3I7FZMYb0OVX/Dy8u61BGl1mnBDRfwucD/qsUv9eG82ovw== X-Received: by 10.46.22.92 with SMTP id 28mr971252ljw.55.1490682326531; Mon, 27 Mar 2017 23:25:26 -0700 (PDT) Received: from [192.168.100.14] (37-219-158-10.nat.bb.dnainternet.fi. [37.219.158.10]) by smtp.gmail.com with ESMTPSA id f19sm493040lji.69.2017.03.27.23.25.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Mar 2017 23:25:25 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Tue, 28 Mar 2017 09:25:22 +0300 Cc: Bob Briscoe , Greg White , "FredBaker.IETF@gmail.com" , "prenatar@cisco.com" , AQM IETF list , "De Schepper, Koen (Koen)" , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> To: "Rong Pan (ropan)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 06:25:30 -0000 > On 28 Mar, 2017, at 04:04, Rong Pan (ropan) wrote: >=20 >> Q1. What were the reasons for introducing such a frequent suppression = of >> the PI algorithm (the RFC just says what this code does, not why)? >=20 > To be work conserving and avoid any unnecessary drops are the main = reasons > behind it.=20 > Cisco had a not so successful algorithm before that is not work > conserving. So we are extra cautious about being work conserving... AQM algorithms are by definition *not* work-conserving, because they can = drop packets. By *definition*. I therefore think you=92re chasing a = non-goal here, and you=92re going to have to justify it much more = clearly if it=92s going to make it into an RFC. By all means, avoid dropping packets when the queue is actually empty - = that is, when you=92re delivering the last packet in the queue. In that = case, there is no congestion to signal for. But there really is no need = to have any complex state-switching logic for that. If your underlying = algorithm is sound, it will naturally decay to zero packet drops if the = empty-queue condition persists. - Jonathan Morton From nobody Tue Mar 28 04:39:14 2017 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 0ABC4129998; Tue, 28 Mar 2017 04:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 ojKIokzSYwQ7; Tue, 28 Mar 2017 04:39:06 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 3020F129983; Tue, 28 Mar 2017 04:39:06 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id 76so2715986itj.0; Tue, 28 Mar 2017 04:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uzatusOboud4BsQ3OSffU2pCcQHUIg/brBfv/6SIjqE=; b=C0qHyN2wgvHGumpLrcD9E5Qe29T5Kk2KnpTJBW7BKQdqU2fR0+xGCO/b169oXIeI/d 9rdR7swWs9vPjIxv+81dZdnfeHD4xiTWV52+Mj4LDI8R01TfkHoM3L7k+2MPJqJ0oZFy iVVzhs+G+h/dEHSq61tVKS38C8Di4Nyo85pSVnXISc03pNPFh3VPjb0wKHOaAODgFSTe 6Hp+2W0fy7sYDKLQdC3cogpBV3vFPbHMpK6LSfFZqc8BC0t601p0wnbHXN6zTJlz35X6 jlxu6flOAXos4CUOeU4A6Hf0s/qWE3KB89IJ8eIUclLT0TCg4NLJFs1oPh/Pr8PbO+0z n7/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uzatusOboud4BsQ3OSffU2pCcQHUIg/brBfv/6SIjqE=; b=TOT20sGhr/BT/XqUswj6pp31xvmB5YU9owEha0LnlQmGMblqkDUSLg+l9h2o86DdyH FZuifxulO8becDam63EU17C4RAyYgpdLt8k/4IF1iq2aa+Y63CrGXCTmNuGkDfmlT8Zd Ztx+bZH25U8T8nTz1P0aR2KjNPSuFHBGQQJFa1CK9b+Z+88EXvOvGmKyw73Om13r/bhP SIih8yXhyjDPHYi2dkklGajSZ1+qU7Cqn8p56nN0fs/GizY+17DonynuwIFxGxVP2du7 kkSywcezDUktnlIj0yhu+rGJPeJqNYDmbnrbyEYkOh+wBLomLsXnC5BlgZ+wkf7icoO9 Gh9A== X-Gm-Message-State: AFeK/H0Ffv6YSLPMUCV6i4+n9UXUbkNI0VawAXj6lQBNE0agUxOLzSbeCG0A03RNTI97Vg== X-Received: by 10.107.169.227 with SMTP id f96mr25867600ioj.199.1490701145567; Tue, 28 Mar 2017 04:39:05 -0700 (PDT) Received: from ?IPv6:2001:67c:1233::5c8b:aa3:1836:b8? ([2001:67c:1233:0:5c8b:aa3:1836:b8]) by smtp.gmail.com with ESMTPSA id d12sm1761767iog.41.2017.03.28.04.39.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 04:39:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Fred Baker In-Reply-To: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> Date: Tue, 28 Mar 2017 06:39:05 -0500 Cc: Rong Pan , Bob Briscoe , Greg White , Preethi Natarajan , AQM IETF list , "De Schepper, Koen (Koen)" , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 11:39:08 -0000 > On Mar 28, 2017, at 1:25 AM, Jonathan Morton = wrote: >=20 >=20 >> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) wrote: >>=20 >>> Q1. What were the reasons for introducing such a frequent = suppression of >>> the PI algorithm (the RFC just says what this code does, not why)? >>=20 >> To be work conserving and avoid any unnecessary drops are the main = reasons >> behind it.=20 >> Cisco had a not so successful algorithm before that is not work >> conserving. So we are extra cautious about being work conserving... >=20 > AQM algorithms are by definition *not* work-conserving, because they = can drop packets. By *definition*. I therefore think you=E2=80=99re = chasing a non-goal here, and you=E2=80=99re going to have to justify it = much more clearly if it=E2=80=99s going to make it into an RFC. >=20 > By all means, avoid dropping packets when the queue is actually empty = - that is, when you=E2=80=99re delivering the last packet in the queue. = In that case, there is no congestion to signal for. But there really is = no need to have any complex state-switching logic for that. If your = underlying algorithm is sound, it will naturally decay to zero packet = drops if the empty-queue condition persists. I'm not convinced I understand the definitions of "work conserving" and = "non work conserving" in this context. A "work conserving" scheduling = algorithm keeps an interface transmitting as long as there is data in = the queue, while a non-work-conserving algorithm reduces the effective = rate of the interface by spacing packets out.=20= From nobody Tue Mar 28 04:47:00 2017 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 2CE1D1299B2; Tue, 28 Mar 2017 04:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 VWASFV908Eku; Tue, 28 Mar 2017 04:46:57 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 EAC421299BC; Tue, 28 Mar 2017 04:46:53 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id x137so36285861lff.3; Tue, 28 Mar 2017 04:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cP2VIevEqGr2DvrVqfqVGJwKLEzRJzalYawF/qXpGcw=; b=ElK/ZQDWaJDIadpzzEzoKWv3+BDtiwtNJv34E0s/LvczabpeCSQPU+9SnbVUY28NXV wR3MtFogWfqWQQ1892k/LopaEA8UG+/gbTW1pMVaQXhbhEk0rm/DJhXGP1IXyy0DSHa+ 6H4eWv6Jk1qJzE/UaQ9TygGNWZnVcP4GnRCRFwtps4QLu0CiaSM2BBv5bnYVeD7pBEpt +zZn5eKRCd56fwb+qAwvoIlgsmijPaH2ZVjB47cUj9YyLIV04WlaebCf/KyUqRA6LWZV /PscKtf1VAsf20gUFfsrKimW+CZHITKnIAo8e3VYHFphIpw3/BU98t05vAg2QZv8d4V5 v8Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cP2VIevEqGr2DvrVqfqVGJwKLEzRJzalYawF/qXpGcw=; b=B+hRn2KfKc/JIZ98Csg4GNkGgYv6bXDN54/2/0txEAJMXnq9y1kbNjwsbELAJg/e72 Girzn+mGm/IB8qzfn6ejmn/buQxTY37vSjgFBq7XNe2XV5XplIKy5RcgFu/oeQNOzKsR VJ0YHtwrZRSq9IKqDWo5QCi51ljEjoqtdd40v7EgnI80omSk5SQC3jhS161S2cLECw/W mGFF3JI7UfTsHXflOlDbPGaBUlYsOzm8dulCwPuJzJGBSs6RSuidXrUqkFcOkN11O3qL ChHTPztI8Bm7OML0Go54sf0WFeMjFw2du8DdRoTfhP5zERxHWDNbIDu1twt8aZknrwVH 0ESg== X-Gm-Message-State: AFeK/H2tjs4A/5m+NQE711t4OXRqhcnqBaJTDMu26oiNHqbeITfVLVzbt0NwLhLsn4BrAQ== X-Received: by 10.25.211.2 with SMTP id k2mr13160433lfg.61.1490701612260; Tue, 28 Mar 2017 04:46:52 -0700 (PDT) Received: from [192.168.100.14] (37-219-158-10.nat.bb.dnainternet.fi. [37.219.158.10]) by smtp.gmail.com with ESMTPSA id m2sm632776lfg.35.2017.03.28.04.46.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Mar 2017 04:46:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Tue, 28 Mar 2017 14:46:48 +0300 Cc: Rong Pan , Bob Briscoe , Greg White , Preethi Natarajan , AQM IETF list , "De Schepper, Koen (Koen)" , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <4C00F349-7F88-413A-AB1B-5487779301F8@gmail.com> References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 11:46:59 -0000 > On 28 Mar, 2017, at 14:39, Fred Baker = wrote: >=20 > I'm not convinced I understand the definitions of "work conserving" = and "non work conserving" in this context. A "work conserving" = scheduling algorithm keeps an interface transmitting as long as there is = data in the queue, while a non-work-conserving algorithm reduces the = effective rate of the interface by spacing packets out. In which case the explanation makes even less sense, as PIE doesn=E2=80=99= t include a shaper. - Jonathan Morton From nobody Tue Mar 28 04:48:58 2017 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 D8F791294F6; Tue, 28 Mar 2017 04:48: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 7e7k7op9g9Qs; Tue, 28 Mar 2017 04:48:53 -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 836C9129431; Tue, 28 Mar 2017 04:48:53 -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 1cspcB-0002zA-2K; Tue, 28 Mar 2017 13:48:43 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id F32ACB00453; Tue, 28 Mar 2017 13:48:42 +0200 (CEST) To: Fred Baker , Jonathan Morton References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> Cc: tsvwg IETF list , Bob Briscoe , "De Schepper, Koen (Koen)" , Greg White , Rong Pan , AQM IETF list , Preethi Natarajan From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> Date: Tue, 28 Mar 2017 13:48:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1490701723. Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 11:48:56 -0000 Hi, Am 28.03.2017 um 13:39 schrieb Fred Baker: > I'm not convinced I understand the definitions of "work conserving" > and "non work conserving" in this context. A "work conserving" > scheduling algorithm keeps an interface transmitting as long as there > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out. +1 (that's also the definition I use, so I'm lost here too) Regards, Roland From nobody Tue Mar 28 05:48:58 2017 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 5DF13124281; Tue, 28 Mar 2017 05:48:56 -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 4AzOy5EMki16; Tue, 28 Mar 2017 05:48:54 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 44CCF1200C1; Tue, 28 Mar 2017 05:48:54 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i34so62724319qtc.0; Tue, 28 Mar 2017 05:48:54 -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=W6EfJgH7gvTRmrSe1FpFk4gWtvHbsbrIhEL5qltJ5EE=; b=JIG/kwOGnxmwNxgbsxGU2z+RwOJ1oQ0giRO4wNg33qNPRhjI4dnch8mdQSLGWOVWUI QMMrMEX6zksTTty9w+03EdPMjX//j3ehUkATBWq7YJnoIXG6WBFr2yKGP3oXytxIKn56 w+KC0AcKm6d431eKzt8cvBVgBDhwc5YRfiv8h7Vqf2ozA6la57DH63gAh8jJJLKTDteO WhxYm2tdeZtWygOedYf0jRY9VdJZgxK6xC0+6yHvhxbGqKdvKAhRrtgB6H5IG7Sf2DnI lSqJwzuGS/k71CBPixJqBaeDLX1yU+Sg44KtFF1Po/0a4IVDA0iu1dWrDcmCUsgZBPTR 60MA== 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=W6EfJgH7gvTRmrSe1FpFk4gWtvHbsbrIhEL5qltJ5EE=; b=NNKLsqcrhT5xj/FhxW3dRVeTbFLxSLwAos04sE4x198iwbUA3M14NWudwa5a6y+mrS LYlkhnVoZSUvEl3NNucH82lXdwZZ8xRLC369MPoRUgdYKifni6yMZeVzXYtt4BIejya8 DHDpthS91wqbcsCtm1NCWC7+6Y8q5reo/XICKKDZfqRiKiYkL5Kj4PwaIldJA9v/SiaU ajhjXlRC+MAMlDV6NMyDY1Haiu9tf/hu5y5rtMguVUGEyJZFpnqfNuAYR8Dhy85vk5+S ZHB+6eRk0mIrvMIj/yQ8u+qog4mJc6AnpTztlbCTYV4X/6fts8MDJl9F1XjWg1uqEVrU ovHA== X-Gm-Message-State: AFeK/H2EMmeyx8lYdhPONfZdq/MLwrNhHp0HDVd6A7rlMd4yxtJtuABarq/b1r9mEx0KzRI3D0J1bXqkI3du9g== X-Received: by 10.200.43.149 with SMTP id m21mr28537222qtm.102.1490705333238; Tue, 28 Mar 2017 05:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.161.162 with HTTP; Tue, 28 Mar 2017 05:48:52 -0700 (PDT) In-Reply-To: <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> From: Luca Muscariello Date: Tue, 28 Mar 2017 14:48:52 +0200 Message-ID: To: "Bless, Roland (TM)" Cc: Fred Baker , Jonathan Morton , tsvwg IETF list , Bob Briscoe , "De Schepper, Koen (Koen)" , Rong Pan , Greg White , AQM IETF list , Preethi Natarajan Content-Type: multipart/alternative; boundary=001a113778c6da4624054bc9e194 Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 12:48:56 -0000 --001a113778c6da4624054bc9e194 Content-Type: text/plain; charset=UTF-8 Work conserving is supposed to be referring to the scheduler. I'm not familiar with work-conservation when it refers to active queue management. I'm not sure it is actually defined. I can understand that an AQM can produce under utilization of the link, but that is different to work conservation. Or is it maybe more subtle than that? Luca On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) wrote: > Hi, > > Am 28.03.2017 um 13:39 schrieb Fred Baker: > > > I'm not convinced I understand the definitions of "work conserving" > > and "non work conserving" in this context. A "work conserving" > > scheduling algorithm keeps an interface transmitting as long as there > > is data in the queue, while a non-work-conserving algorithm reduces > > the effective rate of the interface by spacing packets out. > > +1 (that's also the definition I use, so I'm lost here too) > > Regards, > Roland > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --001a113778c6da4624054bc9e194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Work conserving is supposed to be referring to the schedul= er.
I'm not familiar with work-conservation when it refers to activ= e queue management.
I'm not sure it is actually defined.

I can understand that an AQM can produce under utiliza= tion of the link, but that is=C2=A0
different to work conservatio= n. Or is it maybe more subtle than that?
=C2=A0
Luca

On Tue, Mar 28, = 2017 at 1:48 PM, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conse= rving"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out.

+1 (that's also the definition I use, so I'm lost here too)<= br>
Regards,
=C2=A0Roland

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

--001a113778c6da4624054bc9e194-- From nobody Tue Mar 28 07:17:26 2017 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 2E20B129882; Tue, 28 Mar 2017 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PLeTdAL2y6fP; Tue, 28 Mar 2017 07:17:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D03E1296B5; Tue, 28 Mar 2017 07:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6961; q=dns/txt; s=iport; t=1490710641; x=1491920241; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YEfu8YVFN1Ldic9WJ1eNB5nWe+O5xRB5Vyl0Fi+ikFQ=; b=T5F/9XH6luWjfYxqA0hDkALZtzQ/9e+FkPOf685rHPD0qb0GqHR0CTwQ HU4/jWCcPg+U5gXx0/QENYeeH2LkUcXee1H4H0ZeLqlp8DeaWZetZKbYI 3q9Jyv3gXyd9PtTjV4ThjaO+dvoHSKC8H15BZXyA0Wve7YPRBcieYS+qF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AACAb9pY/5JdJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweNapFRiBeIBIUxgg4fAQqFeAKDIT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBbAsFCwIBCBEDAQIoByEGCxQJCAIEDgWJbwMNCA6ufoczD?= =?us-ascii?q?YMLAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGToRvglGCI4VFBZAijAQ6AY4WhDi?= =?us-ascii?q?RM4pviHoBHzg+RlkVQYQfgXw9dYhggQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,236,1486425600"; d="scan'208,217";a="400274002" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 14:17:20 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2SEHKf3029396 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 14:17:20 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 09:17:19 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Tue, 28 Mar 2017 09:17:19 -0500 From: "Rong Pan (ropan)" To: Luca Muscariello , "Bless, Roland (TM)" CC: Fred Baker , Jonathan Morton , tsvwg IETF list , Bob Briscoe , "De Schepper, Koen (Koen)" , Greg White , "AQM IETF list" , Preethi Natarajan Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqAgACcnACAAFemgIAAArAAgAAQ0AD//9WnAA== Date: Tue, 28 Mar 2017 14:17:19 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.35.73] Content-Type: multipart/alternative; boundary="_000_D4FFE7E32655Bropanciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 28 Mar 2017 14:17:24 -0000 --_000_D4FFE7E32655Bropanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for causing the confusion in choosing the word "work-conserving". If = we apply AQM and can not achieving 100% line rate, i.e. losing throughput, = it is a big No No. Since we are dealing with TCP traffic, excess drops can = cause TCP to back off too much and under-utilize the link. Rong From: Luca Muscariello > Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" = > Cc: Fred Baker >,= Jonathan Morton >, tsv= wg IETF list >, Bob Briscoe >, "De Schepper, Koen (Koen)" >, Rong Pan >, Greg White >, AQM IETF list = >, Preethi Natarajan > Subject: Re: [aqm] Questioning each PIE heuristic Work conserving is supposed to be referring to the scheduler. I'm not familiar with work-conservation when it refers to active queue mana= gement. I'm not sure it is actually defined. I can understand that an AQM can produce under utilization of the link, but= that is different to work conservation. Or is it maybe more subtle than that? Luca On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) > wrote: Hi, Am 28.03.2017 um 13:39 schrieb Fred Baker: > I'm not convinced I understand the definitions of "work conserving" > and "non work conserving" in this context. A "work conserving" > scheduling algorithm keeps an interface transmitting as long as there > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out. +1 (that's also the definition I use, so I'm lost here too) Regards, Roland _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm --_000_D4FFE7E32655Bropanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Sorry for causing the confusion in choosing the word “work-conse= rving". If we apply AQM and can not achieving 100% line rate, i.e. los= ing throughput, it is a big No No. Since we are dealing with TCP traffic, e= xcess drops can cause TCP to back off too much and under-utilize the link.

Rong

From: Luca Muscariello <luca.muscariello@gmail.com> Date: Tuesday, March 28, 2017 at 8:= 48 AM
To: "Bless, Roland (TM)" = <roland.bless@kit.edu> Cc: Fred Baker <fredbaker.ietf@gmail.com>, Jonathan Mort= on <chromatix99@gmail.com&g= t;, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net= >, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>= , AQM IETF list <aqm@ietf.org>, P= reethi Natarajan <prenatar@cisco.c= om>
Subject: Re: [aqm] Questioning each= PIE heuristic

Work conserving is supposed to be referring to the schedul= er.
I'm not familiar with work-conservation when it refers to active queue= management.
I'm not sure it is actually defined.

I can understand that an AQM can produce under utilization of the link= , but that is 
different to work conservation. Or is it maybe more subtle than that?<= /div>
 
Luca

On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (= TM) <roland.bless@= kit.edu> wrote:
Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conservin= g"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out.

+1 (that's also the definition I use, so I'm lost here too)

Regards,
 Roland

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

--_000_D4FFE7E32655Bropanciscocom_-- From nobody Tue Mar 28 14:58:02 2017 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 8959E129684 for ; Tue, 28 Mar 2017 14:58:00 -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 ZnmZJ7KTWup9 for ; Tue, 28 Mar 2017 14:57:59 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 00F0D129991 for ; Tue, 28 Mar 2017 14:57:58 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d191so63295053ywe.2 for ; Tue, 28 Mar 2017 14:57:58 -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=la1F3/rtU1/SIPE2ZFinEdJAoQd4wGx/mMl2K6Rwc4U=; b=qlU4n9VpwHx7ni+SHTg1bMn6FhEddN/HXLMbsC6HLUjZRtlv4zpUtDzrBR9UsypkJJ sWJUK0NhX3Q0I6UIKnA80QJh1IiZ8gy/6M9LgyrloMW+eevd5OxHk0Fnbqy3gTBobilh ZDg/7f6qnpoJH2osZUcjSfo8gDIghiX/zyAM2KB02K5UsgkkHmjCxqhj6ZEscNk/n7pR o8ybv2MXcWB6fgA6uBTjC0fjPOuANFaq01wNt7o9pP3+VF1Bh1emTWfZHTV8H2wxm7Ag HprI8YFTnrUBNKhI5FMOZZbb7yeorOk3DgIwopSi8igWQyl1lZd9VhQJW+rUBNz5Ld25 Z6Eg== 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=la1F3/rtU1/SIPE2ZFinEdJAoQd4wGx/mMl2K6Rwc4U=; b=ugNPlLQH3I0/DwHN8g6mqJhV+Ig9z/tMZ1/8scrkvKHaZSudzbC+j3jGryzYtvo7mw nqZ4C+nM0EHW2FVoq1YlmX34Rl9Un8CQA/GgvEAjP/QzhF8B3YB48fspkkIggCBTo0+e S0qg3jcdoU9bZRiCY3XqHcsFaQHhc8W4pCJ3kEqSrgPoouLt82+dW37HlWEQBc+hE90n 9TASSNsVCR7ktpg6khaS51D9CxlS92w78aiIGRke0Wma+vzavFnhFpqqNLTvYNsDCFhP 0yke1cdzMWIKlY4cqVDGboJN7yXX1+N1mLjwL5T4cgqxzb4l/lXyqratJIS9NDUmQjZo o7QQ== X-Gm-Message-State: AFeK/H30+ubJysiuuUzBajauOQW9+eft/8QQ8c2APbBxdeECwd1RWfEOamNaY/ldOFsvNHqBJPjpGtKNPYr7fQ== X-Received: by 10.129.164.149 with SMTP id b143mr22973764ywh.347.1490738277913; Tue, 28 Mar 2017 14:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Tue, 28 Mar 2017 14:57:57 -0700 (PDT) From: Spencer Dawkins at IETF Date: Tue, 28 Mar 2017 16:57:57 -0500 Message-ID: To: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c128d488238b7054bd18dc5 Archived-At: Subject: [tsvwg] 3GPP cutoff dates for 5G 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, 28 Mar 2017 21:58:00 -0000 --94eb2c128d488238b7054bd18dc5 Content-Type: text/plain; charset=UTF-8 During the TSVWG session yesterday, Wes said he was curious about 3GPP cutoff dates for 5G. I spoke with Georg Mayer, who is the CT chair in 3GPP, and is conveniently attending IETF 98 :-) ... The study period for 5G ends in mid-2018. Georg is cc: on this e-mail, in case I got anything wrong, because that matters. Thanks, all. Spencer --94eb2c128d488238b7054bd18dc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
During the TSVWG session yesterday, Wes said he was curiou= s about 3GPP cutoff dates for 5G.=C2=A0

I spoke with Geo= rg Mayer, who is the CT chair in 3GPP, and is conveniently attending IETF 9= 8 :-) ...

The study period for 5G ends in mid-2018= .

Georg is cc: on this e-mail, in case I got anyth= ing wrong, because that matters.

Thanks, all.

Spencer
--94eb2c128d488238b7054bd18dc5-- From nobody Tue Mar 28 15:02:21 2017 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 736AB1299FA for ; Tue, 28 Mar 2017 15:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2_B2L1fb_88c for ; Tue, 28 Mar 2017 15:02:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B8D36129A2F for ; Tue, 28 Mar 2017 15:02:15 -0700 (PDT) X-AuditID: c1b4fb2d-64c6598000005be8-eb-58dadd65453c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 09.BE.23528.56DDAD85; Wed, 29 Mar 2017 00:02:14 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 29 Mar 2017 00:02:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bqfq2ydbNiSc5Fcbb8cYGNI7F2RI9kO644n/jNmWVAk=; b=CXsIjY11hnWF4gN+5KGJaonXbUIqP9pCoQnuuFn1AZNW4VhQ36yQbUpw6C9GgfGViFa4iFNg1rAzKhM7cxVsboVpdS2XXTjhHONDWhMLgQ6d/wR4x8ez7pM6fy/cSsHkQ/34PZF0JxDRXnzNThYZBGZFpV6a28zU/zHrhdIJMHA= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 22:02:07 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.010; Tue, 28 Mar 2017 22:02:06 +0000 From: Ingemar Johansson S To: Bob Briscoe CC: Wesley Eddy , "De Schepper, Koen (Nokia - BE/Antwerp)" , marcelo bagnulo braun , tsvwg IETF list Thread-Topic: Milestones for L4S work in TSVWG Thread-Index: AQHSpv1M62znacwQ00CA4FLXwfXE3aGqy+Hw Date: Tue, 28 Mar 2017 22:02:05 +0000 Message-ID: References: <261f2bc5-8083-316d-f205-411548c7886f@mti-systems.com> <0a836ed7-7e56-5317-711b-2586af26bd6a@bobbriscoe.net> <070d08c0-51d2-4fe2-0522-4772adf7cb1e@mti-systems.com> <218817b8-53c0-7d6f-54b3-ef6d4df84fb7@bobbriscoe.net> <91ebe46d-3206-eeab-01fe-66c6d7cf1b7d@mti-systems.com> <9dc5409e-e7b3-def4-94fe-4d4a13a61326@bobbriscoe.net> <3773e2b6-fea3-70dd-63c1-910a993690f3@mti-systems.com> <83f5810e-9c54-859e-11b1-51079a50e8b7@bobbriscoe.net> In-Reply-To: <83f5810e-9c54-859e-11b1-51079a50e8b7@bobbriscoe.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [31.133.138.190] x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:52IMe8kUkovEkll0R2ZLi0HTTk5nyDjlVYoSs7Ga5IZcdhLetL4GXz1BgMRaHQnwxRRKs5qd6OjVa6F895xxMLs+IkZaPZlXAu5ln2w/xPgPqgksytzFtgO6T/3aMBB8VVMrNX6e/0uCmaJxMLv44KzBpe/c3zxtQkHkILyLJD4jCYqeGiIAwQZbTEXXi+Zxd8UV8ur6eJCw52bT95aG9WxRNqRWO46BRkkBI9GUUP1oBh4IvizR3kSDdCOFFmep3IqnEL+XRwqyXnkRnrEkONSlT+JUsY8k6cwH8J5EuuMJJqTY2grQoiWPymarPzL6tfzwI5gAwVEOci8Prcedtw== x-ms-office365-filtering-correlation-id: c6b90507-7d99-4887-64b0-08d47626133e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423066)(201703031133072)(201702281549066); SRVR:DB4PR07MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040441)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(201703131423066)(201703061421066)(201703161042066)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(6042181); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB347; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(6436002)(6506006)(77096006)(110136004)(7696004)(6246003)(229853002)(38730400002)(53376002)(2900100001)(4326008)(2950100002)(54906002)(66066001)(6916009)(55016002)(53936002)(6306002)(966004)(33656002)(9686003)(99286003)(74316002)(3280700002)(5660300001)(122556002)(6116002)(189998001)(2906002)(8936002)(8676002)(81166006)(3660700001)(102836003)(76176999)(25786009)(54356999)(53546009)(50986999)(3846002)(305945005)(7736002)(86362001)(93886004)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 22:02:05.7585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjm27nsuJx8muKbWdHKH1ZekxgpakmxP0n9G5LW0OOF5qVzTNKQ 1LRIMYrU0Lwsm5qz5oVJklloJSqmUt5aTh1qqI2CMC2LbNtZ0L/nfZ7ne94LH0O4aSkvJiUt k+XSVGoZLSErlU+j/RJNRmXgj1mJ/I1ZQ8n71xtE8qIlHS3vt5ho+dSGOJJSrM6NUQqt9qdI sT7VTikGh0ppRcF6PX2aipGEJbDqlCyWCwg/L0l+sqAVZxhcLs99N4nzUKFLMXJiAIeAdt1C FCMJ44ZbEcwY74qFYgBBocZA2woSlxIwUbWMBKVCBB8ta7RQ9CMwV+hEtjAah0Fz34bVxTDu 2Aeab+y3eQhbVMFSPrJ5tmM/+Pa1lbZhd+wPIzVrpICD4fdKhZ0nrW8neubtfimOgYHOGkpo tkaBxdJkNznh4/B6s83eGOFdMLcxaw8isCcYF+tEwnYYtM9HCQF7wMrCH3sQwpUIel7qkSDI 4JHeQtoEwCUEPLQYHMIpqCtbcQi3EHwoNjqiUuD68Bf7noCPQu1wrECPi2BkKVfA3tDwqoZ2 hFIwWW4ihP29wDR+03ELb1ie6aFuI9+q/yavssYS2BdanwUI9F4oKzGLq+zXcIXBykVSg0gd 8uBZnk9NCj7sz3Ip8TyfnuafxmZ2IOvf6TX88utCLZ+P9SHMIJmzVKM1Kt0oVRafndqHgCFk 7tLNaislTVBl57Bc+jnukprl+9BOhpR5SiNfjCndcJIqk73Ashks908VMU5eeWiPS4c4p2U2 enpVry7w8VC63okiYhvTzUXzV/xz9e8Plk/H1e+LPzTUWVrb+07tpNdFhmwjIqKC2keXH3en 3m9rUq15Zr7N2xFquFgWwW2V+m5dPUFwFebdlLPm2tbmZO7E8tlPoxu94urQ7riTZ9rzAzvu DfY0ikKXwl2OPOhKlJF8siroAMHxqr/yVcMnNwMAAA== Archived-At: Subject: Re: [tsvwg] Milestones for L4S work in TSVWG 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, 28 Mar 2017 22:02:19 -0000 SGkNCg0KQ3VycmVudGx5IHRoZSBzdGFuZGFyZHMgYmFja2xvZyBmb3IgNUcgc2VlbXMgdG8gYmUg cXVpdGUgcGFja2VkIHdpdGggd29yayBpdGVtcyBzbyBpdCBpcyBkaWZmaWN1bHQgdG8gc2F5IHdo ZXJlIEw0UyBmaXRzIGluLiBUbyBhIGxhcmdlIGV4dGVudCB0aGlzIGRlcGVuZHMgb24gbWFya2V0 IGludGVyZXN0LiANCkkgdHJpZWQgdG8gZ2V0IGEgY2xlYXIgaW5kaWNhdGlvbiBidXQgY3VycmVu dGx5IEkgY2Fubm90IGdpdmUgYW55IGNsZWFyIGFuc3dlciB0byB0aGlzLg0KDQovSW5nZW1hciAN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCb2IgQnJpc2NvZSBbbWFp bHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQo+IFNlbnQ6IGRlbiAyNyBtYXJzIDIwMTcgMTU6MjMN Cj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPg0KPiBDYzogV2VzbGV5IEVkZHkgPHdlc0BtdGktc3lzdGVtcy5jb20+OyBEZSBTY2hlcHBl ciwgS29lbiAoTm9raWEgLQ0KPiBCRS9BbnR3ZXJwKSA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1i ZWxsLWxhYnMuY29tPjsgbWFyY2VsbyBiYWdudWxvDQo+IGJyYXVuIDxtYXJjZWxvQGl0LnVjM20u ZXM+OyB0c3Z3ZyBJRVRGIGxpc3QgPHRzdndnQGlldGYub3JnPg0KPiBTdWJqZWN0OiBNaWxlc3Rv bmVzIGZvciBMNFMgd29yayBpbiBUU1ZXRw0KPiANCj4gSW5nZW1hciwNCj4gDQo+IFdlcyBoYXMg YmVlbiBhc2tpbmcgd2hhdCBhcmUgc2Vuc2libGUgbWlsZXN0b25lcyBmb3IgdGhlIEw0UyB3b3Jr IGluDQo+IFRTVldHLg0KPiBJdCBvY2N1cnJlZCB0byBtZSB0aGF0IHRoZXJlIG1pZ2h0IGJlIGEg cGFydGljdWxhcmx5IGltcG9ydGFudCBkZWFkbGluZSBpbiB0aGUNCj4gM0dQUCdzIHJlbGVhc2Ug c2NoZWR1bGUgZm9yIGludHJvZHVjaW5nIG5ldyBxdWV1ZSBtYW5hZ2VtZW50IHRlY2hub2xvZ3kN Cj4gaW50byBlTm9kZUIncy4NCj4gDQo+IENhbiB5b3UgKG9yIGFueSBvdGhlciAzR1BQLXNhdnZ5 IHBlcnNvbiBvbiB0aGlzIGxpc3QpIHBvaW50IHVzIGF0IHdoZXJlIHRoaXMNCj4gc2NoZWR1bGUg aXMsIGlmIGl0J3MgcHVibGljPyBBbmQgaWYgbmVjZXNzYXJ5IGludGVycHJldCB0aGUgc2lnbmlm aWNhbmNlIG9mIGFueQ0KPiBzdGFnZXMuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IA0KPiBCb2INCj4g DQo+IC0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gX19fX19fDQo+IEJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K From nobody Wed Mar 29 00:26:15 2017 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 1C46A12968F; Wed, 29 Mar 2017 00:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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=bobbriscoe.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 bbtCcDDboyU5; Wed, 29 Mar 2017 00:26:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 7957D128B4E; Wed, 29 Mar 2017 00:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Cc:From:References:To:Subject: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=mbaxm6qX/RWhN04q2VeBjZCwkq0hGPdfc+ukib4DEE8=; b=NsiuoZ69YOOhfwBPQYk3gUzhJf HT/H8TgbaUpZx7hJNZFSqks4mBDhbMZG3juJMZW/jqrm2zYzkdoB2sWmbsVwBpCWWOmgHs/uw9lxR ZIzsuknfCOIA/Nn8ikEcidQU0MnwDfbq/BSJo08w2ElKOhT2s5jzqVYwW71B8YW5co/Zxe1ftCD2h RldJTNRkDykl6sIXtH6u2R/mP+Q1g1l7EaI5aIQ/7mzBxAgKpok8JvK9rTCa2xB2FEqg8qwto3tuW SQNOESvCAgRjiVmuvsmdlRn7OZcCYdQUSNbt5xXzo0x0YtZyHXW/eW8yZ3uiV+33W4ucflMhF+EHa bAtrdrpg==; Received: from [77.40.143.110] (port=55824 helo=[172.31.98.93]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ct7zX-0003Q6-8t; Wed, 29 Mar 2017 08:26:03 +0100 To: Dave Dolson References: <20160722110102.5697618.36413.99476@sandvine.com> From: Bob Briscoe Cc: TCP Prague List , tsvwg IETF list Message-ID: <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> Date: Wed, 29 Mar 2017 08:26:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20160722110102.5697618.36413.99476@sandvine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] [tcpPrague] Treatment of ECT(1) pre L4S 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, 29 Mar 2017 07:26:08 -0000 Dave, I've cc'd this to tsvwg. We will put text in the ecn-l4s-id draft unless there is not consensus from others about this yet. I agree with Koen now. To be clear, I believe that a classic AQM supporting only RFC3168 (Classic) ECN: * should never alter the ECT(1) field * should be configurable between the following two behaviours: - [default] treat ECT(1) as if it does not support ECN, so drop where it would have marked CE - treat ECT(1) as if it is ECT(0) I am less keen than Koen on adding the latter option - I prefer clear simple advice to avoid confusion. So IMO, if you don't want another config knob, it would be OK to just support the default. Ideally, once the DualQ specs are approved, the AQM should also be upgraded to support Dual Qs and the squared relationship between them. Sorry it's taken so long to confirm this. Cheers Bob On 22/07/16 12:01, Dave Dolson wrote: > If an operator were to deploy ECN today, pre L4S, what should be the treatment of ECT(1)? > > I believe, from a discussion with Koen, that the safest approach is for a pre-L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) were treated the same as ECT(0) then new experimental TCP-Prague flows would out-compete any ECT(0) traffic. > > Is this agreed? If so, should it be recommended somewhere? > > Note that I got mixed answers on this from other IETF folks, so I think it is worth sorting out. > > > -Dave > > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Mar 29 07:40:55 2017 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 B0D051242EA; Wed, 29 Mar 2017 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=ericsson.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 imHc6URK8OBZ; Wed, 29 Mar 2017 07:40:51 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F29B8127599; Wed, 29 Mar 2017 07:40:50 -0700 (PDT) X-AuditID: c1b4fb30-7db199800000628e-01-58dbc77017f3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 5A.45.25230.077CBD85; Wed, 29 Mar 2017 16:40:49 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 29 Mar 2017 16:40:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nuG2gI7wVUeGmZDqfYcgbmaL/EsCKYk62NuT3wQlTn8=; b=Zb5mpInRbZeu3Nfzco2c6fOVIfl6FDNFoAvdcWtsS5ZhJJ75jSgY+bs5XUffDZ6p0yLEo4OOEQUa5S0a8akxPYfLHuIn7cVxPpUS+HK9FYL93FnTvHl7fWCcu04Z1MFFxkc3inLU2yIWrCx2P334Y98b/bfqZrs2udRsV29O3bE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 14:40:16 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 14:40:15 +0000 From: Ingemar Johansson S To: tsvwg IETF list , "'tcpprague@ietf.org'" CC: Ingemar Johansson S Thread-Topic: 3GPP RAN2 : On TCP-specific improvements in the RAN Thread-Index: AdKomZzG9owUdRY+R4GVnm5sf8r/Tg== Date: Wed, 29 Mar 2017 14:40:15 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.93] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:8L8I7y6FrJqX3obtPp+gF+mMmBkqsbMmE3GNXZ/C6CclNg7eM1Tz/gukqlGMF6GtEdWhekTFa+F4pOw/vxzyd3hF+OzLFO14a2vok2PXued2EM5T3TYyFIxMJxBchnMwjIBwWFMQPq812UOmUbpEYfUKtXul5KtSlssxnbIjT7qz64St4/SLLYfGI331cPmPtA5RSswx2WcVFrn+qdygnYjCZe/Icj6DkuMyQIx1C/U5hCIRTodhxkJ4m/lIyjFpKe3MeyN3NJBNC80Z7mtlW8K2PXaQ/t5wRuzInkyJy+jBvmU6FsLB7LlSESF5wIR5N/3NEup7UADhj1c2Ju4PqA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(7736002)(74316002)(6436002)(38730400002)(7906003)(107886003)(33656002)(966004)(189998001)(3280700002)(66066001)(2900100001)(7696004)(3660700001)(5660300001)(8558605004)(54356999)(790700001)(6116002)(102836003)(99286003)(450100002)(2906002)(50986999)(86362001)(8676002)(19609705001)(55016002)(25786009)(77096006)(9686003)(6306002)(54896002)(8936002)(6506006)(9326002)(606005)(236005)(53936002)(122556002)(4326008)(81166006)(3846002)(491001)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: a1f5cba8-7568-4920-fae7-08d476b183ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006041)(93001041)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0261CCEEDF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 14:40:15.5716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUyM2K7vW7h8dsRBm0HeS2mNhxksTj25i6b A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyvkzuYS84nlBx4/Fn9gbGl2FdjJwcEgImEk1HZrJ3 MXJxCAmsZ5RY0H2CCcI5wShxdt4KMIdFoJdZonnhUajMNCaJfz/Xs0A4xxglHn9ayA4yjE3A RmLloe+MILaIQLDEik2PmUBsZgEriS/H/zKD2MJANSuW3GCGqHGUaPv5gwXC1pPYeakfbA6L gKrE1rObweK8AlESk5duYgWxGQVkJe5/v8cCMVNc4taT+UwQTwhILNlznhnCFpV4+fgfK8hx jALdjBIf5l0DKuIASihI3L8ZBRKXEOhmlph4YDoThHOMVeL5lkZGiG5fiWs/3kLZtRIPOhug NmRKnJ99HsqOlphyrIsNovkDk8TcDdugVstI9DdNgnpTSuLulU5GCFtG4sWdvawQZ+dL7Fw1 ixXiNUGJkzOfsExgVJuF5KNZSMpmISmDiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEFjOyr GEWLU4uTctONjPRSizKTi4vz8/TyUks2MQJTz8Etvw12ML587niIUYCDUYmH98He2xFCrIll xZW5hxglOJiVRHh/HgUK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUI JsvEwSnVwMgw1z4lyOWN0r7nJtbLb12bnv6g7/2VT9xiaqd7drE9MX++nrN5u41FDN+e5Y+m NCZ+XD1V38DmiO2yc6sfaMrFxNw/lPVQ+OyLu3zTJnD5b505++Tru01bqh+91uQV9uf7+PFs 3tFmlcIlby2uH2GZNWdPguEMle6L+VZX7zx2+dixuLo948x8JZbijERDLeai4kQA7Iy4ZzkD AAA= Archived-At: Subject: [tsvwg] 3GPP RAN2 : On TCP-specific improvements in the RAN 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, 29 Mar 2017 14:40:54 -0000 --_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi This is an input to 3GPP-RAN2 that I wrote up recently, it will be discusse= d at a 3GPP-RAN2 meeting next week. The document addresses various intentions to optimize TCP performance in 3G= PP networks. L4S is here (briefly) introduced as a generic method to optimi= ze transport protocol performance regardless it is TCP, QUIC, .. pigeon dat= agrams... To put it short, there are two main recommendations in the paper 1) 3GPP should avoid the standardization of certain TCP specific optimiz= ations such as ACK thinning 2) 3GPP should consider new low latency technologies like L4S http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_97bis/Docs/R2-1702661.zip Abstract: "There is an ongoing discussion on the merits of TCP ACK thinning= in RAN with the objective to minimize the ACK traffic, and the merits with= ACK prioritization. This input paper discusses the actual need for such fu= nctionality and the applicability in perspective of future transport protoc= ol evolution and future evolution towards low latency access technology. In= short we conclude that no TCP-specific improvements are necessary." Enjoy /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

This is an input to 3GPP-RAN2 that I wrote up recently, it will be dis= cussed at a 3GPP-RAN2 meeting next week.

The document addresses various intentions to optimize TCP performance = in 3GPP networks. L4S is here (briefly) introduced as a generic method to o= ptimize transport protocol performance regardless it is TCP, QUIC, .. pigeon datagrams…

To put it short, there are two main recommendations in the paper<= /o:p>

1)    3GPP should avoid the standardization of certain TCP specific = optimizations such as ACK thinning

2)    3GPP should consider new low latency technologies like L4S

 

 

http://www.3gpp.org/ftp/tsg_= ran/WG2_RL2/TSGR2_97bis/Docs/R2-1702661.zip

 

Abstract: “There is an ongoing discussion on the merits of TCP= ACK thinning in RAN with the objective to minimize the ACK traffic, and th= e merits with ACK prioritization. This input paper discusses the actual need for such functionality and the applicability in perspectiv= e of future transport protocol evolution and future evolution towards low l= atency access technology. In short we conclude that no TCP-specific improve= ments are necessary.”

Enjoy

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake= is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348F4399FB43B38286680C1C2350DB4PR07MB348eurprd_-- From wolfram.lautenschlaeger@nokia-bell-labs.com Tue Mar 28 23:30:10 2017 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 9DD3D129684; Tue, 28 Mar 2017 23:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=nokia.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 j2O_Q9rCRGLQ; Tue, 28 Mar 2017 23:30:06 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0125.outbound.protection.outlook.com [104.47.2.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394AB127601; Tue, 28 Mar 2017 23:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YDttaeAigfRNag3zH2kpXIUPg6pecN5DDYgvmpPADAg=; b=IHCt0Lby4jn4vQE9KEr4pEdGBQgMVhUlLSLiBlR0wwqlUvZCy0FpKo2JZOMtc46HQe3fkKQOkkapA/JkItwtHB/YOoVUPx1W8l/lYIqU8AE15m2ekeoS4wzRZofJAl48Ms7fgRJ1TBK2MsGRmMh259KZRNC/5UhtMahKvatZItA= Received: from DB6PR0701MB2949.eurprd07.prod.outlook.com (10.168.84.11) by DB6PR0701MB2117.eurprd07.prod.outlook.com (10.168.58.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 06:30:01 +0000 Received: from DB6PR0701MB2949.eurprd07.prod.outlook.com ([10.168.84.11]) by DB6PR0701MB2949.eurprd07.prod.outlook.com ([10.168.84.11]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 06:30:01 +0000 From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" To: "Rong Pan (ropan)" , Luca Muscariello , "Bless, Roland (TM)" CC: tsvwg IETF list , Fred Baker , Bob Briscoe , "De Schepper, Koen (Nokia - BE/Antwerp)" , Greg White , Jonathan Morton , AQM IETF list , Preethi Natarajan Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHCPmUgFXrIeUydGegAQAXKAKGpdjyAgABZiACAAFengIAAArAAgAAQzwCAABi2gIABDPPg Date: Wed, 29 Mar 2017 06:30:00 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.11] x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2117; 7:34nmCP3Sq6l6dvmL3IglD0K5zPJMfRHqZ7ZTcjQcK6Iw+rptP+a4umXyCZkJ+hb0nTNB8oBhEante78peLuL+4wjVfWmKHhe13kUo3xs+mreh1wcW6LhJ/htYC/V9MBnRP3FnNkhbHAmG1wQg14YwlhmkJ7EXQ+RFCkQQa1iXAkozzwA2JqPcVKebulm1teq7+q9qtKrYrP9PCQiU9DgU5VI1iGn82zZ3vKKPbdThCMkcZTq2gU1aWsSeXsu3VCHtoayRe2HUZ5ZGIZAT+KDNOstUJB1efMFlU+Fd6ICmYQ41ojhtJExx4ngxyCXO3HOyLykjvOlqMqYuEbWz8yinw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(24454002)(377454003)(6436002)(39060400002)(606005)(8676002)(38730400002)(7696004)(77096006)(5660300001)(189998001)(81166006)(4326008)(6506006)(8936002)(54906002)(53936002)(7906003)(2900100001)(229853002)(7416002)(6116002)(54896002)(7736002)(55016002)(99286003)(53546009)(19609705001)(2950100002)(25786009)(6306002)(236005)(790700001)(3846002)(74316002)(102836003)(6246003)(9686003)(122556002)(33656002)(93886004)(3280700002)(2906002)(86362001)(2171002)(3660700001)(66066001)(50986999)(54356999)(76176999)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2117; H:DB6PR0701MB2949.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: e27e70c7-a4db-46bd-9d12-08d4766d0740 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423072)(201703031133078); SRVR:DB6PR0701MB2117; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040447)(601004)(2401047)(8121501046)(5005006)(93006041)(93001041)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423072)(201702281528072)(201703061421072)(201703061406072)(6072148); SRVR:DB6PR0701MB2117; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2117; x-forefront-prvs: 0261CCEEDF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 06:30:00.8167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2117 Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 07:44:25 -0700 Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 29 Mar 2017 06:31:41 -0000 --_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To my understanding a proper operating AQM _is_ work-conserving. Packet dro= ps occur, if any, when a reasonable queue is present. And as long as packet= s are present in the queue, the link runs at 100%. I cannot see any (AQM) m= echanism that is holding back queued packets while the link is idle. Wolfram From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan) Sent: Dienstag, 28. M=E4rz 2017 16:17 To: Luca Muscariello ; Bless, Roland (TM) Cc: tsvwg IETF list ; Fred Baker = ; Bob Briscoe ; De Schepper, Koen (Nokia - BE/Antwerp)= ; Greg White = ; Jonathan Morton ; AQM IETF list ; Pr= eethi Natarajan Subject: Re: [aqm] Questioning each PIE heuristic Sorry for causing the confusion in choosing the word "work-conserving". If = we apply AQM and can not achieving 100% line rate, i.e. losing throughput, = it is a big No No. Since we are dealing with TCP traffic, excess drops can = cause TCP to back off too much and under-utilize the link. Rong From: Luca Muscariello > Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" = > Cc: Fred Baker >,= Jonathan Morton >, tsv= wg IETF list >, Bob Briscoe >, "De Schepper, Koen (Koen)" >, Rong Pan >, Greg White >, AQM IETF list = >, Preethi Natarajan > Subject: Re: [aqm] Questioning each PIE heuristic Work conserving is supposed to be referring to the scheduler. I'm not familiar with work-conservation when it refers to active queue mana= gement. I'm not sure it is actually defined. I can understand that an AQM can produce under utilization of the link, but= that is different to work conservation. Or is it maybe more subtle than that? Luca On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) > wrote: Hi, Am 28.03.2017 um 13:39 schrieb Fred Baker: > I'm not convinced I understand the definitions of "work conserving" > and "non work conserving" in this context. A "work conserving" > scheduling algorithm keeps an interface transmitting as long as there > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out. +1 (that's also the definition I use, so I'm lost here too) Regards, Roland _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm --_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To my understanding a proper operatin= g AQM _is_ work-conserving. Packet drops occur, if any, when a reaso= nable queue is present. And as long as packets are present in the queue, the link runs at 100%. I cannot see any (AQM) me= chanism that is holding back queued packets while the link is idle.

 

Wolfram

 

 

From: aqm [mailto:aqm-bounces@ietf.o= rg] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. M=E4rz 2017 16:17
To: Luca Muscariello <luca.muscariello@gmail.com>; Bless, Rola= nd (TM) <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>; Fred Baker <fredbaker= .ietf@gmail.com>; Bob Briscoe <ietf@bobbriscoe.net>; De Schepper, = Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>; Gre= g White <g.white@cablelabs.com>; Jonathan Morton <chromatix99@gmai= l.com>; AQM IETF list <aqm@ietf.org>; Preethi Natarajan <prenatar@cisco.c= om>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Sorry for causing the confusion in choo= sing the word “work-conserving". If we apply AQM and can not ach= ieving 100% line rate, i.e. losing throughput, it is a big No No. Since we are dealing with TCP traffic, excess drops can cause TCP t= o back off too much and under-utilize the link.

 

Rong

 

From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredb= aker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, &q= uot;De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Work conserving is supposed to be refer= ring to the scheduler.

I'm not familiar with work-conservation= when it refers to active queue management.

I'm not sure it is actually defined.

 

I can understand that an AQM can produc= e under utilization of the link, but that is 

different to work conservation. Or is i= t maybe more subtle than that?

 

Luca

 

On Tue, Mar 28, 2017 at 1:48 PM, Bless,= Roland (TM) <= roland.bless@kit.edu> wrote:

Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conservin= g"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out.

+1 (that's also the definition I use, so I'm lost here too)

Regards,
 Roland


_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

 

--_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_-- From nobody Wed Mar 29 09:21:56 2017 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 4FB6E12943A for ; Wed, 29 Mar 2017 09:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Xg5vucdGdZUa for ; Wed, 29 Mar 2017 09:21:53 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 AA3B112940A for ; Wed, 29 Mar 2017 09:21:52 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d191so14309081ywe.2 for ; Wed, 29 Mar 2017 09:21:52 -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; bh=s4tGJsSpYbvSHq2++5iFOaDovpLpF9JYg9hgXk6q+Qg=; b=HBSt9ayplOAvsFuPTDpwDBuK7G76KvU5KeCotBt5xyU3jgwTPAgf7rzRxqG28ug3jm ZlVwZ+LpWPA7TS0uVgPLJWLjU3ch65uFvm626zdCJo6JAkrqg5mKOT6hydyA5O/JHCAP d8LSdWUMUOLA1tBzy1PS8yTIs9GEadKEPpbTwYlqSWZaQqYIyVfPTApaKuUh552UMHb0 6XoqnuN7ZFbBzqha4IibXp++HgSK/QAzCjOjuTrFR5aSaN6MXYXdXsSN4GtZnoxNCJvj WNvzHsFAhc8gSxUYV0iLVzPRk5Ugs05nH4xSEk2WfXcFrco3Zk+wm7TgmQeaOg2sHFJg vsBw== 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; bh=s4tGJsSpYbvSHq2++5iFOaDovpLpF9JYg9hgXk6q+Qg=; b=M0YVordkev2hEEohmga3HFnNnSTDd3FPwEKpClSlYqKSuZ8sleGIwvo0KXWscnxgke geOfVKCB+MvQX1ZBqasiWUJqlMbmM+q1/pG23sJRCVjwO57Fv+rqTdoLJZaqx6u2sKNH eHunc9P8xxifsc7TYpkczKYgjpjfi7ymfwOEsAqY57GNwLNtwIH8NmxCpDjTFWRAgVxc gPxhJTtzcjnwYC3/jWwbPCw8MHJUtMcZ2ACNEaWxpWeB1CLHOzF14MK+/sh3o6RpalcX NJfalLXmmhO0tgzgmy6jE19VUfNLbMlIgIO4ODEbHJ+CdwDvT26wwGE7O9GNYzWj4s7F kniA== X-Gm-Message-State: AFeK/H2t26YxJOJ2DvuZoPDVBuWqVo8GSiD1qMSXFcaF5JRXi5H6teB4Q0q4v1NFv/jYOopn0hKOcPilPLDURA== X-Received: by 10.13.235.151 with SMTP id u145mr1094137ywe.19.1490804511646; Wed, 29 Mar 2017 09:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 29 Mar 2017 09:21:51 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Wed, 29 Mar 2017 11:21:51 -0500 Message-ID: To: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c06c39058e64a054be0f900 Archived-At: Subject: Re: [tsvwg] 3GPP cutoff dates for 5G 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, 29 Mar 2017 16:21:54 -0000 --94eb2c06c39058e64a054be0f900 Content-Type: text/plain; charset=UTF-8 Dear TSVWG, On Tue, Mar 28, 2017 at 4:57 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > During the TSVWG session yesterday, Wes said he was curious about 3GPP > cutoff dates for 5G. > > I spoke with Georg Mayer, who is the CT chair in 3GPP, and is conveniently > attending IETF 98 :-) ... > > The study period for 5G ends in mid-2018. > > Georg is cc: on this e-mail, in case I got anything wrong, because that > matters. > > Thanks, all. > > Spencer > Something ate Georg's e-mail address on CC: of my e-mail (it's on the version in my sent mail folder, but it didn't survive all the way to the working group). Georg's e-mail address is georg.mayer.huawei@gmx.com, if there are questions about 3GPP 5G milestone dates. Thanks to Martin Dolly, for spotting his missing e-mail address and letting me know. Spencer --94eb2c06c39058e64a054be0f900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TSVWG,

On Tue, Mar 28, 2017 at 4:57 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
During the TSVWG sess= ion yesterday, Wes said he was curious about 3GPP cutoff dates for 5G.=C2= =A0

I spoke with Georg Mayer, who is the CT chair in 3GP= P, and is conveniently attending IETF 98 :-) ...

T= he study period for 5G ends in mid-2018.

Georg is = cc: on this e-mail, in case I got anything wrong, because that matters.

Thanks, all.

Spencer

Something ate Georg= 's e-mail address on CC: of my e-mail (it's on the version in my se= nt mail folder, but it didn't survive all the way to the working group)= .

Geor= g's e-mail address is=C2=A0georg.mayer.huawei@gmx.com, if there are questions about 3GPP 5G mile= stone dates.

Thanks to Martin Dolly, for spotting his missing e-mail= address and letting me know.

Spencer
--94eb2c06c39058e64a054be0f900-- From nobody Wed Mar 29 10:58:17 2017 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 517CE12025C; Wed, 29 Mar 2017 10:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hZUnD2jIif2X; Wed, 29 Mar 2017 10:58:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C9F128708; Wed, 29 Mar 2017 10:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18294; q=dns/txt; s=iport; t=1490810290; x=1492019890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b2NGVXLDIoLjYvehCEXK9Wc7BdP/LLP6hHjQm6F6rbY=; b=KKWP/0A64qz8y/NehirE3NNTPHvD6iqhgPamLbAjblqIQZGH3uxAVO0J zkZ8PllRAPIQ9YIcsMNfHYOd/3zV8F/b/0vB0rzZY3cECMnzSceFv34XA 819CTsqEcNL4y1V1YkySL7BWcYv8E5jh2tz0xGV2Jd2ZMnXYyfrLkTn6S w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQAO9NtY/4oNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuPCthgQsHjWyRUYgYiAWFMYIOHwEKhXgCg0M/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBAStBCwULAgEIEQMBAQEoByEGCxQJCAIEAQ0FiXIDDQgOs?= =?us-ascii?q?BiHJg2DHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRgiMWhS8FkCKMBDo?= =?us-ascii?q?BiiaDcYQ4kTOKb4h6AR84PkZZFUGGGz11iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,242,1486425600"; d="scan'208,217";a="8368292" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 17:58:08 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2THw9xS007196 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 17:58:09 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 12:58:08 -0500 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 12:58:08 -0500 From: "Rong Pan (ropan)" To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" , Luca Muscariello , "Bless, Roland (TM)" CC: tsvwg IETF list , Fred Baker , Bob Briscoe , "De Schepper, Koen (Nokia - BE/Antwerp)" , Greg White , Jonathan Morton , AQM IETF list , Preethi Natarajan Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqAgACcnACAAFemgIAAArAAgAAQ0AD//9WnAIABUtMAgAB9L4A= Date: Wed, 29 Mar 2017 17:58:08 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.25.27] Content-Type: multipart/alternative; boundary="_000_D5016D98265A4ropanciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 29 Mar 2017 17:58:15 -0000 --_000_D5016D98265A4ropanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are not holding back queued packets when the link is idle. We stop dropp= ing packets when the queue is shallow in order to avoid unnecessary drops t= hat could cause TCP traffic to back off and stop sending traffic that will = cause link idle. Rong From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" > Date: Wednesday, March 29, 2017 at 2:30 AM To: Rong Pan >, Luca Muscariello >, "Bless, Rola= nd (TM)" > Cc: tsvwg IETF list >, Fred Baker >, Bob Briscoe >, "De Schepper, Koen (Nokia - B= E/Antwerp)" >, Greg White >, Jonathan Morton >, AQM IETF list >, Preethi Nataraj= an > Subject: RE: [aqm] Questioning each PIE heuristic To my understanding a proper operating AQM _is_ work-conserving. Packet dro= ps occur, if any, when a reasonable queue is present. And as long as packet= s are present in the queue, the link runs at 100%. I cannot see any (AQM) m= echanism that is holding back queued packets while the link is idle. Wolfram From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan) Sent: Dienstag, 28. M=E4rz 2017 16:17 To: Luca Muscariello >; Bless, Roland (TM) > Cc: tsvwg IETF list >; Fred Baker >; Bob Briscoe >; De Schepper, Koen (Nokia - BE= /Antwerp) >; Greg White >; Jonathan Morton >; AQM IETF list >; Preethi Natarajan= > Subject: Re: [aqm] Questioning each PIE heuristic Sorry for causing the confusion in choosing the word "work-conserving". If = we apply AQM and can not achieving 100% line rate, i.e. losing throughput, = it is a big No No. Since we are dealing with TCP traffic, excess drops can = cause TCP to back off too much and under-utilize the link. Rong From: Luca Muscariello > Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" = > Cc: Fred Baker >,= Jonathan Morton >, tsv= wg IETF list >, Bob Briscoe >, "De Schepper, Koen (Koen)" >, Rong Pan >, Greg White >, AQM IETF list = >, Preethi Natarajan > Subject: Re: [aqm] Questioning each PIE heuristic Work conserving is supposed to be referring to the scheduler. I'm not familiar with work-conservation when it refers to active queue mana= gement. I'm not sure it is actually defined. I can understand that an AQM can produce under utilization of the link, but= that is different to work conservation. Or is it maybe more subtle than that? Luca On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) > wrote: Hi, Am 28.03.2017 um 13:39 schrieb Fred Baker: > I'm not convinced I understand the definitions of "work conserving" > and "non work conserving" in this context. A "work conserving" > scheduling algorithm keeps an interface transmitting as long as there > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out. +1 (that's also the definition I use, so I'm lost here too) Regards, Roland _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm --_000_D5016D98265A4ropanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1047AC109A1544499A1DA38A14D6A4F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
We are not holding back queued packets when the link is idle. We stop = dropping packets when the queue is shallow in order to avoid unnecessary dr= ops that could cause TCP traffic to back off and stop sending traffic that = will cause link idle.

Rong

From: "Lautenschlaeger, Wolfra= m (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com><= br> Date: Wednesday, March 29, 2017 at = 2:30 AM
To: Rong Pan <ropan@cisco.com>, Luca Muscariello <luca.muscariello@gmail.com>, "= ;Bless, Roland (TM)" <rolan= d.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>, Bob Brisco= e <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Greg White <g.white@cab= lelabs.com>, Jonathan Morton <chromatix99@gmail.com>, AQM IETF list <aqm@ietf.org>, Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: RE: [aqm] Questioning each= PIE heuristic

To my understanding a proper operat= ing AQM _is_ work-conserving. Packet drops occur, if any, when a rea= sonable queue is present. And as long as packets are present in the queue, the link runs at 100%. I cannot see a= ny (AQM) mechanism that is holding back queued packets while the link is id= le.

 

Wolfram

 

 

From: aqm [mai= lto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. M=E4rz 2017 16:17
To: Luca Muscariello <luca.muscariello@gmail.com>; Bless, Roland (TM) <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf= .org>; Fred Baker <fr= edbaker.ietf@gmail.com>; Bob Briscoe <ietf@bobbriscoe.net>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>; Greg White <g.white@cablelabs.com>; Jonathan M= orton <chromatix99@gmail.com>; AQM IETF list <aqm@ietf.org>; Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Sorry for causing the confusion in choosing = the word “work-conserving". If we apply AQM and can not achievin= g 100% line rate, i.e. losing throughput, it is a big No No. Since we are dealing with TCP traffic, excess drops can cause= TCP to back off too much and under-utilize the link.

 

Rong

 

From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredb= aker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, &q= uot;De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Work conserving is supposed to be referring = to the scheduler.

I'm not familiar with work-conservation when= it refers to active queue management.

I'm not sure it is actually defined.

 

I can understand that an AQM can produce und= er utilization of the link, but that is 

different to work conservation. Or is it may= be more subtle than that?

 

Luca

 

On Tue, Mar 28, 2017 at 1:48 PM, Bless, Rola= nd (TM) <rolan= d.bless@kit.edu> wrote:

Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conservin= g"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > is data in the queue, while a non-work-conserving algorithm reduces > the effective rate of the interface by spacing packets out.

+1 (that's also the definition I use, so I'm lost here too)

Regards,
 Roland


_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

 

 --_000_D5016D98265A4ropanciscocom_-- From nobody Wed Mar 29 11:08:48 2017 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 8B43F12946F for ; Wed, 29 Mar 2017 11:08:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149081092756.27569.8132970820522218199.idtracker@ietfa.amsl.com> Date: Wed, 29 Mar 2017 11:08:47 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG 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, 29 Mar 2017 18:08:47 -0000 Changed milestone "Submit 'Tunnel Congestion Feedback' as an Informational RFC", set due date to April 2017 from December 2016. Changed milestone "Submit 'SCTP New Data Chunk' as a Proposed Standard RFC", set due date to April 2017 from January 2017. Changed milestone "Submit 'A Lower Effort Per-Hop Behavior (LE PHB)' as a Proposed Standard RFC", set due date to September 2017 from May 2017. Changed milestone "Submit 'Guidelines for DiffServ to IEEE 802.11 Mapping' as an Informational RFC ", set due date to September 2017 from January 2017. Changed milestone "Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC", set due date to September 2017 from April 2017. Changed milestone "Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC", set due date to September 2017 from June 2017. Changed milestone "Submit 'SCTP NAT Support' to IESG for consideration as a PS RFC", set due date to December 2017 from April 2017. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Wed Mar 29 11:47:52 2017 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 890EA12894A; Wed, 29 Mar 2017 11:47:50 -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, 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=bobbriscoe.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 Ua11Inr4Z5k7; Wed, 29 Mar 2017 11:47:45 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C1BB612946E; Wed, 29 Mar 2017 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject: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=Gv/mTJRH6ZuS8HHIh/djMe2ZHYxdnhvCbJZ4VJCxz0k=; b=DrTxUTdTZt6tggNrPpfm+1kpH FpDVAa3LlAFBVE9MlJzqI2XK5FOqT2slXGguhDHCh6qObnAaybMUWzkjhtFTY/es1j1av85eYVZP/ OmYMFGfjK/cndk2TlJtTT/0E38tuVn2nxL/LpRFpcym2pVHUcvlpENDgHe8h2vPLZcNe8QHoaNhky aE3cy2CLqZzhtodBO4tk9BgTiQbIfN3ODL+mioncxtybxJF88JxnWp9QDT7WRJasMvu/uNDTS1gEW VJx5SSSdIZgrjOJ5cA71UJK9tyArzPE37CCxMkWKwU8Ou+YI0asWHdYUIQ3V9u2abj5jDlTeB/4Kp tYLDbku0w==; Received: from [77.88.71.158] (port=48066 helo=[172.16.5.179]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ctIdB-0000BL-9N; Wed, 29 Mar 2017 19:47:41 +0100 To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> Cc: "Rong Pan (ropan)" , Luca Muscariello , "Bless, Roland (TM)" , tsvwg IETF list , Fred Baker , "De Schepper, Koen (Nokia - BE/Antwerp)" , Greg White , Jonathan Morton , AQM IETF list , Preethi Natarajan From: Bob Briscoe Message-ID: <205cf09e-0657-f028-2485-3a415895e627@bobbriscoe.net> Date: Wed, 29 Mar 2017 19:47:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6BDEE67AE25C42B9B277A4A3" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 29 Mar 2017 18:47:51 -0000 This is a multi-part message in MIME format. --------------6BDEE67AE25C42B9B277A4A3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Wolfram, Just to explain some context. The PIE algorithm determines a dropping probability at sample times (default 16ms), then continues to drop with that probability until the next sample. If the queue had been large then traffic ends, while the queue is draining towards zero it is still dropping at the last calculated probability. So the PIE code includes a heuristic that suppresses any drop if the queue is less than half the target. Nonetheless, the PIE algo continues to calculate what the drop probability /would/ be if a queue of more than half the target appeared again. This is so that the drop probability reflects a longer running measure of the load as well as the instantaneous queue. Bob On 29/03/17 18:58, Rong Pan (ropan) wrote: > We are not holding back queued packets when the link is idle. We stop > dropping packets when the queue is shallow in order to avoid > unnecessary drops that could cause TCP traffic to back off and stop > sending traffic that will cause link idle. > > Rong > > From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" > > > Date: Wednesday, March 29, 2017 at 2:30 AM > To: Rong Pan >, Luca > Muscariello >, "Bless, Roland (TM)" > > > Cc: tsvwg IETF list >, Fred > Baker >, > Bob Briscoe >, "De > Schepper, Koen (Nokia - BE/Antwerp)" > >, Greg White > >, Jonathan > Morton >, AQM > IETF list >, Preethi Natarajan > > > Subject: RE: [aqm] Questioning each PIE heuristic > > To my understanding a proper operating AQM _/is/_ work-conserving. > Packet drops occur, if any, when a reasonable queue is present. And as > long as packets are present in the queue, the link runs at 100%. I > cannot see any (AQM) mechanism that is holding back queued packets > while the link is idle. > > Wolfram > > *From:*aqm [mailto:aqm-bounces@ietf.org] *On Behalf Of *Rong Pan (ropan) > *Sent:* Dienstag, 28. März 2017 16:17 > *To:* Luca Muscariello >; Bless, Roland (TM) > > > *Cc:* tsvwg IETF list >; Fred > Baker >; > Bob Briscoe >; De > Schepper, Koen (Nokia - BE/Antwerp) > >; Greg White > >; Jonathan > Morton >; AQM > IETF list >; Preethi Natarajan > > > *Subject:* Re: [aqm] Questioning each PIE heuristic > > Sorry for causing the confusion in choosing the word > “work-conserving". If we apply AQM and can not achieving 100% line > rate, i.e. losing throughput, it is a big No No. Since we are dealing > with TCP traffic, excess drops can cause TCP to back off too much and > under-utilize the link. > > Rong > > *From: *Luca Muscariello > > *Date: *Tuesday, March 28, 2017 at 8:48 AM > *To: *"Bless, Roland (TM)" > > *Cc: *Fred Baker >, Jonathan Morton > >, tsvwg IETF > list >, Bob Briscoe > >, "De Schepper, Koen > (Koen)" >, Rong Pan >, Greg White >, AQM IETF list >, Preethi Natarajan > > *Subject: *Re: [aqm] Questioning each PIE heuristic > > Work conserving is supposed to be referring to the scheduler. > > I'm not familiar with work-conservation when it refers to active queue > management. > > I'm not sure it is actually defined. > > I can understand that an AQM can produce under utilization of the > link, but that is > > different to work conservation. Or is it maybe more subtle than that? > > Luca > > On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) > > wrote: > > Hi, > > Am 28.03.2017 um 13:39 schrieb Fred Baker: > > > I'm not convinced I understand the definitions of "work conserving" > > and "non work conserving" in this context. A "work conserving" > > scheduling algorithm keeps an interface transmitting as long as > there > > is data in the queue, while a non-work-conserving algorithm reduces > > the effective rate of the interface by spacing packets out. > > +1 (that's also the definition I use, so I'm lost here too) > > Regards, > Roland > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------6BDEE67AE25C42B9B277A4A3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Wolfram,

Just to explain some context. The PIE algorithm determines a dropping probability at sample times (default 16ms), then continues to drop with that probability until the next sample. If the queue had been large then traffic ends, while the queue is draining towards zero it is still dropping at the last calculated probability. So the PIE code includes a heuristic that suppresses any drop if the queue is less than half the target. Nonetheless, the PIE algo continues to calculate what the drop probability /would/ be if a queue of more than half the target appeared again.

This is so that the drop probability reflects a longer running measure of the load as well as the instantaneous queue.


Bob

On 29/03/17 18:58, Rong Pan (ropan) wrote:
We are not holding back queued packets when the link is idle. We stop dropping packets when the queue is shallow in order to avoid unnecessary drops that could cause TCP traffic to back off and stop sending traffic that will cause link idle.

Rong

From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com>
Date: Wednesday, March 29, 2017 at 2:30 AM
To: Rong Pan <ropan@cisco.com>, Luca Muscariello <luca.muscariello@gmail.com>, "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Greg White <g.white@cablelabs.com>, Jonathan Morton <chromatix99@gmail.com>, AQM IETF list <aqm@ietf.org>, Preethi Natarajan <prenatar@cisco.com>
Subject: RE: [aqm] Questioning each PIE heuristic

To my understanding a proper operating AQM _is_ work-conserving. Packet drops occur, if any, when a reasonable queue is present. And as long as packets are present in the queue, the link runs at 100%. I cannot see any (AQM) mechanism that is holding back queued packets while the link is idle.

 

Wolfram

 

 

From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. März 2017 16:17
To: Luca Muscariello <luca.muscariello@gmail.com>; Bless, Roland (TM) <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>; Fred Baker <fredbaker.ietf@gmail.com>; Bob Briscoe <ietf@bobbriscoe.net>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>; Greg White <g.white@cablelabs.com>; Jonathan Morton <chromatix99@gmail.com>; AQM IETF list <aqm@ietf.org>; Preethi Natarajan <prenatar@cisco.com>
Subject: Re: [aqm] Questioning each PIE heuristic

 

Sorry for causing the confusion in choosing the word “work-conserving". If we apply AQM and can not achieving 100% line rate, i.e. losing throughput, it is a big No No. Since we are dealing with TCP traffic, excess drops can cause TCP to back off too much and under-utilize the link.

 

Rong

 

From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Preethi Natarajan <prenatar@cisco.com>
Subject: Re: [aqm] Questioning each PIE heuristic

 

Work conserving is supposed to be referring to the scheduler.

I'm not familiar with work-conservation when it refers to active queue management.

I'm not sure it is actually defined.

 

I can understand that an AQM can produce under utilization of the link, but that is 

different to work conservation. Or is it maybe more subtle than that?

 

Luca

 

On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) <roland.bless@kit.edu> wrote:

Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conserving"
> and "non work conserving" in this context. A "work conserving"
> scheduling algorithm keeps an interface transmitting as long as there
> is data in the queue, while a non-work-conserving algorithm reduces
> the effective rate of the interface by spacing packets out.

+1 (that's also the definition I use, so I'm lost here too)

Regards,
 Roland


_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------6BDEE67AE25C42B9B277A4A3-- From nobody Wed Mar 29 12:26:01 2017 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 05AB11296DE for ; Wed, 29 Mar 2017 12:26:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149081556001.27508.1849017643547908973.idtracker@ietfa.amsl.com> Date: Wed, 29 Mar 2017 12:26:00 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG 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, 29 Mar 2017 19:26:00 -0000 Changed milestone "Submit ‘Explicit Congestion Notification (ECN) Experimentation’ as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit 'Guidelines for DiffServ to IEEE 802.11 Mapping' as an Informational RFC ", set description to "Submit 'Guidelines for DiffServ to IEEE 802.11 Mapping' as an Informational RFC". URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Wed Mar 29 12:47:22 2017 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 690AE1297A5; Wed, 29 Mar 2017 12:47:20 -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, 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=bobbriscoe.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 I4rq95PLGI_w; Wed, 29 Mar 2017 12:47:17 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 019311297BE; Wed, 29 Mar 2017 12:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:References:To:Subject:From: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=HyM0Hf9RcW7RnM1R1Pmx2bUJQfjpmoeNIMeDcZ5qLfM=; b=IsYQoWy+e8bEmnUR+/WYqchHP 1iYzaYjCqrNIVPS+mj8K25glatKoi/9v9DLa1hTC+eOjHRYnoCz6XaW1pFWPH7gTFuo+gssxH0tJG +4Qspqx7flEjc81bA/JilnoahCLU7I+8ydRX9QlLYJ46Zg1+DkIR0ngPcOK53SuTrhMQZVL2ybTYt db5BzLoMVqsCv7evLW5zzR7dIzlaqEtB5KTqqNyQDZusAy8+mORyHSM/OAWclr+lKJb8U7mqBnigu XEnbuE4+9E2FPrt5tpHvkSsan7URzTiuTpCa40SAvNzg11Cxy5QnMRDtHuoqEnwBfR312cu49Dm1j SD460BPKg==; Received: from [77.88.71.158] (port=54348 helo=[172.16.5.179]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ctJYn-0007Jh-Jw; Wed, 29 Mar 2017 20:47:14 +0100 From: Bob Briscoe To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list Message-ID: Date: Wed, 29 Mar 2017 20:47:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------54382D5FEED02957C3633CD0" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 29 Mar 2017 19:47:20 -0000 This is a multi-part message in MIME format. --------------54382D5FEED02957C3633CD0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Wolfram, Just to explain some context. The PIE algorithm determines a dropping probability at sample times (default 16ms), then continues to drop with that probability until the next sample. If the queue had been large then traffic ends, while the queue is draining towards zero it is still dropping at the last calculated probability. So the PIE code includes a heuristic that suppresses any drop if the queue is less than half the target. Nonetheless, the PIE algo continues to calculate what the drop probability /would/ be if a queue of more than half the target appeared again. This is so that the drop probability reflects a longer running measure of the load as well as the instantaneous queue. Bob On 29/03/17 18:58, Rong Pan (ropan) wrote: > We are not holding back queued packets when the link is idle. We stop > dropping packets when the queue is shallow in order to avoid > unnecessary drops that could cause TCP traffic to back off and stop > sending traffic that will cause link idle. > > Rong > > From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" > > > Date: Wednesday, March 29, 2017 at 2:30 AM > To: Rong Pan >, Luca > Muscariello >, "Bless, Roland (TM)" > > > Cc: tsvwg IETF list >, Fred > Baker >, > Bob Briscoe >, "De > Schepper, Koen (Nokia - BE/Antwerp)" > >, Greg White > >, Jonathan > Morton >, AQM > IETF list >, Preethi Natarajan > > > Subject: RE: [aqm] Questioning each PIE heuristic > > To my understanding a proper operating AQM _/is/_ work-conserving. > Packet drops occur, if any, when a reasonable queue is present. And as > long as packets are present in the queue, the link runs at 100%. I > cannot see any (AQM) mechanism that is holding back queued packets > while the link is idle. > > Wolfram > > *From:*aqm [mailto:aqm-bounces@ietf.org] *On Behalf Of *Rong Pan (ropan) > *Sent:* Dienstag, 28. März 2017 16:17 > *To:* Luca Muscariello >; Bless, Roland (TM) > > > *Cc:* tsvwg IETF list >; Fred > Baker >; > Bob Briscoe >; De > Schepper, Koen (Nokia - BE/Antwerp) > >; Greg White > >; Jonathan > Morton >; AQM > IETF list >; Preethi Natarajan > > > *Subject:* Re: [aqm] Questioning each PIE heuristic > > Sorry for causing the confusion in choosing the word > “work-conserving". If we apply AQM and can not achieving 100% line > rate, i.e. losing throughput, it is a big No No. Since we are dealing > with TCP traffic, excess drops can cause TCP to back off too much and > under-utilize the link. > > Rong > > *From: *Luca Muscariello > > *Date: *Tuesday, March 28, 2017 at 8:48 AM > *To: *"Bless, Roland (TM)" > > *Cc: *Fred Baker >, Jonathan Morton > >, tsvwg IETF > list >, Bob Briscoe > >, "De Schepper, Koen > (Koen)" >, Rong Pan >, Greg White >, AQM IETF list >, Preethi Natarajan > > *Subject: *Re: [aqm] Questioning each PIE heuristic > > Work conserving is supposed to be referring to the scheduler. > > I'm not familiar with work-conservation when it refers to active queue > management. > > I'm not sure it is actually defined. > > I can understand that an AQM can produce under utilization of the > link, but that is > > different to work conservation. Or is it maybe more subtle than that? > > Luca > > On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) > > wrote: > > Hi, > > Am 28.03.2017 um 13:39 schrieb Fred Baker: > > > I'm not convinced I understand the definitions of "work conserving" > > and "non work conserving" in this context. A "work conserving" > > scheduling algorithm keeps an interface transmitting as long as > there > > is data in the queue, while a non-work-conserving algorithm reduces > > the effective rate of the interface by spacing packets out. > > +1 (that's also the definition I use, so I'm lost here too) > > Regards, > Roland > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------54382D5FEED02957C3633CD0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Wolfram,

Just to explain some context. The PIE algorithm determines a dropping probability at sample times (default 16ms), then continues to drop with that probability until the next sample. If the queue had been large then traffic ends, while the queue is draining towards zero it is still dropping at the last calculated probability. So the PIE code includes a heuristic that suppresses any drop if the queue is less than half the target. Nonetheless, the PIE algo continues to calculate what the drop probability /would/ be if a queue of more than half the target appeared again.

This is so that the drop probability reflects a longer running measure of the load as well as the instantaneous queue.


Bob

On 29/03/17 18:58, Rong Pan (ropan) wrote:
We are not holding back queued packets when the link is idle. We stop dropping packets when the queue is shallow in order to avoid unnecessary drops that could cause TCP traffic to back off and stop sending traffic that will cause link idle.

Rong

From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com>
Date: Wednesday, March 29, 2017 at 2:30 AM
To: Rong Pan <ropan@cisco.com>, Luca Muscariello <luca.muscariello@gmail.com>, "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Greg White <g.white@cablelabs.com>, Jonathan Morton <chromatix99@gmail.com>, AQM IETF list <aqm@ietf.org>, Preethi Natarajan <prenatar@cisco.com>
Subject: RE: [aqm] Questioning each PIE heuristic

To my understanding a proper operating AQM _is_ work-conserving. Packet drops occur, if any, when a reasonable queue is present. And as long as packets are present in the queue, the link runs at 100%. I cannot see any (AQM) mechanism that is holding back queued packets while the link is idle.

 

Wolfram

 

 

From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. März 2017 16:17
To: Luca Muscariello <luca.muscariello@gmail.com>; Bless, Roland (TM) <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>; Fred Baker <fredbaker.ietf@gmail.com>; Bob Briscoe <ietf@bobbriscoe.net>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>; Greg White <g.white@cablelabs.com>; Jonathan Morton <chromatix99@gmail.com>; AQM IETF list <aqm@ietf.org>; Preethi Natarajan <prenatar@cisco.com>
Subject: Re: [aqm] Questioning each PIE heuristic

 

Sorry for causing the confusion in choosing the word “work-conserving". If we apply AQM and can not achieving 100% line rate, i.e. losing throughput, it is a big No No. Since we are dealing with TCP traffic, excess drops can cause TCP to back off too much and under-utilize the link.

 

Rong

 

From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Preethi Natarajan <prenatar@cisco.com>
Subject: Re: [aqm] Questioning each PIE heuristic

 

Work conserving is supposed to be referring to the scheduler.

I'm not familiar with work-conservation when it refers to active queue management.

I'm not sure it is actually defined.

 

I can understand that an AQM can produce under utilization of the link, but that is 

different to work conservation. Or is it maybe more subtle than that?

 

Luca

 

On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) <roland.bless@kit.edu> wrote:

Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conserving"
> and "non work conserving" in this context. A "work conserving"
> scheduling algorithm keeps an interface transmitting as long as there
> is data in the queue, while a non-work-conserving algorithm reduces
> the effective rate of the interface by spacing packets out.

+1 (that's also the definition I use, so I'm lost here too)

Regards,
 Roland


_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------54382D5FEED02957C3633CD0-- From nobody Wed Mar 29 14:03:45 2017 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 7547212944C for ; Wed, 29 Mar 2017 14:03:44 -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=unavailable 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 dMnS0XRXDfap for ; Wed, 29 Mar 2017 14:03:43 -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 AE04612945D for ; Wed, 29 Mar 2017 13:58:28 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id d191so19537968ywe.2 for ; Wed, 29 Mar 2017 13:58:28 -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=W4mCTqsLBjFhcM7Lnaxu6duUARBWG3hg2dNchMeavLY=; b=YhYTCoB23HI5HIpfr0UfWVl1SzNHBypOCrcUHcy2Cyc6kzP8cWAWxvTQP0/zUpWWX0 keAdDxrXjbdyfylt+q4JQEHtaNnzokQ/9jiPxfzbPFsOjhp0mBmSXZQAi+HqUyzoJYYm zkR1TGsGUDYYpKF1TEEfEla4Rw03ZSPjsDUkwL5h23noeOAqNWO2q1UyFEZPaYUobygh P6Doqs1oVseQv620ZzYZb3T3hLLqUfdYMwr4rgDHxFN0mJdq3ES9w3tsaVtGaJTLqyeA cWXZkYj3t3z6qpJ2FwRLkYaQ6ZlmYgUV2Cl5blRiujRalqNzYgzfxN/OrWUOLNQF5SZ1 R1tQ== 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=W4mCTqsLBjFhcM7Lnaxu6duUARBWG3hg2dNchMeavLY=; b=PqYvzcuJb3ExV8SchtPEmMF0q1itT+mqL/0h+s8qyOAQ6d+t/I3O+l0CAJ33+1NTuD A7pM3CSq7jXZf16UXjkHv+BObj/g8DyWUDRQp0fPxCO89bT7qbHxsYBtkL4q5MViqmn3 RVYN3jknDjwPgdcPDFlbokPNVW+kqRljqlUiwPH1LDzmQRn7+C/XClAxgZQdu/iIURdy sxRSiknQLdbMsjTJdcyHzikaufRxtmw7dckfk9Rtrz6lDcpwT6asv6tin0a4Z8T7nMbN iKMOl3WeqKEwjamXNu5Hm69IvjhlntA1K0F6wH8NPkWAG9Ayx8/CO5fhtwmtqCRBWNwv ElJA== X-Gm-Message-State: AFeK/H3QnqJfKesUxLg558d5lnQbsom0BO302r6989joSRs3AlJDNJ5DdIcd5UfqCTcGD9vRx3VvReRyI1hHoQ== X-Received: by 10.37.209.212 with SMTP id i203mr2645612ybg.121.1490821107946; Wed, 29 Mar 2017 13:58:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 29 Mar 2017 13:58:27 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Wed, 29 Mar 2017 13:58:27 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Wed, 29 Mar 2017 15:58:27 -0500 Message-ID: To: tsvwg@ietf.org Content-Type: multipart/alternative; boundary=001a114fa8ec901d7f054be4d651 Archived-At: Subject: [tsvwg] Correction on 3GPP dates for 5G 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, 29 Mar 2017 21:03:44 -0000 --001a114fa8ec901d7f054be4d651 Content-Type: text/plain; charset=UTF-8 Dear TSVWG, I'm glad I confirmed with Georg - the June 2018 date is for 3GPP to finish technical specification work on 5G. That's the date for L4S to be included. Thanks, Spencer --001a114fa8ec901d7f054be4d651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TSVWG,

= I'm glad I confirmed with Georg - the June 2018 date is for 3GPP to fin= ish technical specification work on 5G.

That's the date for L4S to be included.

Thanks,

Spencer
--001a114fa8ec901d7f054be4d651-- From nobody Thu Mar 30 00:46:57 2017 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 5AB2D129542; Thu, 30 Mar 2017 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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=bobbriscoe.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 WWmNVnq3VXoh; Thu, 30 Mar 2017 00:46:48 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 3CBAB1293E9; Thu, 30 Mar 2017 00:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject: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=tfvhEbHj7ngsgBRHLmm5MuEEeNWTKf3ywkeciavyjgU=; b=KKJSX0O9dttmo2CpLBcDb2Mfs5 X+HY5n1ZZE/JEQRHYxb+ruBG6BNDri8QtjWA97DRNpvL+RI+olcCb2Ak08e9nO2BzUBR7Igxd60Pm 6G2byMEGIW6sHV5GwVcSflIv6+NRoDt2yCjMs2cIWZmpAYCSqihFSV4funFirYU0+/kN21RMEg8th b4Bz6B2ED2e9+t0jE6x197nXAW+eXp8/YFNqdG3A28pyblF9vJUNSscB2ySPRKs54UiphwMwJo05S 02uc6gM+cpS2bHWt+bpA7vud7RocfkL+axcnboKby9+zrwitdcC3qyuwlNpwpoXhokQ3TGFFz8HsW Y1G01BiQ==; Received: from [77.88.71.158] (port=62123 helo=[172.16.5.179]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ctUn8-000056-0Z; Thu, 30 Mar 2017 08:46:46 +0100 To: Jonathan Morton , "Rong Pan (ropan)" References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> Cc: Greg White , "FredBaker.IETF@gmail.com" , AQM IETF list , tsvwg IETF list From: Bob Briscoe Message-ID: <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Date: Thu, 30 Mar 2017 08:46:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 30 Mar 2017 07:46:50 -0000 Jonathan, Picking up on an earlier point you made about avoiding heuristics by ensuring the underlying algo is sound,... that's precisely why I'm going through all the (9) PIE heuristics... For PI2 we removed all but 2 and it worked the same or better than PIE in all our tests. I have been assessing each of the other 7 one by one for reinstatement. So far I've rejected 6. I think I can reject this last one by making the sampling time of the base PI algo dependent on the max link rate. Then when the queue goes idle, the base PI algo will decay drop down to zero no slower than the queue drains, without needing this extra heuristic. But I need to check that's realistic. We will be writing all this up (probably in an update to the PI2 paper - I don't think the IETF PI2 spec is the right place for a critique of heuristics that it doesn't use). Our aim is a completely sound AQM in a few lines of code and a few operations so it can be implemented everywhere with minimal resistance from developers due to performance concerns (e.g. cheap ethernet switches, cheap home gateways, carrier-grade equipment for thousands of users, etc). Bob On 28/03/17 07:25, Jonathan Morton wrote: > > By all means, avoid dropping packets when the queue is actually empty - that is, when you’re delivering the last packet in the queue. In that case, there is no congestion to signal for. But there really is no need to have any complex state-switching logic for that. If your underlying algorithm is sound, it will naturally decay to zero packet drops if the empty-queue condition persists. > > - Jonathan Morton > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Mar 30 02:08:43 2017 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 E9D6D128B4E; Thu, 30 Mar 2017 02:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 gA5qd5fQIvyR; Thu, 30 Mar 2017 02:08:35 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::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 349C51241FC; Thu, 30 Mar 2017 02:08:35 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id n78so3968467lfi.3; Thu, 30 Mar 2017 02:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jDkU2XksMyT27XP4ClXrfKmLPIDeMyE1aa9rZCXiBgk=; b=erFIRMenn3q044tt3Gxk3zGZOqiQCjPcyh/VBchL//oRO5HBMMjF3ZDDaNt4LJkO1/ JIoHcgnNvJxFdRY4h/Z8zXhKyH22vWB1X0vXPE6Sy/ZaHndUGeho31H5DrIzGP1mAgCo 7Z+7zgjVIlWoPDv709Iz8pCvBLctnpV6R4jCtePPYEE0ES1HlWSK03YvxnnUURb/3FSS auWbM2YL9mYrrLUUPyL1ryvU6YmPbFkJMYST/WyRcejwEvWEhzqCC8ny1KPp6v/MiQgV 2WDChiolkGmytg4B5uBPfiuQvqUyXZ7nadu5imGD3wnard08g8QfFez92XI9I2u2gC27 qkbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jDkU2XksMyT27XP4ClXrfKmLPIDeMyE1aa9rZCXiBgk=; b=BjLQQquSuR1UivCHwQrnNjalJyKQy5Qe+8xEx10p+S4Sh74JDEctdDJf478bZSDom6 WNoclJnvu/dNJfLGFgdBgJmhWmXUWKE9EqafWU/0NrKOXNZ34Z0ZwQyifpqCvM+cwtJq PT+/3Sv80ELiKk9OPIqJpoT6KVYEHsgfjeOBTCqldTe/2SjMHDCtq9QxQVUyzPeRuF/S LwxcMBE7Zr3mOLSTyLYyRnraUf4PWvzlHIHzqIsG78fa6NdgwM2bfGGS5HHu1uWkjQ8Y GbmzlbG5nQCtsPdekskKDDL07pZA/NpyTuJTD7qzapqolT4hFAmCDoBIxFPMt/TJclRe gjvg== X-Gm-Message-State: AFeK/H2GVOo/VqsDToeX2NB/EDu+wF0L0cTMRMM2PkDvsDT2dBW5olnWI64PCKH2bzrDsA== X-Received: by 10.25.204.9 with SMTP id c9mr1266515lfg.107.1490864913502; Thu, 30 Mar 2017 02:08:33 -0700 (PDT) Received: from [192.168.100.14] (37-219-158-10.nat.bb.dnainternet.fi. [37.219.158.10]) by smtp.gmail.com with ESMTPSA id t30sm250424ljd.39.2017.03.30.02.08.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Mar 2017 02:08:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Date: Thu, 30 Mar 2017 12:08:29 +0300 Cc: "Rong Pan (ropan)" , Greg White , "FredBaker.IETF@gmail.com" , AQM IETF list , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 30 Mar 2017 09:08:37 -0000 > On 30 Mar, 2017, at 10:46, Bob Briscoe wrote: >=20 > For PI2 we removed all but 2 and it worked the same or better than PIE = in all our tests. I have been assessing each of the other 7 one by one = for reinstatement. So far I've rejected 6. I think I can reject this = last one by making the sampling time of the base PI algo dependent on = the max link rate. Then when the queue goes idle, the base PI algo will = decay drop down to zero no slower than the queue drains, without needing = this extra heuristic. That=E2=80=99s fair enough. It sounds like the fairly coarsely discrete time intervals in PIE are = the main justification for this particular heuristic, so it might be = sufficient to document that WRT PIE itself. Using finer time intervals = is clearly a better choice for the future. - Jonathan Morton From nobody Thu Mar 30 02:57:44 2017 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 F1DFC12946B; Thu, 30 Mar 2017 02:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 0km1WCzFG4Qb; Thu, 30 Mar 2017 02:57:40 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (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 674EC129426; Thu, 30 Mar 2017 02:57:40 -0700 (PDT) Received: from [134.2.11.131] (chaos.informatik.uni-tuebingen.de [134.2.11.131]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 3CA1A12FA2; Thu, 30 Mar 2017 11:57:38 +0200 (CEST) To: Jonathan Morton , Bob Briscoe References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list From: Michael Menth Message-ID: <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de> Date: Thu, 30 Mar 2017 11:57:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement 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, 30 Mar 2017 09:57:43 -0000 Hi all, Am 30.03.2017 um 11:08 schrieb Jonathan Morton: > >> On 30 Mar, 2017, at 10:46, Bob Briscoe wrote: >> >> For PI2 we removed all but 2 and it worked the same or better than PIE in all our tests. I have been assessing each of the other 7 one by one for reinstatement. So far I've rejected 6. I think I can reject this last one by making the sampling time of the base PI algo dependent on the max link rate. Then when the queue goes idle, the base PI algo will decay drop down to zero no slower than the queue drains, without needing this extra heuristic. > > That’s fair enough. > > It sounds like the fairly coarsely discrete time intervals in PIE are the main justification for this particular heuristic, so it might be sufficient to document that WRT PIE itself. Using finer time intervals is clearly a better choice for the future. PIE uses time intervals for measurement purposes and several parameters contribute. We've recently done some basic work on measurement methodology that facilitates a comparison of different measurement approaches and better-informed parametrization by introduction of the "memory" concept. https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf PIE essentially implements TDRM-DTWMA-UEMA illustrated in Fig. 6d. The concept of "memory" can also be applied to moving averages which are also used in PIE for several purposes. Configuration via a "memory" can make some heuristics more intuitive. Best wishes, Michael > > - Jonathan Morton > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Mar 30 05:06:59 2017 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 69C671294E4; Thu, 30 Mar 2017 05:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 3LDKozEs43Nl; Thu, 30 Mar 2017 05:06:51 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DA2129489; Thu, 30 Mar 2017 05:06:51 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 08:06:50 -0400 From: Dave Dolson To: Bob Briscoe , Jonathan Morton , "Rong Pan (ropan)" CC: Greg White , tsvwg IETF list , "AQM IETF list" , "FredBaker.IETF@gmail.com" Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHALX//dtLVFUCWt7nl7FFE5KGpuUqAgABZiACAAztmAIAAA2ew Date: Thu, 30 Mar 2017 12:06:48 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> In-Reply-To: <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic 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, 30 Mar 2017 12:06:53 -0000 V2hpbGUgcmV2aWV3aW5nIFBJRSwgaXQgbWlnaHQgYmUgd29ydGggcmV2aXNpdGluZyBteSBjb21t ZW50IGhlcmU6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYXFtL2lma0Jl NnV2TUU1TnFtLUo2dWxaV2xvb0J4bw0KVGhlIHNlY29uZCBwYXJ0IHdhcyBuZXZlciBhbnN3ZXJl ZCB0byBteSBzYXRpc2ZhY3Rpb24uDQoNCkkgYmVsaWV2ZWQgSSBoYWQgZm91bmQgYSBidWc6ICBJ IHNhaWQsICJJIHRoaW5rIHRoZXJlIGFyZSBhIHZhcmlldHkgb2YgdHJhZmZpYyBwYXR0ZXJucyB0 aGF0IGNhbiBhbGxvdyAncCcgdG8gbWVhbmRlciBhcm91bmQgaW4gbm9uLXplcm8gc3BhY2UgZXZl biB0aG91Z2ggdGhlIHF1ZXVlIGlzIG5lYXJseSBlbXB0eSINCg0KTWF5YmUgeW91J3ZlIGFkZHJl c3NlZCB0aGlzLCBiZWNhdXNlIEkgdGhpbmsgaXQgd2FzIGR1ZSB0byBhIGhldXJpc3RpYy4NCg0K SSdtIG11Y2ggaW4gZmF2b3Igb2YgcmVtb3ZpbmcgdGhlIGhldXJpc3RpY3Mgb24gY29udHJvbCBz eXN0ZW1zOyB0aGFua3MuDQoNCi1EYXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogYXFtIFttYWlsdG86YXFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC b2IgQnJpc2NvZQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3IDI6NDcgQU0NClRvOiBK b25hdGhhbiBNb3J0b247IFJvbmcgUGFuIChyb3BhbikNCkNjOiBHcmVnIFdoaXRlOyB0c3Z3ZyBJ RVRGIGxpc3Q7IEFRTSBJRVRGIGxpc3Q7IEZyZWRCYWtlci5JRVRGQGdtYWlsLmNvbQ0KU3ViamVj dDogUmU6IFthcW1dIFF1ZXN0aW9uaW5nIGVhY2ggUElFIGhldXJpc3RpYw0KDQpKb25hdGhhbiwN Cg0KUGlja2luZyB1cCBvbiBhbiBlYXJsaWVyIHBvaW50IHlvdSBtYWRlIGFib3V0IGF2b2lkaW5n IGhldXJpc3RpY3MgYnkgZW5zdXJpbmcgdGhlIHVuZGVybHlpbmcgYWxnbyBpcyBzb3VuZCwuLi4g dGhhdCdzIHByZWNpc2VseSB3aHkgSSdtIGdvaW5nIHRocm91Z2ggYWxsIHRoZSAoOSkgUElFIGhl dXJpc3RpY3MuLi4NCg0KRm9yIFBJMiB3ZSByZW1vdmVkIGFsbCBidXQgMiBhbmQgaXQgd29ya2Vk IHRoZSBzYW1lIG9yIGJldHRlciB0aGFuIFBJRSBpbiBhbGwgb3VyIHRlc3RzLiBJIGhhdmUgYmVl biBhc3Nlc3NpbmcgZWFjaCBvZiB0aGUgb3RoZXIgNyBvbmUgYnkgb25lIGZvciByZWluc3RhdGVt ZW50LiBTbyBmYXIgSSd2ZSByZWplY3RlZCA2LiBJIHRoaW5rIEkgY2FuIHJlamVjdCB0aGlzIGxh c3Qgb25lIGJ5IG1ha2luZyB0aGUgc2FtcGxpbmcgdGltZSBvZiB0aGUgYmFzZSBQSSBhbGdvIGRl cGVuZGVudCBvbiB0aGUgbWF4IGxpbmsgcmF0ZS4gVGhlbiB3aGVuIHRoZSBxdWV1ZSBnb2VzIGlk bGUsIHRoZSBiYXNlIFBJIGFsZ28gd2lsbCBkZWNheSBkcm9wIGRvd24gdG8gemVybyBubyBzbG93 ZXIgdGhhbiB0aGUgcXVldWUgZHJhaW5zLCB3aXRob3V0IG5lZWRpbmcgdGhpcyBleHRyYSBoZXVy aXN0aWMuIEJ1dCBJIG5lZWQgdG8gY2hlY2sgdGhhdCdzIHJlYWxpc3RpYy4NCg0KV2Ugd2lsbCBi ZSB3cml0aW5nIGFsbCB0aGlzIHVwIChwcm9iYWJseSBpbiBhbiB1cGRhdGUgdG8gdGhlIFBJMiBw YXBlciAtIEkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgUEkyIHNwZWMgaXMgdGhlIHJpZ2h0IHBsYWNl IGZvciBhIGNyaXRpcXVlIG9mIGhldXJpc3RpY3MgdGhhdCBpdCBkb2Vzbid0IHVzZSkuDQoNCk91 ciBhaW0gaXMgYSBjb21wbGV0ZWx5IHNvdW5kIEFRTSBpbiBhIGZldyBsaW5lcyBvZiBjb2RlIGFu ZCBhIGZldyBvcGVyYXRpb25zIHNvIGl0IGNhbiBiZSBpbXBsZW1lbnRlZCBldmVyeXdoZXJlIHdp dGggbWluaW1hbCByZXNpc3RhbmNlIGZyb20gZGV2ZWxvcGVycyBkdWUgdG8gcGVyZm9ybWFuY2Ug Y29uY2VybnMgKGUuZy4gY2hlYXAgZXRoZXJuZXQgc3dpdGNoZXMsIGNoZWFwIGhvbWUgZ2F0ZXdh eXMsIGNhcnJpZXItZ3JhZGUgZXF1aXBtZW50IGZvciB0aG91c2FuZHMgb2YgdXNlcnMsIGV0Yyku DQoNCg0KQm9iDQoNCk9uIDI4LzAzLzE3IDA3OjI1LCBKb25hdGhhbiBNb3J0b24gd3JvdGU6DQo+ DQo+IEJ5IGFsbCBtZWFucywgYXZvaWQgZHJvcHBpbmcgcGFja2V0cyB3aGVuIHRoZSBxdWV1ZSBp cyBhY3R1YWxseSBlbXB0eSAtIHRoYXQgaXMsIHdoZW4geW914oCZcmUgZGVsaXZlcmluZyB0aGUg bGFzdCBwYWNrZXQgaW4gdGhlIHF1ZXVlLiAgSW4gdGhhdCBjYXNlLCB0aGVyZSBpcyBubyBjb25n ZXN0aW9uIHRvIHNpZ25hbCBmb3IuICBCdXQgdGhlcmUgcmVhbGx5IGlzIG5vIG5lZWQgdG8gaGF2 ZSBhbnkgY29tcGxleCBzdGF0ZS1zd2l0Y2hpbmcgbG9naWMgZm9yIHRoYXQuICBJZiB5b3VyIHVu ZGVybHlpbmcgYWxnb3JpdGhtIGlzIHNvdW5kLCBpdCB3aWxsIG5hdHVyYWxseSBkZWNheSB0byB6 ZXJvIHBhY2tldCBkcm9wcyBpZiB0aGUgZW1wdHktcXVldWUgY29uZGl0aW9uIHBlcnNpc3RzLg0K Pg0KPiAgIC0gSm9uYXRoYW4gTW9ydG9uDQo+DQoNCg0KLS0NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJvYiBCcmlzY29l ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFxbSBtYWls aW5nIGxpc3QNCmFxbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcW0NCg== From nobody Thu Mar 30 11:29:36 2017 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 1ED50127698 for ; Thu, 30 Mar 2017 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 YboQrPeti8qH for ; Thu, 30 Mar 2017 11:29:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 C64A6128616 for ; Thu, 30 Mar 2017 11:29:30 -0700 (PDT) X-AuditID: c1b4fb2d-275fe70000005be8-dc-58dd4e87d250 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id EF.0D.23528.78E4DD85; Thu, 30 Mar 2017 20:29:29 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 30 Mar 2017 20:29:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KqK2vRO306oyB5MBtEZ/+j3y6osj47XVpzwQKKgS4HE=; b=Re7Fs85eklCR5IkdeXctZCK29FSUXa1pRB9/dEKCs245GrL0cnGonIwt18HPksnceF7tNFIoRNYse+5YtO8jSBBxCWWGO/HlF1NNp4jc8+YH/E+M9aBhAYh8I3RDJH5pZ7BrsZUh3KPmYttzcByNdow+bzBOBMuoKP7aE0ybrcE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0575.eurprd07.prod.outlook.com (10.242.221.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 30 Mar 2017 18:29:15 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.014; Thu, 30 Mar 2017 18:29:14 +0000 From: Ingemar Johansson S To: "randall@lakerest.net" , "tuexen@C-muenster.de" , Salvatore Loreto , "rfc@robin-seggelmann.com" , "weinrank@C-muenster.de" CC: tsvwg IETF list Thread-Topic: Comments on draft-ietf-tsvwg-sctp-ndata-09 regarding SCTP_SS_WFQ Thread-Index: AdKpgccYBOTCLBZnT/ycnRh8nx1dVw== Date: Thu, 30 Mar 2017 18:29:13 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lakerest.net; dkim=none (message not signed) header.d=none;lakerest.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.92] x-microsoft-exchange-diagnostics: 1; DB4PR07MB0575; 7:MiJE9bFdNgTyAdyaV6tbX8T4JhvMfrvbPQdYc+9jfqEOjUkZtz8c4y/dWlPTiUelFw0Na0/iWMY4R+fzuK1EpK30uHi8f3WDOm6PzwDSBV1MQrV+nhp59Cx/YsYVz/VGuOfd8rZn9/fwthmNpVx1+1Rl8wI1Q6CvQGY1qlfL4v3C3LdOhzSi1AQilQoPAdD+myFJJnsQzcn+K9ouMK2//amiw6bbGwMWRgidgFtrGSoei2euOS+N0CI6JRpvNJOWMhQ37Ie3A2epxgmEg+NpRwauLzh+8rord1CDc93jaIpATucZpWjBJdiINhIC1qv98s3kdV37Ql+efpzeuZHLfw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(189998001)(6506006)(54896002)(19609705001)(6306002)(9686003)(9326002)(2201001)(77096006)(66066001)(122556002)(236005)(3846002)(25786009)(55016002)(2900100001)(53936002)(86362001)(6436002)(790700001)(6116002)(102836003)(606005)(8936002)(81166006)(38730400002)(2906002)(99286003)(54356999)(4326008)(50986999)(2501003)(7736002)(5660300001)(74316002)(7906003)(33656002)(3660700001)(8676002)(3280700002)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0575; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: b387d595-81a4-4685-842a-08d4779aaaf9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB0575; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006067)(93001067)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:DB4PR07MB0575; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB0575; x-forefront-prvs: 02622CEF0A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348523144127BE4D0AF43A8C2340DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 18:29:13.9949 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0575 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed7L9jpcvZniwUvEsKSLs8wPI8VUIkdURn0ZQtjKFxW3KXtN NPqgq4WGYVIbbkRqeckK85oKGjpvy6LlrUI3RdNYqCkViOUs52Owb79z/v9znvOHhyF9BugA Jl2TzWk1SpVEIKJMija/sKJzDsWRGttO2VzxGi2zjrgI2cCiQyBzdS8JZZ+M/rG0vLnoISGv qloj5CXltZTcODVNn6eSRNEpnCo9h9OGx1wWpQ1NFKKsV6dyl99a6XykO3EHeTHARsLHpsfU HSRifNiXCPSLQwJcWBEYRl3IXVDsXRLeLS+SWDES0K+3bxcDCLryDZR7mYCNhjrL6taIL6sj oLRvmXALJBsChrHfAjfvZk/DrLMEudmXTYT1p48IzFKoL7HSbqbYfTDlerK1VMwmgcswuOVH bDBMr05ReKc/TMyVEzgFC1WdNhKzH3z7skG7j0DsfQRFBXohFvbC+sjsVjpgi0l4YekjcWGm oddVi7DrLMw7xygslCDIt9u3xzPgZuctCrMKvvYPCrFpmAB9y8j240Fg624gcdAAcIwVIcxB 4LR30fjwTJiZXxHicLvgjWmOuof2mz0ymT1sZg8b7kvhs+GBAPMhqKlcIDGHQdmGhfLsVyDh M+THczyvTo04JuW06Vd5PlMj1XDZTWjzd/W0/AlrR88X4iyIZZDEW1yR4FD40MocPk9tQcCQ El9xYdRmS5yizLvOaTOTtddUHG9BgQwl8RfHvv6g8GFTldlcBsdlcdr/KsF4BeSjPeV0T2hC ZKJCcTz+p4k78NfZ2FW2ospOyascD+xuaFVZq4JtVwqaDp+kZ0zThH3te5DIrhuP73BMxje3 a0tDLtzmZ2KaM3OXkiNaey+mTVYOGfvbqsdvtFS3q+sK4wrUG/XM4kxhb8dAlLdu9NJYivD9 cOiZXztsxvDRH40dEopPUx49SGp55T8ZP9ixWQMAAA== Archived-At: Subject: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-09 regarding SCTP_SS_WFQ 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, 30 Mar 2017 18:29:35 -0000 --_000_DB4PR07MB348523144127BE4D0AF43A8C2340DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have been experimenting a little with the stream scheduler in the SCReAM = implementation (https://github.com/EricssonResearch/scream), which is somet= hing close to a weighted fair scheduler. Not sure if these findings are of = interest but anyway... While it is quite straightforward to allocate bandwidth in a weighted manne= r if the sources are of the type "infinite bandwidth" i.e. large enough obj= ects, things get more tricky when sources like video is used. SCReAM congestion control has the requirement that a minimum of delay is al= lowed on the sending side, this means that the source bitrate must match th= e available (weighted) share of the bandwidth relatively closely. The end e= ffect is that if we run two video sources through the SCReAM congestion con= troller with different weights , we will still get the same bitrate.. In SCReAM I implemented a correction to this, perhaps there are better alte= rnatives that I don't know of. The bottomline is that the results with WFQ may differ depending of if the = sources are of infinite bitrate or if they are bandwidth limited. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348523144127BE4D0AF43A8C2340DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I have been experimenting a little with the stream s= cheduler in the SCReAM implementation (https://github.com/EricssonResearch/scream), which i= s something close to a weighted fair scheduler. Not sure if these findings are of interest but anyway…

 

While it is quite straightforward to allocate bandwi= dth in a weighted manner if the sources are of the type “infinite ban= dwidth” i.e. large enough objects, things get more tricky when source= s like video is used.

 

SCReAM congestion control has the requirement that a= minimum of delay is allowed on the sending side, this means that the sourc= e bitrate must match the available (weighted) share of the bandwidth relati= vely closely. The end effect is that if we run two video sources through the SCReAM congestion controller with = different weights , we will still get the same bitrate..

In SCReAM I implemented a correction to this, perhap= s there are better alternatives that I don’t know of.

 

The bottomline is that the results with WFQ may diff= er depending of if the sources are of infinite bitrate or if they are bandw= idth limited.

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348523144127BE4D0AF43A8C2340DB4PR07MB348eurprd_-- From nobody Thu Mar 30 13:17:59 2017 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 7FC5C129411 for ; Thu, 30 Mar 2017 13:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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=bobbriscoe.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 Ohhp5uHsJlRw for ; Thu, 30 Mar 2017 13:17:55 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 D23641292FD for ; Thu, 30 Mar 2017 13:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Dfh/zQ9/zT8gthKPOYS/wo+xZPj72W6qiYoCT+yi8u0=; b=Oevu9yWdySy/iHX+ZKrEEQwFYN XYXqeyyxWhSmksxELv/nyGd3x67GwxGoM8YvrtBx/YqCgvSWk7qZt59d2i3+j+nW5Vv5KZBfRLKS0 Qh4o0g6BJHscnTy9Mv4SvJUVP5l5yspJGufJ7ryo/0HVoCt7/c3qdPYYv0JkebyYYF+6A6uQmKfps p+Yn6ECKr4BLjjN3EewaO2lq1HtwpCefUigXVoLB3JVAtNjoC1XPIx+YxHGCBWjT01nmhXIXyQye3 2QruINEcT0czDjXYgyfFv0UaPpI0rCBmHtLMH06Cuj48SjgXzo4gqro+D7Um7FaIEm28InkT93+Rl 3NlY1Oww==; Received: from [77.40.143.110] (port=25179 helo=[172.31.98.93]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ctgVx-0008Gy-Vq; Thu, 30 Mar 2017 21:17:52 +0100 To: Ingemar Johansson S , tsvwg IETF list From: Bob Briscoe Message-ID: Date: Thu, 30 Mar 2017 21:17:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tsvwg] transport protocol feedback overhead 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, 30 Mar 2017 20:17:57 -0000 Ingemar, list, I seemed to get blocked from talking after I was trying to be polite - letting you finish your talk... You described one problem: (A) In mobile (and other networks) upstream ACK load is a problem. There is a complementary problem too: (B) Capacity variation is getting huge as radio wavelength increases. So it's useful for the sender to watch the timing of the ACKs to be able to track changes in capacity as fast as possible. It's also useful to be able to vary the spacing between the packets you send to probe for increases in capacity by watching the ACK spacing in response. These two are in tension - (A) wants less ACKs, (B) wants them all. A possible solution, is a data structure in a stretch ACK to be able to report the time of arrival of all the previous data packets (ie. the packets that the stretch ACK is ACKing. Even tho this info will arrive at the sender later than it would have done if the ACKs had not been suppressed, as long as you are still getting a reasonable number of ACKs every RTT, it resolves the tension between A and B. Thoughts? Does this idea already exist? Bob PS. Apologies for dropping an innovative idea into a standards meeting. This probably ought to be a research paper first. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Mar 30 14:15:18 2017 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 C7D24128BB7 for ; Thu, 30 Mar 2017 14:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 jK1FczDbTyyP for ; Thu, 30 Mar 2017 14:15:13 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 9B79B12957A for ; Thu, 30 Mar 2017 14:14:54 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cthPB-0003Qa-1E for tsvwg@ietf.org; Thu, 30 Mar 2017 23:14:53 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cthP9-0002Fo-Pl; Thu, 30 Mar 2017 23:14:52 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7D609015-399F-4A3F-9BA3-28CFFC783D4E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 30 Mar 2017 16:14:49 -0500 In-Reply-To: Cc: tsvwg IETF list , David Ros To: Ingemar Johansson S References: X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 53406 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.031, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 80F851E29676E43D0AFE3B4F8FD387406996176F X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 110 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) 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, 30 Mar 2017 21:15:17 -0000 --Apple-Mail=_7D609015-399F-4A3F-9BA3-28CFFC783D4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks Ingemar for your interesting presentation today: = https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessb-7-transpo= rt-protocol-feedback-overhead-issues-and-solutions-00.pdf = I wanted to share with you, and the list, that David Ros (one of the = original authors of ACK-CC, RFC 5690) and I once advised a master = student to: - implement ACK-CC - test it - analyze all RFC 2119 - style keywords in RFC 5690, to see how they = should be changed (if at all) in a possible update Back then, our thinking was that we could write a paper about it, and = try to get this deployed as a way of doing the Experiment and moving = this to PS status. However, we were less and less sure about the real value of this - = whether actual networks need this? Then, we had less and less time = available and at some point dropped the ball. I of course found it interesting to hear that it *is* a real problem, = even today. Anyway: this master thesis is available here: = http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mastersthesis-m= ariusno.pdf = and I think I can safely say on behalf of David, Marius (the master = student who did this) and myself that we=E2=80=99re happy if someone = picks this up and continues the work. It would require some digging, but I might also still have the code = lying around somewhere - for some outdated version of Linux=E2=80=A6 Cheers, Michael --Apple-Mail=_7D609015-399F-4A3F-9BA3-28CFFC783D4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Thanks = Ingemar for your interesting presentation today:
https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sess= b-7-transport-protocol-feedback-overhead-issues-and-solutions-00.pdf

I wanted to = share with you, and the list, that David Ros  (one of the original = authors of ACK-CC, RFC 5690) and I once advised a master student = to:
- implement ACK-CC
- test = it
- analyze all RFC 2119 - style keywords in RFC = 5690, to see how they should be changed (if at all) in a possible = update

Back = then, our thinking was that we could write a paper about it, and try to = get this deployed as a way of doing the Experiment and moving this to PS = status.
However, we were less and less sure about = the real value of this - whether actual networks need this? Then, we had = less and less time available and at some point dropped the = ball.
I of course found it interesting to hear that = it *is* a real problem, even today.

Anyway: this master thesis is available = here:  http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/mast= ersthesis-mariusno.pdf
and I think I can safely = say on behalf of David, Marius (the master student who did this) and = myself that we=E2=80=99re happy if someone picks this up and continues = the work.
It would require some digging, but I = might also still have the code lying around somewhere - for some = outdated version of Linux=E2=80=A6

Cheers,
Michael

= --Apple-Mail=_7D609015-399F-4A3F-9BA3-28CFFC783D4E-- From nobody Thu Mar 30 15:17:28 2017 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 42F4712426E for ; Thu, 30 Mar 2017 15:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 T_YDRPcE7s8q for ; Thu, 30 Mar 2017 15:17:21 -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 C28A312961E for ; Thu, 30 Mar 2017 15:17:18 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l7so28977557ioe.3 for ; Thu, 30 Mar 2017 15:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hl6ATgXMPHOtz7ksrTW3Sn8j7usHTyZ+a/eTBDC1pG8=; b=fiiBiuSRw/um+wiYDjZZvB7ynpD+OV81XFyG3C5N0j20gqTUu8LRbU9bJDLKFMvx5v S0NyeBAHrX8x9UyURgCx44yoVSv/XDW9ltdhbxLWQ8gYgCKx468HmNRFavlC2kxGztqH MuxeHRDrOjcbl1NHcpy7/zpk7E04HzZzMrD7mAf4puzHbl00UKWlAX8lWiZvyKRFNdzb vhFvThbktJfe0uFRmbgb3KkhIWPksvEYeFNKry9ZRhgrnGCzef0O02HCotRvjN3Q7Y5v B5CC85JdfVRv8v2wEasXRRTO+hoO0LYByMJL4H/gO/uFIQbKUZAUPXEnhBfEK2sAy78Q dT5Q== 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=hl6ATgXMPHOtz7ksrTW3Sn8j7usHTyZ+a/eTBDC1pG8=; b=EuKU+BAApnuAriRhlPpWIl7ilGbe15ZTlkSnvUnG0g1X8tbDu63uJjV1KuUxqrZ5U/ hWdtDyzJXmG6bBPs/Xc1zIIAlEQiNDwrc1JVA9zTKTJF7+RpSOLyNGWpexYukwN15TOp CQvYL7aGuMrOywKBBIdCAbbs9CWFD5M75D9dRJIGSb5rPf2t+MMXg+KJzolf8KWEMDbm 5bx/XIo90DoO0b4wn5frhQp1u4iyjPdeah7XzdnAyMyy7cE1S/zyzaTC9DCfjSzmxjnJ zNksWnURDWLZybDjqYBOmWJn6Nye133y1FScaNdJ9BBhUH045UMGyzvTdNQHx3KesAJa 24Vg== X-Gm-Message-State: AFeK/H2C/Qv/HtYHCWhqPtjY1jamwySOyudMmFSJUeYDLfnVRsxPjt4bEwdjhGS2baakz3dP1HWu2w5XUpwKKCh1 X-Received: by 10.107.164.36 with SMTP id n36mr3253110ioe.103.1490912237981; Thu, 30 Mar 2017 15:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.24 with HTTP; Thu, 30 Mar 2017 15:16:37 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 30 Mar 2017 15:16:37 -0700 Message-ID: To: Michael Welzl Cc: Ingemar Johansson S , tsvwg IETF list , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=001a114220ac567be4054bfa0e23 Archived-At: Subject: Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) 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, 30 Mar 2017 22:17:22 -0000 --001a114220ac567be4054bfa0e23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable regarding the question in the slide 5. "Is immediate ACK needed for out of order segments if RACK is used ?" The answer is both yes and no: a timely feedback is appreciated (yes). But RACK does not need 100 DUPACKs each telling one more packet is delivered out of order (no). In other words if the ACK is timely and precise about the delivery process, RACK would work well (so does BBR). However this can go terribly wrong if the middle-box sends only the last ACK/SACK. It has happened in one major cloud platform. On Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl wrote: > Hi, > > Thanks Ingemar for your interesting presentation today: > https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-s > essb-7-transport-protocol-feedback-overhead-issues-and-solutions-00.pdf > > I wanted to share with you, and the list, that David Ros (one of the > original authors of ACK-CC, RFC 5690) and I once advised a master student > to: > - implement ACK-CC > - test it > - analyze all RFC 2119 - style keywords in RFC 5690, to see how they > should be changed (if at all) in a possible update > > Back then, our thinking was that we could write a paper about it, and try > to get this deployed as a way of doing the Experiment and moving this to = PS > status. > However, we were less and less sure about the real value of this - whethe= r > actual networks need this? Then, we had less and less time available and = at > some point dropped the ball. > I of course found it interesting to hear that it *is* a real problem, eve= n > today. > > Anyway: this master thesis is available here: > http://heim.ifi.uio.no/michawe/teaching/dipls/marius-olsen/ > mastersthesis-mariusno.pdf > and I think I can safely say on behalf of David, Marius (the master > student who did this) and myself that we=E2=80=99re happy if someone pick= s this up > and continues the work. > It would require some digging, but I might also still have the code lying > around somewhere - for some outdated version of Linux=E2=80=A6 > > Cheers, > Michael > > --001a114220ac567be4054bfa0e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
regarding the question in the slide 5.
"Is immedi= ate ACK needed for out of order segments if RACK is used ?"
=
The answer is both yes and no: a timely feedback is apprecia= ted (yes). But RACK does not need 100 DUPACKs each telling one more packet = is delivered out of order (no). In other words if the ACK is timely and pre= cise about the delivery process, RACK would work well (so does BBR). Howeve= r this can go terribly wrong if the middle-box sends only the last ACK/SACK= . It has happened in one major cloud platform.

On = Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl <michawe@ifi.uio.no>= wrote:
Hi,
Thanks Ingemar for your interesting presentation today:

I wanted to share with = you, and the list, that David Ros =C2=A0(one of the original authors of ACK= -CC, RFC 5690) and I once advised a master student to:
- implemen= t ACK-CC
- test it
- analyze all RFC 2119 - style keywo= rds in RFC 5690, to see how they should be changed (if at all) in a possibl= e update

Back then, our thinking was that we could= write a paper about it, and try to get this deployed as a way of doing the= Experiment and moving this to PS status.
However, we were less a= nd less sure about the real value of this - whether actual networks need th= is? Then, we had less and less time available and at some point dropped the= ball.
I of course found it interesting to hear that it *is* a re= al problem, even today.

and I think I can safely say on behalf of David,= Marius (the master student who did this) and myself that we=E2=80=99re hap= py if someone picks this up and continues the work.
It would requ= ire some digging, but I might also still have the code lying around somewhe= re - for some outdated version of Linux=E2=80=A6

C= heers,
Michael


<= /div>
--001a114220ac567be4054bfa0e23-- From nobody Thu Mar 30 15:45:28 2017 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 0144D12945D for ; Thu, 30 Mar 2017 15:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 XP27Rj1ocmZu for ; Thu, 30 Mar 2017 15:45:16 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00136.outbound.protection.outlook.com [40.107.0.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE54126DDF for ; Thu, 30 Mar 2017 15:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zC4kJ7aOa7KFgSQiRNDj/ya89oMI0hVg3dD0t6n69lg=; b=gcIZSGYEhygYwiAepkhkQiUuw3MD38RnxDkGGzK8emOQU4xfoxhDl5BlHMvxUkH+TU9qhnAIBKLViyKNs7pYqqHvLLap027HMMkumEgfEHNEvuiShGzOM/AxRJDwTOe7fE3zp2QHbglZOdbKCkNzXP3Xxv7It/tueauIvkWw1wg= Received: from AM4PR0701MB2115.eurprd07.prod.outlook.com (10.167.132.136) by AM4PR0701MB2116.eurprd07.prod.outlook.com (10.167.132.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 30 Mar 2017 22:45:14 +0000 Received: from AM4PR0701MB2115.eurprd07.prod.outlook.com ([10.167.132.136]) by AM4PR0701MB2115.eurprd07.prod.outlook.com ([10.167.132.136]) with mapi id 15.01.1005.014; Thu, 30 Mar 2017 22:45:14 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: Bob Briscoe , Ingemar Johansson S , tsvwg IETF list Thread-Topic: [tsvwg] transport protocol feedback overhead Thread-Index: AQHSqZK8chKH6SA4AUqCptCh3WK2gaGt+tlw Date: Thu, 30 Mar 2017 22:45:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [31.133.147.129] x-microsoft-exchange-diagnostics: 1; AM4PR0701MB2116; 7:CYXOFWHt3uvf5nMjN+/etcriQGzvYQl4QgEndn6L7Hy4XTAKb4FQPOwhqTZc1WbG3DGGg0dIpmYg2Z8WGFezYxUY90nbsBn2Ydf1rtxpsJhGs/iCjYiN8zKuDPDMLgG1Q/PUx8z5r3zSmkIe45Pl3Hwipyvac8cT1DRVnw+otZ8WCa+HadNCoxm9Sk7jaogcuYco3r5AVSHYQzm/VG+3l3FQtKEhX4u4UYVtCrIxWVsEDsystkWayT96S6jw+JMLq8hDjqbSTDPSCPzOBEpT6CV+1TKcH52bOAvEk/JQcvlXQ39ZJiUnr7FNWdjTbObI0JfVxJ4/UOWRGMlcnX4+xA== x-ms-office365-filtering-correlation-id: 50d9075e-7b60-4c16-a262-08d477be6e45 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR0701MB2116; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:AM4PR0701MB2116; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0701MB2116; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39860400002)(39410400002)(39840400002)(13464003)(3846002)(102836003)(6116002)(74316002)(305945005)(53546009)(50986999)(76176999)(189998001)(7696004)(54356999)(53376002)(8936002)(6436002)(81166006)(6506006)(8676002)(6246003)(25786009)(5660300001)(9686003)(966004)(7736002)(99286003)(53936002)(55016002)(77096006)(6306002)(38730400002)(66066001)(122556002)(33656002)(2906002)(86362001)(3660700001)(3280700002)(2950100002)(229853002)(2900100001)(90052001)(336755003)(18886065003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0701MB2116; H:AM4PR0701MB2115.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 22:45:14.2660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2116 Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead 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, 30 Mar 2017 22:45:19 -0000 SSBhZ3JlZSB0aGF0IEFDS3MgZ2l2aW5nIHRpbWluZyBkZXRhaWxzIG9mIHRoZSBsYXN0IHBhY2tl dCBhcnJpdmFscyB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bC4gSXQgd2lsbCBhbHNvIGF2b2lkIGRlbGF5 IG5vaXNlIGluIHRoZSBBQ0sgcGF0aC4NCg0KS29lbi4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEJvYiBCcmlzY29lDQo+IFNlbnQ6IGRvbmRlcmRhZyAzMCBtYWFydCAyMDE3 IDIyOjE4DQo+IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbT47IHRzdndnIElFVEYNCj4gbGlzdCA8dHN2d2dAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFt0c3Z3Z10gdHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkDQo+IA0KPiBJ bmdlbWFyLCBsaXN0LA0KPiANCj4gSSBzZWVtZWQgdG8gZ2V0IGJsb2NrZWQgZnJvbSB0YWxraW5n IGFmdGVyIEkgd2FzIHRyeWluZyB0byBiZSBwb2xpdGUgLQ0KPiBsZXR0aW5nIHlvdSBmaW5pc2gg eW91ciB0YWxrLi4uDQo+IA0KPiBZb3UgZGVzY3JpYmVkIG9uZSBwcm9ibGVtOg0KPiAgIChBKSBJ biBtb2JpbGUgKGFuZCBvdGhlciBuZXR3b3JrcykgIHVwc3RyZWFtIEFDSyBsb2FkIGlzIGEgcHJv YmxlbS4NCj4gDQo+IFRoZXJlIGlzIGEgY29tcGxlbWVudGFyeSBwcm9ibGVtIHRvbzoNCj4gKEIp IENhcGFjaXR5IHZhcmlhdGlvbiBpcyBnZXR0aW5nIGh1Z2UgYXMgcmFkaW8gd2F2ZWxlbmd0aCBp bmNyZWFzZXMuIFNvDQo+IGl0J3MgdXNlZnVsIGZvciB0aGUgc2VuZGVyIHRvIHdhdGNoIHRoZSB0 aW1pbmcgb2YgdGhlIEFDS3MgdG8gYmUgYWJsZSB0bw0KPiB0cmFjayBjaGFuZ2VzIGluIGNhcGFj aXR5IGFzIGZhc3QgYXMgcG9zc2libGUuIEl0J3MgYWxzbyB1c2VmdWwgdG8gYmUNCj4gYWJsZSB0 byB2YXJ5IHRoZSBzcGFjaW5nIGJldHdlZW4gdGhlIHBhY2tldHMgeW91IHNlbmQgdG8gcHJvYmUg Zm9yDQo+IGluY3JlYXNlcyBpbiBjYXBhY2l0eSBieSB3YXRjaGluZyB0aGUgQUNLIHNwYWNpbmcg aW4gcmVzcG9uc2UuDQo+IA0KPiBUaGVzZSB0d28gYXJlIGluIHRlbnNpb24gLSAoQSkgd2FudHMg bGVzcyBBQ0tzLCAoQikgd2FudHMgdGhlbSBhbGwuDQo+IA0KPiBBIHBvc3NpYmxlIHNvbHV0aW9u LCBpcyBhIGRhdGEgc3RydWN0dXJlIGluIGEgc3RyZXRjaCBBQ0sgdG8gYmUgYWJsZSB0bw0KPiBy ZXBvcnQgdGhlIHRpbWUgb2YgYXJyaXZhbCBvZiBhbGwgdGhlIHByZXZpb3VzIGRhdGEgcGFja2V0 cyAoaWUuIHRoZQ0KPiBwYWNrZXRzIHRoYXQgdGhlIHN0cmV0Y2ggQUNLIGlzIEFDS2luZy4NCj4g DQo+IEV2ZW4gdGhvIHRoaXMgaW5mbyB3aWxsIGFycml2ZSBhdCB0aGUgc2VuZGVyIGxhdGVyIHRo YW4gaXQgd291bGQgaGF2ZQ0KPiBkb25lIGlmIHRoZSBBQ0tzIGhhZCBub3QgYmVlbiBzdXBwcmVz c2VkLCBhcyBsb25nIGFzIHlvdSBhcmUgc3RpbGwNCj4gZ2V0dGluZyBhIHJlYXNvbmFibGUgbnVt YmVyIG9mIEFDS3MgZXZlcnkgUlRULCBpdCByZXNvbHZlcyB0aGUgdGVuc2lvbg0KPiBiZXR3ZWVu IEEgYW5kIEIuDQo+IA0KPiBUaG91Z2h0cz8NCj4gRG9lcyB0aGlzIGlkZWEgYWxyZWFkeSBleGlz dD8NCj4gDQo+IA0KPiANCj4gQm9iDQo+IA0KPiBQUy4gQXBvbG9naWVzIGZvciBkcm9wcGluZyBh biBpbm5vdmF0aXZlIGlkZWEgaW50byBhIHN0YW5kYXJkcyBtZWV0aW5nLg0KPiBUaGlzIHByb2Jh Ymx5IG91Z2h0IHRvIGJlIGEgcmVzZWFyY2ggcGFwZXIgZmlyc3QuDQo+IA0KPiANCj4gLS0NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBfX19fX18NCj4gQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQo= From nobody Thu Mar 30 17:28:34 2017 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 E95EA1296FA for ; Thu, 30 Mar 2017 17:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Y5PxGxTx5Tw9 for ; Thu, 30 Mar 2017 17:28:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 A3CD8127B73 for ; Thu, 30 Mar 2017 17:28:31 -0700 (PDT) Received: from [128.9.184.172] ([128.9.184.172]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2V0SDNR006673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Mar 2017 17:28:14 -0700 (PDT) To: tsvwg From: Joe Touch Cc: Mark Townsley Message-ID: <77bbceb7-d905-d4b0-a250-41450ee56645@isi.edu> Date: Thu, 30 Mar 2017 17:28:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback 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, 31 Mar 2017 00:28:33 -0000 Hi, all, Discussing this off-list with my co-author on the draft-ietf-intarea-tunnels doc (Mark Townsley, cc'd), we was wondering what has been done to validate this work against the potential for layered congestion interference? I.e., propagating ECN from inside the tunnel to outside (RFC 6040) is safe, but using that information to govern tunnel admission seems like it's using ECN to determine per-hop forwarding. I would expect that to be the purview of the router where the tunnel is attached (where the tunnel ingress and egress act as *interfaces* at either routers or hosts where the tunnel originates/terminates - as per draft-ietf-intarea-tunnels). IMO, there are two clearly valid approaches (which have already been addressed by RFCs): 1) use the intra-tunnel ECN to trigger circuit breakers (RFC 8084) 2) propagate the intra-tunnel ECN to outside the tunnel (RFC 6040) However, this document appears to recommend an approach that results in layered congestion control, but doesn't appear to address decoupling interactions with E2E congestion control (e.g., TCP, DCCP, SCTP), nor does it seem to present any analysis (incl. experiments) to demonstrate that this isn't a concern. In fact, it mentions these protocols only in passing in the introduction. Has this been addressed? If not, can it be? Thanks, Joe From nobody Fri Mar 31 07:08:17 2017 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 BAB45129871 for ; Fri, 31 Mar 2017 07:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 M0LnjzaJlbJT for ; Fri, 31 Mar 2017 07:08:14 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 5BCE31297BF for ; Fri, 31 Mar 2017 07:08:13 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l7so40165927ioe.3 for ; Fri, 31 Mar 2017 07:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=QfjXLU24GaiGxX6gwdHAYtMLvxIzfzFxLKDf2MDHlzI=; b=Tj4igjtogMlCXe5fq5/wTKmy0flCupOE8C/xEtjj6LJcQ7iefYRFtKV2waboExmXeL eF3hDYAX0wIIsSZ93mhhShfFDPgs7rk8kEOFuISXxv6sWyICG9OTYxIrhEYXM7eKnPPq l7hPhAhXbTWTw1RbJBc7LUJGF+khvCCxbhYNR9Rbw1hLeqPz3KrTBVmGE5vIoX0Z6U01 xPQoMzFrKEQLRbdoBA66FKRaOQ/amiFWTZs4j1j1poNhVyzIObZZxxGbbFXudcI9yc6l yYw5UpWZ9YK06CM+F6Ro0WX53yRZ4TaA7pNutjV35r3JNMN24dzFgfdjXODKy+qmcdXP ERSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=QfjXLU24GaiGxX6gwdHAYtMLvxIzfzFxLKDf2MDHlzI=; b=dH10Ev9ydf29hi8E7TVqYHHEw13RblQuNNWrRws8VT+lMrXKdhWofZDidEmFcri7UD 1ui4Wff2MaGTUsRIaCNVHg+GOUr/iyyqU8ldmf/EHGdfmy2lWFgNxViZUnXrwa05CQKT hQXFaSTVV6lHeTBA8ulAKmhjwcbP19LfYnsnqr4Q/yol+jeezViwrZ+JKSjVrImzZyqm CshQ3B0SalQv2JF9ttnF2orpZLxNSZAO/fSwX1AuC4a/bd6/7lLPo6tqT/Fn3hIVpOYv a+abEVbI0ExtbHa8EU+zAtvPEkoncoiofWQqsaoL7zuTGqs/Rdvev/WgIO+iV0NKg/SS ddKg== X-Gm-Message-State: AFeK/H2C7f1loYVlwI+fI0N8TeYT5cLoy7MiDE/dF6I9HykvDCbYRkUTJLxSunkLdc0VJQ== X-Received: by 10.107.30.213 with SMTP id e204mr3444611ioe.203.1490969292528; Fri, 31 Mar 2017 07:08:12 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id x83sm1289248ita.28.2017.03.31.07.08.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 07:08:12 -0700 (PDT) To: "tsvwg@ietf.org" From: Wesley Eddy Message-ID: Date: Fri, 31 Mar 2017 10:08:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] confirming adoption of L4S drafts 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, 31 Mar 2017 14:08:16 -0000 Hello, this is a note to confirm that due to the positve response at the last couple IETF meetings and on the mailing list, and currently no negative responses, we (TSVWG co-chairs) think there's consensus to adopt the set of 3 L4S drafts. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id We've asked the authors to wait a week, just to confirm this with the mailing list, before submitting the documents as draft-ietf-tsvwg-... Please don't hesitate to start reviewing and discussing the open items Koen highlighted yesterday. From nobody Fri Mar 31 09:40:38 2017 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 DBE951296FD for ; Fri, 31 Mar 2017 09:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 4_oyJ2gcX5i1 for ; Fri, 31 Mar 2017 09:40:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 10E0E129883 for ; Fri, 31 Mar 2017 09:40:24 -0700 (PDT) X-AuditID: c1b4fb2d-dadfe700000033e1-9b-58de867306e2 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id A0.6E.13281.3768ED85; Fri, 31 Mar 2017 18:40:23 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 31 Mar 2017 18:40:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hqGK0DlvyxgdIup+S7gF47Trae3bNdogzolhm7xzw50=; b=PWwt09B704udPVZfw218sxfzKForkulYRHZFgb9P7Gnu0CcfM7CmcXuwxiF/u/AN99RrrBtTb+vjvSkqaR5oJfd6EisHnPWnBkGhzZJ0EJaBbO6x2fkF2/lVkSmEDBEYUUU3FxIgORA8Jpp3tMVf8dQdKKNMwWzUs3S60XWMEHs= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 16:40:18 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.014; Fri, 31 Mar 2017 16:40:18 +0000 From: Ingemar Johansson S To: Michael Welzl CC: tsvwg IETF list , David Ros Thread-Topic: TCP ACK-CC (re: Transport protocol feedback overhead ) Thread-Index: AQHSqZq/4RHrIyBgtUCygnpI+u3trKGvJkGQ Date: Fri, 31 Mar 2017 16:40:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ifi.uio.no; dkim=none (message not signed) header.d=none;ifi.uio.no; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.88] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:95N3nKwEQsvR44KXYjFNC1fdcY0jieIqpVnUtMu9vvPkTZD+uEcw5jHAYDozlUY4HmeCIPIHRtz8grztYOHwHCecUPAYfBWCFOyHZqlyL//mxxgAjODeU8eAIw21ZSktANEp8keCu1rhwMlxHMwbqCP4EFwBJ4UYtNtbgoS9EAQ/AHIYWL5qCF0l44M6nXg2VsVDfDu44i8Qaqtp7P5MwaQa8Xe1LHbiwvDamIWCI+TM8YgplDwRopA2D9U80yGkIj9e1QcpOjaykFBSmOf4u2ZpsrLX8A+y8VodPv2C7UkDnroT4uLl1MGX9aBANR3wajZ0LMrHBwMtsBYb0fHKMw== x-ms-office365-filtering-correlation-id: aadb4b96-91b3-4533-723f-08d478549dab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39860400002)(39400400002)(39410400002)(39850400002)(966004)(5660300001)(25786009)(53546009)(229853002)(7696004)(6916009)(7906003)(77096006)(2950100002)(3660700001)(55016002)(6506006)(74316002)(606005)(54896002)(54906002)(53936002)(6306002)(6436002)(99286003)(9686003)(236005)(2906002)(8936002)(2900100001)(3280700002)(81166006)(8676002)(122556002)(50986999)(33656002)(86362001)(76176999)(54356999)(66066001)(4326008)(6116002)(38730400002)(19609705001)(189998001)(110136004)(790700001)(102836003)(6246003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3480AF734961C23D009F19EC2370DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 16:40:18.2677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyzUYRzH93x/3H2pq6dDPpNGt2lYiNrSyKSUtVFambTi4hsWR/dFabOp xo6rIa0ip/xo0WWmmnPpB2fJj4kaS3J+zN1iTPVHIzbL3aPNf6/n834/n8/7+ezhaGkT68Ql KzJ4pUKeIhPZMmXRukivK/lj0btnzJv9G2t6RP6LfXrWv3POKAqmw2pr/1JhWu0kHdas6hCf oGNsAxP4lOQsXukTFGeb9Cd/iE6fv3j1jlnN5iJVQiGy4QDvBc37D3QhsuWkuBFBx3Q9Iocu BN8GV0QWF4Nv02DqwUS4R0H1S9OaqxNByc+bjMUlwoFQb1hAFrbHO6HrqdZ6m8bBYB4doQoR x9nhQ6DSbCCWw1BYsyQm7AdNxmGWDHOD0rYha12CY6BGd8vaRooz4X5fg9Vjg4Pg86KKsjDC 22F8YYwhoxxhxPSIIk/DUPumnybsADNTK6wlM8JFq5nHxxkiuMK8pldEWE2DeTmDcDiotXVi wjkwUZC71jQZVAMtLOFj8HB4grI0BdxPQcPy7NoFZ5iv0CMitLPQVaK2xrDDTmAcLECEnWF6 9C1bjNzL1yUvX10SjdOgts6z3LqALdBdZmJI2QMaX/sQ9w64q54UE3aHvAqNeH39MRI/Qw4C LwipiX57vHllcrwgpCm8FXzGC7T6kdpfLXu1IO3sQQPCHJJtlEzEjUVLWXmWkJ1qQMDRMnsJ dX61JEmQZ1/jlWmxyswUXjCgbRwjc5QEvxuIluJEeQZ/iefTeeV/leJsnHJRxGVnveH6pG/r Vub311BtdejHLD5e7huy3yk8pzLKsRHUAVXiPPMPXf3x72ef7BqYVMxxF7zsZx6M9VQ9d3Yz RppOuVTqpxuWXD1+BfHGk9LuT73VRarY/oEbm5oDjj7Iat2HvSO+nHGZOtJ2INXVTpd9zqf4 tNyuM0Q/GquLKpUxQpLc15NWCvJ/0vTuUUQDAAA= Archived-At: Subject: Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) 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, 31 Mar 2017 16:40:37 -0000 --_000_DB4PR07MB3480AF734961C23D009F19EC2370DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCBhbmQgb3RoZXJzLg0KVGhhbmtzIGZvciB0aGUgdmVyeSBnb29kIGZlZWRiYWNr IGZyb20gYWxsIG9mIHlvdS4NCg0KSXQgaXMgYSBiaXQgb2YgYSBjaGFsbGVuZ2UgdG8gZGV0ZXJt aW5lIGhvdyBvbmUgc2hvdWxkIHB1cnN1ZSB0aGlzIG1hdHRlciwgaXMgQkNQIHRoZSBiZXN0IHdh eSB0byBnbyBvciBhcmUgdGhlcmUgdG9vIG1hbnkgZGlmZmVyZW5jZXMgIGJldHdlZW4gdHJhbnNw b3J0IHByb3RvY29scyA/Lg0KVGhlcmUgaXMgYSBjZXJ0YWluIHJpc2sgdGhhdCB3ZSBvcGVuIHVw IGEgY2FuIG9mIHdvcm1zID8sIHRoZSBsYXR0ZXIgaXMgb2YgY291cnNlIGEgY2VydGFpbiBpbmRp Y2F0aW9uIHRoYXQgbWlkZGxlYm94IG1lZGRsaW5nIHdpdGggQUNLcyBzaG91bGQgYmUgYXZvaWRl ZC4NCg0KVGhhbmtzIGZvciB0aGUgcmVmZXJlbmNlIHRvIHRoZSBtYXN0ZXIgdGhlc2lzLCBJIGhh dmUgcGxlbnR5IG9mIHRpbWUgdG8gcmVhZCBpdCBvbiBteSB3YXkgYmFjay4NCg0KL0luZ2VtYXIN Cg0KRnJvbTogTWljaGFlbCBXZWx6bCBbbWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ub10NClNlbnQ6 IGRlbiAzMCBtYXJzIDIwMTcgMjM6MTUNClRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCkNjOiB0c3Z3ZyBJRVRGIGxpc3QgPHRzdndnQGll dGYub3JnPjsgRGF2aWQgUm9zIDxkcm9zQHNpbXVsYS5ubz4NClN1YmplY3Q6IFRDUCBBQ0stQ0Mg KHJlOiBUcmFuc3BvcnQgcHJvdG9jb2wgZmVlZGJhY2sgb3ZlcmhlYWQgKQ0KDQpIaSwNCg0KVGhh bmtzIEluZ2VtYXIgZm9yIHlvdXIgaW50ZXJlc3RpbmcgcHJlc2VudGF0aW9uIHRvZGF5Og0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3Z3Zy1z ZXNzYi03LXRyYW5zcG9ydC1wcm90b2NvbC1mZWVkYmFjay1vdmVyaGVhZC1pc3N1ZXMtYW5kLXNv bHV0aW9ucy0wMC5wZGYNCg0KSSB3YW50ZWQgdG8gc2hhcmUgd2l0aCB5b3UsIGFuZCB0aGUgbGlz dCwgdGhhdCBEYXZpZCBSb3MgIChvbmUgb2YgdGhlIG9yaWdpbmFsIGF1dGhvcnMgb2YgQUNLLUND LCBSRkMgNTY5MCkgYW5kIEkgb25jZSBhZHZpc2VkIGEgbWFzdGVyIHN0dWRlbnQgdG86DQotIGlt cGxlbWVudCBBQ0stQ0MNCi0gdGVzdCBpdA0KLSBhbmFseXplIGFsbCBSRkMgMjExOSAtIHN0eWxl IGtleXdvcmRzIGluIFJGQyA1NjkwLCB0byBzZWUgaG93IHRoZXkgc2hvdWxkIGJlIGNoYW5nZWQg KGlmIGF0IGFsbCkgaW4gYSBwb3NzaWJsZSB1cGRhdGUNCg0KQmFjayB0aGVuLCBvdXIgdGhpbmtp bmcgd2FzIHRoYXQgd2UgY291bGQgd3JpdGUgYSBwYXBlciBhYm91dCBpdCwgYW5kIHRyeSB0byBn ZXQgdGhpcyBkZXBsb3llZCBhcyBhIHdheSBvZiBkb2luZyB0aGUgRXhwZXJpbWVudCBhbmQgbW92 aW5nIHRoaXMgdG8gUFMgc3RhdHVzLg0KSG93ZXZlciwgd2Ugd2VyZSBsZXNzIGFuZCBsZXNzIHN1 cmUgYWJvdXQgdGhlIHJlYWwgdmFsdWUgb2YgdGhpcyAtIHdoZXRoZXIgYWN0dWFsIG5ldHdvcmtz IG5lZWQgdGhpcz8gVGhlbiwgd2UgaGFkIGxlc3MgYW5kIGxlc3MgdGltZSBhdmFpbGFibGUgYW5k IGF0IHNvbWUgcG9pbnQgZHJvcHBlZCB0aGUgYmFsbC4NCkkgb2YgY291cnNlIGZvdW5kIGl0IGlu dGVyZXN0aW5nIHRvIGhlYXIgdGhhdCBpdCAqaXMqIGEgcmVhbCBwcm9ibGVtLCBldmVuIHRvZGF5 Lg0KDQpBbnl3YXk6IHRoaXMgbWFzdGVyIHRoZXNpcyBpcyBhdmFpbGFibGUgaGVyZTogIGh0dHA6 Ly9oZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9tYXJpdXMtb2xzZW4vbWFz dGVyc3RoZXNpcy1tYXJpdXNuby5wZGYNCmFuZCBJIHRoaW5rIEkgY2FuIHNhZmVseSBzYXkgb24g YmVoYWxmIG9mIERhdmlkLCBNYXJpdXMgKHRoZSBtYXN0ZXIgc3R1ZGVudCB3aG8gZGlkIHRoaXMp IGFuZCBteXNlbGYgdGhhdCB3ZeKAmXJlIGhhcHB5IGlmIHNvbWVvbmUgcGlja3MgdGhpcyB1cCBh bmQgY29udGludWVzIHRoZSB3b3JrLg0KSXQgd291bGQgcmVxdWlyZSBzb21lIGRpZ2dpbmcsIGJ1 dCBJIG1pZ2h0IGFsc28gc3RpbGwgaGF2ZSB0aGUgY29kZSBseWluZyBhcm91bmQgc29tZXdoZXJl IC0gZm9yIHNvbWUgb3V0ZGF0ZWQgdmVyc2lvbiBvZiBMaW51eOKApg0KDQpDaGVlcnMsDQpNaWNo YWVsDQoNCg== --_000_DB4PR07MB3480AF734961C23D009F19EC2370DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVw dCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5IaSBNaWNoYWVsIGFuZCBvdGhlcnMuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3Ig dGhlIHZlcnkgZ29vZCBmZWVkYmFjayBmcm9tIGFsbCBvZiB5b3UuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SXQgaXMgYSBiaXQgb2YgYSBjaGFsbGVuZ2UgdG8gZGV0ZXJtaW5lIGhvdyBvbmUgc2hvdWxkIHB1 cnN1ZSB0aGlzIG1hdHRlciwgaXMgQkNQIHRoZSBiZXN0IHdheSB0byBnbyBvciBhcmUgdGhlcmUg dG9vIG1hbnkgZGlmZmVyZW5jZXMmbmJzcDsgYmV0d2VlbiB0cmFuc3BvcnQgcHJvdG9jb2xzID8u DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoZXJlIGlzIGEgY2VydGFpbiByaXNrIHRoYXQgd2Ugb3BlbiB1cCBhIGNhbiBvZiB3 b3JtcyA/LCB0aGUgbGF0dGVyIGlzIG9mIGNvdXJzZSBhIGNlcnRhaW4gaW5kaWNhdGlvbiB0aGF0 IG1pZGRsZWJveCBtZWRkbGluZyB3aXRoIEFDS3Mgc2hvdWxkIGJlIGF2b2lkZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZSB0byB0aGUgbWFzdGVyIHRoZXNpcywgSSBo YXZlIHBsZW50eSBvZiB0aW1lIHRvIHJlYWQgaXQgb24gbXkgd2F5IGJhY2suPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPi9JbmdlbWFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gTWljaGFlbCBXZWx6bCBbbWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ub10N Cjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMzAgbWFycyAyMDE3IDIzOjE1PGJyPg0KPGI+VG86PC9i PiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRzdndnIElFVEYgbGlzdCAmbHQ7dHN2d2dAaWV0Zi5vcmcm Z3Q7OyBEYXZpZCBSb3MgJmx0O2Ryb3NAc2ltdWxhLm5vJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBUQ1AgQUNLLUNDIChyZTogVHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkICk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBJbmdlbWFyIGZv ciB5b3VyIGludGVyZXN0aW5nIHByZXNlbnRhdGlvbiB0b2RheTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtdHN2d2ctc2Vzc2ItNy10cmFu c3BvcnQtcHJvdG9jb2wtZmVlZGJhY2stb3ZlcmhlYWQtaXNzdWVzLWFuZC1zb2x1dGlvbnMtMDAu cGRmIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4 LXRzdndnLXNlc3NiLTctdHJhbnNwb3J0LXByb3RvY29sLWZlZWRiYWNrLW92ZXJoZWFkLWlzc3Vl cy1hbmQtc29sdXRpb25zLTAwLnBkZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YW50ZWQgdG8gc2hhcmUgd2l0aCB5b3UsIGFuZCB0 aGUgbGlzdCwgdGhhdCBEYXZpZCBSb3MgJm5ic3A7KG9uZSBvZiB0aGUgb3JpZ2luYWwgYXV0aG9y cyBvZiBBQ0stQ0MsIFJGQyA1NjkwKSBhbmQgSSBvbmNlIGFkdmlzZWQgYSBtYXN0ZXIgc3R1ZGVu dCB0bzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0gaW1wbGVtZW50IEFDSy1DQzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSB0ZXN0IGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGFuYWx5emUgYWxsIFJGQyAyMTE5IC0gc3R5bGUga2V5d29y ZHMgaW4gUkZDIDU2OTAsIHRvIHNlZSBob3cgdGhleSBzaG91bGQgYmUgY2hhbmdlZCAoaWYgYXQg YWxsKSBpbiBhIHBvc3NpYmxlIHVwZGF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWNrIHRoZW4sIG91ciB0aGlua2luZyB3YXMgdGhhdCB3 ZSBjb3VsZCB3cml0ZSBhIHBhcGVyIGFib3V0IGl0LCBhbmQgdHJ5IHRvIGdldCB0aGlzIGRlcGxv eWVkIGFzIGEgd2F5IG9mIGRvaW5nIHRoZSBFeHBlcmltZW50IGFuZCBtb3ZpbmcgdGhpcyB0byBQ UyBzdGF0dXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ib3dldmVyLCB3ZSB3ZXJlIGxlc3MgYW5kIGxlc3Mgc3VyZSBhYm91dCB0aGUgcmVhbCB2 YWx1ZSBvZiB0aGlzIC0gd2hldGhlciBhY3R1YWwgbmV0d29ya3MgbmVlZCB0aGlzPyBUaGVuLCB3 ZSBoYWQgbGVzcyBhbmQgbGVzcyB0aW1lIGF2YWlsYWJsZSBhbmQgYXQgc29tZSBwb2ludCBkcm9w cGVkIHRoZSBiYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBvZiBjb3Vyc2UgZm91bmQgaXQgaW50ZXJlc3RpbmcgdG8gaGVhciB0aGF0IGl0 ICppcyogYSByZWFsIHByb2JsZW0sIGV2ZW4gdG9kYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueXdheTogdGhpcyBtYXN0ZXIgdGhlc2lz IGlzIGF2YWlsYWJsZSBoZXJlOiAmbmJzcDs8YSBocmVmPSJodHRwOi8vaGVpbS5pZmkudWlvLm5v L21pY2hhd2UvdGVhY2hpbmcvZGlwbHMvbWFyaXVzLW9sc2VuL21hc3RlcnN0aGVzaXMtbWFyaXVz bm8ucGRmIj5odHRwOi8vaGVpbS5pZmkudWlvLm5vL21pY2hhd2UvdGVhY2hpbmcvZGlwbHMvbWFy aXVzLW9sc2VuL21hc3RlcnN0aGVzaXMtbWFyaXVzbm8ucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIEkgdGhpbmsgSSBjYW4gc2Fm ZWx5IHNheSBvbiBiZWhhbGYgb2YgRGF2aWQsIE1hcml1cyAodGhlIG1hc3RlciBzdHVkZW50IHdo byBkaWQgdGhpcykgYW5kIG15c2VsZiB0aGF0IHdl4oCZcmUgaGFwcHkgaWYgc29tZW9uZSBwaWNr cyB0aGlzIHVwIGFuZCBjb250aW51ZXMgdGhlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCByZXF1aXJlIHNvbWUgZGlnZ2lu ZywgYnV0IEkgbWlnaHQgYWxzbyBzdGlsbCBoYXZlIHRoZSBjb2RlIGx5aW5nIGFyb3VuZCBzb21l d2hlcmUgLSBmb3Igc29tZSBvdXRkYXRlZCB2ZXJzaW9uIG9mIExpbnV44oCmPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB4PR07MB3480AF734961C23D009F19EC2370DB4PR07MB348eurprd_-- From nobody Fri Mar 31 10:35:28 2017 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 C144C12996E; Fri, 31 Mar 2017 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 no4Bg4Lt4Xzd; Fri, 31 Mar 2017 10:35:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B3FE212995D; Fri, 31 Mar 2017 10:35:19 -0700 (PDT) X-AuditID: c1b4fb2d-d97ff700000033e1-f2-58de935576e4 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 54.F4.13281.5539ED85; Fri, 31 Mar 2017 19:35:17 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 31 Mar 2017 19:35:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cTmfPDGdesdSrDeh4g/dNJbNUy1zll4sqOXnQE9yxrc=; b=QLmVj0/4Hz9eKbpyxzI68Dv19pywEAG564Jwv6cEi0gLx1wBUXdpcQDB7i4/Efrg+0SqVZ+BKwI89/4leewkVbC+/wXu/jDiCLz73FHtwIv7qA62coHZ35q59SFX6/mE/jb5bQmjcbbvMpv4uyzHFyZRCnyFk7Ex3AQ7okNzEzk= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 17:35:12 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.014; Fri, 31 Mar 2017 17:35:12 +0000 From: Ingemar Johansson S To: Yuchung Cheng , Michael Welzl CC: tsvwg IETF list , "tcpm@ietf.org Extensions" Thread-Topic: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) Thread-Index: AQHSqZq/4RHrIyBgtUCygnpI+u3trKGt82KAgAFBFtA= Date: Fri, 31 Mar 2017 17:35:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.88] x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:zP2WuGBdEMojGGfyfOLtO0MlpsqaIOgtTjgHyDBZlI4bmX7Zg5XPIbL4+RI/THyJ6ElwRDbj7d1owgmPFZhWh+DGJas3wL/SEzGySl4aufERSNNHVfl+1snbxYgP8+PmZY0kQy3zQLRKNGcAZRYxFkTFmijSA1NGM72sptQ/dxTwISd6L9hDgR3/IbYrwdH7F3q2MjTJxY9H7T8Tlq09oscxTGUhT7KJyq+T3RLNZd4BcWS31VHI6zveSM1OVyuFR2WHzotmPHF+/w3nFHFbl4ujWubUg87jaI4CjipzXo+SgdAmyYEXD9NeBee/6uIcJSUZtUPY5HUHHZ9mrAGb8w== x-ms-office365-filtering-correlation-id: 7d948de1-9004-4b6a-8d91-08d4785c4953 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39450400003)(39860400002)(39400400002)(39410400002)(39840400002)(377454003)(24454002)(6436002)(53546009)(606005)(25786009)(3280700002)(3660700001)(189998001)(8676002)(81166006)(966004)(8936002)(122556002)(6506006)(2950100002)(229853002)(2906002)(790700001)(5660300001)(102836003)(6116002)(3846002)(7906003)(66066001)(19609705001)(2900100001)(6246003)(9686003)(6306002)(99286003)(54896002)(86362001)(54906002)(77096006)(33656002)(55016002)(74316002)(38730400002)(7696004)(236005)(50986999)(54356999)(76176999)(53936002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 17:35:12.6275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfO2Y6jyevSfLxENRDMvGV9WCWl4Aezq4J4A3PqQcV5YUdF g2IZhpfCIDMmikYzmYYTk8zrdJK6UhyoYJrWnKKlLS1LI7s4zwK//Z7//3mf9/m/vDQhbqdc 6bTMHEaRKZNL+EJSFd1+zifywVy0v3HIW7o12kFJXxhqedLB1Vm+dMM8yQ8iQ+tac0PV6p+8 0KYmE3GViBUGJjPytDxG4Xc2QZiq6dzkZ09k5ev7DEiJjPJSZEcDPgkqzXdBKRLSYqxFULTc T3LFMIJPqsLdgsT3CKh/puRzTiUPOgbqbMUggr8mC2kdxseBoNFvolJE0474PPRo/K0ygSNg qeEtZeX9+AL0THHtjvgitLU+sfFpeLzURliZxB4wVLiKrCzCsaCxLNr260ag6lBT1vl2OByU Q/bWHoQPwvvNOZK7yxmmF2p5XDYM6u4xgmMn+Gj+Q1nnIFyOYHxlxtZ0GCw1b3bDAC4joGW7 HHHGJVgvXxNwfAPmy8w2ToOH6yMkx3GwZBkguMNjPFhUfaM4wx0s1R2IM/QU6G89suV3hdmJ EsSxOyy/66HuI8+qPatX7aQjcBYUdhdU7b6AAxhUCyQnHwVtpx/XfQQqykwCjj2hqLpGsFev Q4JG5MQyLJuREnDCl1GkJbFsVqZvJpPTina+U3/bL5+XqGklWI8wjST7RB8S5qLFlCyPLcjQ I6AJiaOIF78jiZJlBdcZRdY1Ra6cYfXIjSYlzqKgXmO0GKfIcph0hslmFP9dHm3nqkT1Dusx I7r4xL6Sudr56V6TqrHry3DeWnFY8zG/A40BXvKnpA4vNxRLX2+0sPZhp9xeSQYOpVdsf434 gW9XNp9xMyldtOhyyHNd3Ix2ozPWJSkqJj84t0x3ExemR969kzh/5fdMiP+UDodPdBWvfd7y 6BuNMk96G5zGt4ypIS0Skk2VHfciFKzsH86w9VZKAwAA Archived-At: Subject: Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) 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, 31 Mar 2017 17:35:27 -0000 --_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZGV0YWlscy4gSXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgaXQgY2FuIGJl IHRyaWNreSB0byBnZXQgYSBkZWNlbnQgdW5kZXJzdGFuZGluZyBvZiB3aGF0IGlzIHBvc3NpYmxl IGluIHRlcm1zIG9mIEFDSyByYXRlIHJlZHVjdGlvbiBmb3IgVENQLiBUaGUgbWlkZGxlYm94IGJl aGF2aW9yIHRvIGRpc2NhcmQgZXZlcnl0aGluZyBleGNlcHQgdGhlIGxhc3QgQUNLIGhhcyBhbHNv IGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJBTjIgV0cgaW4gM0dQUC4NCg0KL0luZ2VtYXINCg0KRnJv bTogWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tXQ0KU2VudDogZGVuIDMx IG1hcnMgMjAxNyAwMDoxNw0KVG86IE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZpLnVpby5ubz4N CkNjOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bT47IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+OyB0Y3BtQGlldGYub3JnIEV4dGVu c2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBUQ1AgQUNLLUNDIChy ZTogVHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkICkNCg0KcmVnYXJkaW5nIHRo ZSBxdWVzdGlvbiBpbiB0aGUgc2xpZGUgNS4NCiJJcyBpbW1lZGlhdGUgQUNLIG5lZWRlZCBmb3Ig b3V0IG9mIG9yZGVyIHNlZ21lbnRzIGlmIFJBQ0sgaXMgdXNlZCA/Ig0KDQpUaGUgYW5zd2VyIGlz IGJvdGggeWVzIGFuZCBubzogYSB0aW1lbHkgZmVlZGJhY2sgaXMgYXBwcmVjaWF0ZWQgKHllcyku IEJ1dCBSQUNLIGRvZXMgbm90IG5lZWQgMTAwIERVUEFDS3MgZWFjaCB0ZWxsaW5nIG9uZSBtb3Jl IHBhY2tldCBpcyBkZWxpdmVyZWQgb3V0IG9mIG9yZGVyIChubykuIEluIG90aGVyIHdvcmRzIGlm IHRoZSBBQ0sgaXMgdGltZWx5IGFuZCBwcmVjaXNlIGFib3V0IHRoZSBkZWxpdmVyeSBwcm9jZXNz LCBSQUNLIHdvdWxkIHdvcmsgd2VsbCAoc28gZG9lcyBCQlIpLiBIb3dldmVyIHRoaXMgY2FuIGdv IHRlcnJpYmx5IHdyb25nIGlmIHRoZSBtaWRkbGUtYm94IHNlbmRzIG9ubHkgdGhlIGxhc3QgQUNL L1NBQ0suIEl0IGhhcyBoYXBwZW5lZCBpbiBvbmUgbWFqb3IgY2xvdWQgcGxhdGZvcm0uDQoNCk9u IFRodSwgTWFyIDMwLCAyMDE3IGF0IDI6MTQgUE0sIE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZp LnVpby5ubzxtYWlsdG86bWljaGF3ZUBpZmkudWlvLm5vPj4gd3JvdGU6DQpIaSwNCg0KVGhhbmtz IEluZ2VtYXIgZm9yIHlvdXIgaW50ZXJlc3RpbmcgcHJlc2VudGF0aW9uIHRvZGF5Og0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3Z3Zy1zZXNz Yi03LXRyYW5zcG9ydC1wcm90b2NvbC1mZWVkYmFjay1vdmVyaGVhZC1pc3N1ZXMtYW5kLXNvbHV0 aW9ucy0wMC5wZGYNCg0KSSB3YW50ZWQgdG8gc2hhcmUgd2l0aCB5b3UsIGFuZCB0aGUgbGlzdCwg dGhhdCBEYXZpZCBSb3MgIChvbmUgb2YgdGhlIG9yaWdpbmFsIGF1dGhvcnMgb2YgQUNLLUNDLCBS RkMgNTY5MCkgYW5kIEkgb25jZSBhZHZpc2VkIGEgbWFzdGVyIHN0dWRlbnQgdG86DQotIGltcGxl bWVudCBBQ0stQ0MNCi0gdGVzdCBpdA0KLSBhbmFseXplIGFsbCBSRkMgMjExOSAtIHN0eWxlIGtl eXdvcmRzIGluIFJGQyA1NjkwLCB0byBzZWUgaG93IHRoZXkgc2hvdWxkIGJlIGNoYW5nZWQgKGlm IGF0IGFsbCkgaW4gYSBwb3NzaWJsZSB1cGRhdGUNCg0KQmFjayB0aGVuLCBvdXIgdGhpbmtpbmcg d2FzIHRoYXQgd2UgY291bGQgd3JpdGUgYSBwYXBlciBhYm91dCBpdCwgYW5kIHRyeSB0byBnZXQg dGhpcyBkZXBsb3llZCBhcyBhIHdheSBvZiBkb2luZyB0aGUgRXhwZXJpbWVudCBhbmQgbW92aW5n IHRoaXMgdG8gUFMgc3RhdHVzLg0KSG93ZXZlciwgd2Ugd2VyZSBsZXNzIGFuZCBsZXNzIHN1cmUg YWJvdXQgdGhlIHJlYWwgdmFsdWUgb2YgdGhpcyAtIHdoZXRoZXIgYWN0dWFsIG5ldHdvcmtzIG5l ZWQgdGhpcz8gVGhlbiwgd2UgaGFkIGxlc3MgYW5kIGxlc3MgdGltZSBhdmFpbGFibGUgYW5kIGF0 IHNvbWUgcG9pbnQgZHJvcHBlZCB0aGUgYmFsbC4NCkkgb2YgY291cnNlIGZvdW5kIGl0IGludGVy ZXN0aW5nIHRvIGhlYXIgdGhhdCBpdCAqaXMqIGEgcmVhbCBwcm9ibGVtLCBldmVuIHRvZGF5Lg0K DQpBbnl3YXk6IHRoaXMgbWFzdGVyIHRoZXNpcyBpcyBhdmFpbGFibGUgaGVyZTogIGh0dHA6Ly9o ZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9tYXJpdXMtb2xzZW4vbWFzdGVy c3RoZXNpcy1tYXJpdXNuby5wZGYNCmFuZCBJIHRoaW5rIEkgY2FuIHNhZmVseSBzYXkgb24gYmVo YWxmIG9mIERhdmlkLCBNYXJpdXMgKHRoZSBtYXN0ZXIgc3R1ZGVudCB3aG8gZGlkIHRoaXMpIGFu ZCBteXNlbGYgdGhhdCB3ZeKAmXJlIGhhcHB5IGlmIHNvbWVvbmUgcGlja3MgdGhpcyB1cCBhbmQg Y29udGludWVzIHRoZSB3b3JrLg0KSXQgd291bGQgcmVxdWlyZSBzb21lIGRpZ2dpbmcsIGJ1dCBJ IG1pZ2h0IGFsc28gc3RpbGwgaGF2ZSB0aGUgY29kZSBseWluZyBhcm91bmQgc29tZXdoZXJlIC0g Zm9yIHNvbWUgb3V0ZGF0ZWQgdmVyc2lvbiBvZiBMaW51eOKApg0KDQpDaGVlcnMsDQpNaWNoYWVs DQoNCg0K --_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIGRldGFpbHMuIEl0IG1heSBi ZSB0aGUgY2FzZSB0aGF0IGl0IGNhbiBiZSB0cmlja3kgdG8gZ2V0IGEgZGVjZW50IHVuZGVyc3Rh bmRpbmcgb2Ygd2hhdCBpcyBwb3NzaWJsZSBpbiB0ZXJtcyBvZiBBQ0sgcmF0ZSByZWR1Y3Rpb24g Zm9yIFRDUC4gVGhlIG1pZGRsZWJveCBiZWhhdmlvcg0KIHRvIGRpc2NhcmQgZXZlcnl0aGluZyBl eGNlcHQgdGhlIGxhc3QgQUNLIGhhcyBhbHNvIGJlZW4gcHJvcG9zZWQgaW4gdGhlIFJBTjIgV0cg aW4gM0dQUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVu Z0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAzMSBtYXJzIDIwMTcgMDA6MTc8 YnI+DQo8Yj5Ubzo8L2I+IE1pY2hhZWwgV2VsemwgJmx0O21pY2hhd2VAaWZpLnVpby5ubyZndDs8 YnI+DQo8Yj5DYzo8L2I+IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNz b25AZXJpY3Nzb24uY29tJmd0OzsgdHN2d2cgSUVURiBsaXN0ICZsdDt0c3Z3Z0BpZXRmLm9yZyZn dDs7IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9ucyAmbHQ7dGNwbUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gVENQIEFDSy1DQyAocmU6IFRyYW5zcG9ydCBwcm90 b2NvbCBmZWVkYmFjayBvdmVyaGVhZCApPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZGluZyB0aGUgcXVlc3Rpb24gaW4gdGhlIHNsaWRl IDUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7SXMg aW1tZWRpYXRlIEFDSyBuZWVkZWQgZm9yIG91dCBvZiBvcmRlciBzZWdtZW50cyBpZiBSQUNLIGlz IHVzZWQgPyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgYW5zd2VyIGlzIGJvdGggeWVzIGFuZCBubzogYSB0aW1lbHkgZmVlZGJh Y2sgaXMgYXBwcmVjaWF0ZWQgKHllcykuIEJ1dCBSQUNLIGRvZXMgbm90IG5lZWQgMTAwIERVUEFD S3MgZWFjaCB0ZWxsaW5nIG9uZSBtb3JlIHBhY2tldCBpcyBkZWxpdmVyZWQgb3V0IG9mIG9yZGVy IChubykuIEluIG90aGVyIHdvcmRzIGlmIHRoZSBBQ0sgaXMgdGltZWx5IGFuZCBwcmVjaXNlIGFi b3V0IHRoZSBkZWxpdmVyeSBwcm9jZXNzLA0KIFJBQ0sgd291bGQgd29yayB3ZWxsIChzbyBkb2Vz IEJCUikuIEhvd2V2ZXIgdGhpcyBjYW4gZ28gdGVycmlibHkgd3JvbmcgaWYgdGhlIG1pZGRsZS1i b3ggc2VuZHMgb25seSB0aGUgbGFzdCBBQ0svU0FDSy4gSXQgaGFzIGhhcHBlbmVkIGluIG9uZSBt YWpvciBjbG91ZCBwbGF0Zm9ybS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMzAsIDIwMTcgYXQgMjoxNCBQTSwgTWljaGFl bCBXZWx6bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ubyIgdGFyZ2V0PSJf YmxhbmsiPm1pY2hhd2VAaWZpLnVpby5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MgSW5nZW1hciBmb3IgeW91ciBpbnRlcmVzdGluZyBwcmVzZW50YXRpb24gdG9kYXk6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LXRz dndnLXNlc3NiLTctdHJhbnNwb3J0LXByb3RvY29sLWZlZWRiYWNrLW92ZXJoZWFkLWlzc3Vlcy1h bmQtc29sdXRpb25zLTAwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtdHN2d2ctc2Vzc2ItNy10cmFuc3BvcnQt cHJvdG9jb2wtZmVlZGJhY2stb3ZlcmhlYWQtaXNzdWVzLWFuZC1zb2x1dGlvbnMtMDAucGRmPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdhbnRlZCB0byBzaGFyZSB3aXRoIHlvdSwgYW5kIHRoZSBsaXN0LCB0aGF0IERhdmlkIFJvcyAm bmJzcDsob25lIG9mIHRoZSBvcmlnaW5hbCBhdXRob3JzIG9mIEFDSy1DQywgUkZDIDU2OTApIGFu ZCBJIG9uY2UgYWR2aXNlZCBhIG1hc3RlciBzdHVkZW50IHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBpbXBsZW1lbnQgQUNLLUNDPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRlc3QgaXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gYW5h bHl6ZSBhbGwgUkZDIDIxMTkgLSBzdHlsZSBrZXl3b3JkcyBpbiBSRkMgNTY5MCwgdG8gc2VlIGhv dyB0aGV5IHNob3VsZCBiZSBjaGFuZ2VkIChpZiBhdCBhbGwpIGluIGEgcG9zc2libGUgdXBkYXRl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJh Y2sgdGhlbiwgb3VyIHRoaW5raW5nIHdhcyB0aGF0IHdlIGNvdWxkIHdyaXRlIGEgcGFwZXIgYWJv dXQgaXQsIGFuZCB0cnkgdG8gZ2V0IHRoaXMgZGVwbG95ZWQgYXMgYSB3YXkgb2YgZG9pbmcgdGhl IEV4cGVyaW1lbnQgYW5kIG1vdmluZyB0aGlzIHRvIFBTIHN0YXR1cy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHdlIHdlcmUgbGVz cyBhbmQgbGVzcyBzdXJlIGFib3V0IHRoZSByZWFsIHZhbHVlIG9mIHRoaXMgLSB3aGV0aGVyIGFj dHVhbCBuZXR3b3JrcyBuZWVkIHRoaXM/IFRoZW4sIHdlIGhhZCBsZXNzIGFuZCBsZXNzIHRpbWUg YXZhaWxhYmxlIGFuZCBhdCBzb21lIHBvaW50IGRyb3BwZWQgdGhlIGJhbGwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG9mIGNvdXJzZSBmb3Vu ZCBpdCBpbnRlcmVzdGluZyB0byBoZWFyIHRoYXQgaXQgKmlzKiBhIHJlYWwgcHJvYmxlbSwgZXZl biB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW55d2F5OiB0aGlzIG1hc3RlciB0aGVzaXMgaXMgYXZhaWxhYmxlIGhlcmU6ICZuYnNw OzxhIGhyZWY9Imh0dHA6Ly9oZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9t YXJpdXMtb2xzZW4vbWFzdGVyc3RoZXNpcy1tYXJpdXNuby5wZGYiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vaGVpbS5pZmkudWlvLm5vL21pY2hhd2UvdGVhY2hpbmcvZGlwbHMvbWFyaXVzLW9sc2Vu L21hc3RlcnN0aGVzaXMtbWFyaXVzbm8ucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIEkgdGhpbmsgSSBjYW4gc2FmZWx5IHNheSBv biBiZWhhbGYgb2YgRGF2aWQsIE1hcml1cyAodGhlIG1hc3RlciBzdHVkZW50IHdobyBkaWQgdGhp cykgYW5kIG15c2VsZiB0aGF0IHdl4oCZcmUgaGFwcHkgaWYgc29tZW9uZSBwaWNrcyB0aGlzIHVw IGFuZCBjb250aW51ZXMgdGhlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCByZXF1aXJlIHNvbWUgZGlnZ2luZywgYnV0IEkg bWlnaHQgYWxzbyBzdGlsbCBoYXZlIHRoZSBjb2RlIGx5aW5nIGFyb3VuZCBzb21ld2hlcmUgLSBm b3Igc29tZSBvdXRkYXRlZCB2ZXJzaW9uIG9mIExpbnV44oCmPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pY2hhZWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB348585F3090AF94C3234231C2370DB4PR07MB348eurprd_-- From nobody Fri Mar 31 10:44:47 2017 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 463761294CA for ; Fri, 31 Mar 2017 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.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 BYv1Tp40e3Nd for ; Fri, 31 Mar 2017 10:44:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 B2AF212948F for ; Fri, 31 Mar 2017 10:44:42 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-52-58de952ee94d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 76.A8.27378.E259ED85; Fri, 31 Mar 2017 19:43:11 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 31 Mar 2017 19:42:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=esd1i76r0mxdop2C7muGI5tglu5KZ0WeOPvKenHOel0=; b=aAxKyUt60FKk3yQLu12aCFG9bl3I54pS17x0PBSDDWAKgXEcqQfE+we8n+9jZamll+LVWYBcMU/091qG1pYck87KbR435SEIFcmd65V9OAgLVkyasxPHfPIZTaHVH+iNI9l2stLmYyufERFQbUgqkjFwKdQ6zq4AXJeI6yrnY84= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 17:42:55 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.1005.014; Fri, 31 Mar 2017 17:42:55 +0000 From: Ingemar Johansson S To: Bob Briscoe , tsvwg IETF list Thread-Topic: transport protocol feedback overhead Thread-Index: AQHSqZLOdmB+LdBFN0Wl5nbQvPjKQ6GvN3bQ Date: Fri, 31 Mar 2017 17:42:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.88] x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:DSY/dq+K8kOUajdjyPZzxQGjBnMTAlqwTuPHdxO2rZp0NTqTX3kWRcqKnr3nMtROPPEN+3zQPUMgJ0RvlE7GZ+6sdsEhzYD2N+7DoxqxsYtrbu71eXVbs88FCLwiSY15ZeHHZYLIz16Uh+e+3Ip7qcqWXbhisno8xUROcoefGYAUeindmrWENcQvvGkkLl4ijZgxVUGHa1kDSuHzYnAnLDS5E12cD9vbblalXA47ofsOxYZ2Dj733t/HlN4pm6iGjFRto8JAWrhqacSX42NS+YfLf2yFFicE8rpBvGDB3Bdb3w9+U5I9ubPEm/MCTRBkLjtqKcLK3F41cyS5ZWCr/A== x-ms-office365-filtering-correlation-id: 53ad264e-0784-491a-f018-08d4785d5cc8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB347; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39850400002)(39860400002)(39410400002)(39400400002)(39450400003)(13464003)(74316002)(54356999)(966004)(76176999)(50986999)(305945005)(77096006)(102836003)(3846002)(2906002)(3480700004)(66066001)(122556002)(6116002)(229853002)(6436002)(2900100001)(33656002)(99286003)(53376002)(2950100002)(6506006)(6246003)(3280700002)(38730400002)(7696004)(189998001)(25786009)(81166006)(9686003)(3660700001)(8936002)(5660300001)(86362001)(8676002)(53936002)(55016002)(6306002)(53546009)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 17:42:54.8484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KZGbFdQld/6r0Ig/aNzBZHHy5gtTj25i6b A5PHq/sXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJUx9dAB9oJdEhWLVn9ma2B8Id7FyMkhIWAi 8WVZP0sXIxeHkMB6Rok5O18zQjgnGCWaL3czgzgsAr3MEr0fv0OVTWOSeDj7KlTZMUaJ302f GUGGsQnYSKw89B3MFhFwlzh+4SiYLSxgKLFpzi6ouJHE68/74OyVbz6zg9gsAqoSzbdbmUBs XoEoiSsTd7CC2EICjhIHbj0Hq+EUcJKYdaMFLM4oICtx//s9FhCbWUBc4taT+UwQDwlILNlz nhnCFpV4+fgfK8ihjAIzGSX27l/HCJFQkHg39zQbSEJCoJtZYv/1TjaIhK/Eyr1bgCZxANm1 Ek3LbCHCmRKzO58yQ4StJOadiYVoPc8kMXflL6hWGYl3c3YyQiRWs0o8nTQD6nspibtXOqFs GYkXd/ayggxiFtCUWL9LfwKjxiwkP8xCyECEFSWmdD9knwUOFkGJkzOfsCxgZFnFKFqcWpyU m25krJdalJlcXJyfp5eXWrKJEZg2Dm75rbqD8fIbx0OMAhyMSjy8DxLuRQixJpYVV+YeYpTg YFYS4WWKAwrxpiRWVqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgmy8TBKdXA GPpHP2LlDI/+1h/ZfIZ+Uy76zd0oyv3y3KnLyps+rVw1g907yT3D6BPnidL608uuWlRzri1y +/Pqi//fzeF3bapic69s/7mhZZnRzgead2y+y34JfPBXWDTDUu7pPcXgAve2kl75WusHKXtL t50PFxcznmzpbOT+6EeK8qQF80L4VmyQ2rDVUomlOCPRUIu5qDgRAIlLPR4XAwAA Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead 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, 31 Mar 2017 17:44:45 -0000 SGkNCg0KUGxlYXNlIHNlZSBpbmxpbmUuLg0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29l Lm5ldF0NCj4gU2VudDogZGVuIDMwIG1hcnMgMjAxNyAyMjoxOA0KPiBUbzogSW5nZW1hciBKb2hh bnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyB0c3Z3ZyBJRVRGDQo+ IGxpc3QgPHRzdndnQGlldGYub3JnPg0KPiBTdWJqZWN0OiB0cmFuc3BvcnQgcHJvdG9jb2wgZmVl ZGJhY2sgb3ZlcmhlYWQNCj4gDQo+IEluZ2VtYXIsIGxpc3QsDQo+IA0KPiBJIHNlZW1lZCB0byBn ZXQgYmxvY2tlZCBmcm9tIHRhbGtpbmcgYWZ0ZXIgSSB3YXMgdHJ5aW5nIHRvIGJlIHBvbGl0ZSAt IGxldHRpbmcNCj4geW91IGZpbmlzaCB5b3VyIHRhbGsuLi4NCltJSl0gSXQgbmV2ZXIgcGF5cyBv ZmYgdG8gYmUgcG9saXRlIDotKQ0KDQoNCj4gDQo+IFlvdSBkZXNjcmliZWQgb25lIHByb2JsZW06 DQo+ICAgKEEpIEluIG1vYmlsZSAoYW5kIG90aGVyIG5ldHdvcmtzKSAgdXBzdHJlYW0gQUNLIGxv YWQgaXMgYSBwcm9ibGVtLg0KW0lKXSBZZXMsIGl0IGNhbiBiZSBwcm9ibGVtYXRpYyBmb3IgaW5z dGFuY2UgaW4gVEREIGFjY2VzcywgZHVlIHRvIHRoZSBhc3ltbWV0cnksIHRoZXJlIGFyZSBvZiBj b3Vyc2UgZGlmZmVyZW50IGRlZ3JlZXMgaW4gaGVsbC4gVGhlIG1haW4gcG9pbnQgSSB3YW50ZWQg dG8gY29udmV5IChub3Qgc3VyZSBob3cgbHVja3kgSSB3YXMpIHdhcyB0byBlbmNvdXJhZ2UgZGV2 ZWxvcGVycyB0byBzZW5kIGFzIG11Y2ggQUNLcyBhcyBhIG5lZWRlZCwgbm90aGluZyBtb3JlLiAN Cg0KDQo+IFRoZXJlIGlzIGEgY29tcGxlbWVudGFyeSBwcm9ibGVtIHRvbzoNCj4gKEIpIENhcGFj aXR5IHZhcmlhdGlvbiBpcyBnZXR0aW5nIGh1Z2UgYXMgcmFkaW8gd2F2ZWxlbmd0aCBpbmNyZWFz ZXMuIFNvIGl0J3MNCj4gdXNlZnVsIGZvciB0aGUgc2VuZGVyIHRvIHdhdGNoIHRoZSB0aW1pbmcg b2YgdGhlIEFDS3MgdG8gYmUgYWJsZSB0byB0cmFjaw0KPiBjaGFuZ2VzIGluIGNhcGFjaXR5IGFz IGZhc3QgYXMgcG9zc2libGUuIEl0J3MgYWxzbyB1c2VmdWwgdG8gYmUgYWJsZSB0byB2YXJ5IHRo ZQ0KPiBzcGFjaW5nIGJldHdlZW4gdGhlIHBhY2tldHMgeW91IHNlbmQgdG8gcHJvYmUgZm9yIGlu Y3JlYXNlcyBpbiBjYXBhY2l0eSBieQ0KPiB3YXRjaGluZyB0aGUgQUNLIHNwYWNpbmcgaW4gcmVz cG9uc2UuDQo+IA0KPiBUaGVzZSB0d28gYXJlIGluIHRlbnNpb24gLSAoQSkgd2FudHMgbGVzcyBB Q0tzLCAoQikgd2FudHMgdGhlbSBhbGwuDQo+IA0KPiBBIHBvc3NpYmxlIHNvbHV0aW9uLCBpcyBh IGRhdGEgc3RydWN0dXJlIGluIGEgc3RyZXRjaCBBQ0sgdG8gYmUgYWJsZSB0byByZXBvcnQNCj4g dGhlIHRpbWUgb2YgYXJyaXZhbCBvZiBhbGwgdGhlIHByZXZpb3VzIGRhdGEgcGFja2V0cyAoaWUu IHRoZSBwYWNrZXRzIHRoYXQgdGhlDQo+IHN0cmV0Y2ggQUNLIGlzIEFDS2luZy4NCltJSl0gTGlr ZSB3aGF0IGlzIGltcGxlbWVudGVkIGluIFFVSUMsIHRoaXMgd2lsbCBhbGxvdyB0byBnZXQgZGV0 YWlsZWQgdGltaW5nIG9mIGVhY2ggcmVjZWl2ZWQgcGFja2V0IGlmIHdhbnRlZC4gTm90IHN1cmUg aG93IGZlYXNpYmxlIGl0IGlzIHdpdGggVENQLg0KDQo+IA0KPiBFdmVuIHRobyB0aGlzIGluZm8g d2lsbCBhcnJpdmUgYXQgdGhlIHNlbmRlciBsYXRlciB0aGFuIGl0IHdvdWxkIGhhdmUgZG9uZSBp ZiB0aGUNCj4gQUNLcyBoYWQgbm90IGJlZW4gc3VwcHJlc3NlZCwgYXMgbG9uZyBhcyB5b3UgYXJl IHN0aWxsIGdldHRpbmcgYSByZWFzb25hYmxlDQo+IG51bWJlciBvZiBBQ0tzIGV2ZXJ5IFJUVCwg aXQgcmVzb2x2ZXMgdGhlIHRlbnNpb24gYmV0d2VlbiBBIGFuZCBCLg0KPiANCj4gVGhvdWdodHM/ DQo+IERvZXMgdGhpcyBpZGVhIGFscmVhZHkgZXhpc3Q/DQoNCg0KPiANCj4gDQo+IA0KPiBCb2IN Cj4gDQo+IFBTLiBBcG9sb2dpZXMgZm9yIGRyb3BwaW5nIGFuIGlubm92YXRpdmUgaWRlYSBpbnRv IGEgc3RhbmRhcmRzIG1lZXRpbmcuDQo+IFRoaXMgcHJvYmFibHkgb3VnaHQgdG8gYmUgYSByZXNl YXJjaCBwYXBlciBmaXJzdC4NCj4gDQo+IA0KPiAtLQ0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fXw0KPiBCb2IgQnJp c2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQv DQoNCg== From nobody Fri Mar 31 12:47:35 2017 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 3100A129454 for ; Fri, 31 Mar 2017 12:47:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 H_H4zg5dff4M for ; Fri, 31 Mar 2017 12:47:29 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 E873512940F for ; Fri, 31 Mar 2017 12:47:28 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cu2W7-000AV7-Bb for tsvwg@ietf.org; Fri, 31 Mar 2017 21:47:27 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cu2W6-0007u1-CZ for tsvwg@ietf.org; Fri, 31 Mar 2017 21:47:27 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_D973AE85-2192-4E00-8AB5-B4E0A7433AD3" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 31 Mar 2017 14:47:26 -0500 References: To: tsvwg IETF list In-Reply-To: Message-Id: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 3 sum msgs/h 3 total rcpts 53443 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.032, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FB27C732104ECA10093A23A11E31273E1024F6C6 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 133 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts 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, 31 Mar 2017 19:47:33 -0000 --Apple-Mail=_D973AE85-2192-4E00-8AB5-B4E0A7433AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Sorry, I would have gone to the mic to say this yesterday, but time was = running short, there were lots of others going there, AND I was = scribing=E2=80=A6 hence now this email: I=E2=80=99m a little worried that we=E2=80=99re adopting a behavior = inside the network, without specifying how end systems should work with = it. In particular, what makes me feel uneasy is slide 2 from = yesterday=E2=80=99s presentation: = https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessb-l4s-draft= s-01.pdf = which showed TCP Prague as an ICCRG item. I think this misrepresents the = role of an IRTF group: yes ICCRG can publish documents, but these have = an IRTF boilerplate, and I don=E2=80=99t think that=E2=80=99s the right = way to publish an e2e counterpart to an IETF Experimental RFC. As I = explained in tsvarea earlier this week: = https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-discuss= ion-on-congestion-control-work-in-the-ietf-the-role-of-iccrg-michael-welzl= -00.pdf = =E2=80=A6 the more common role of ICCRG is to pre-evaluate proposals = before they=E2=80=99re even ready for the IETF. Technically, these are not so minor issues. DCTCP, as it stands, = doesn=E2=80=99t work on the Internet; there are Internet-specific = problems that would first need to be addressed. Two cases were discussed = yesterday: 1) how will this work when there are two bottlenecks in a row? 2) what if TCP Prague traffic gets into a =E2=80=9Cclassic=E2=80=9D ECN = queue? =E2=80=A6 and these are likely not the only ones. E.g., the second = problem was identified long ago, at the L4S BoF - see slide 3: https://www.ietf.org/proceedings/96/slides/slides-96-l4s-6.pdf = where it says "Fall-back to classic TCP on classic ECN bottleneck=E2=80=9D= . Worryingly, the =E2=80=9Cstarting point=E2=80=9D column says = =E2=80=9Cnone=E2=80=9D, and so far it doesn=E2=80=99t seem that we have = an answer to this question. =3D> what will this do to the ongoing effort of Apple to enable = (classic) ECN? Cheers, Michael > On Mar 31, 2017, at 9:08 AM, Wesley Eddy wrote: >=20 > Hello, this is a note to confirm that due to the positve response at = the last couple IETF meetings and on the mailing list, and currently no = negative responses, we (TSVWG co-chairs) think there's consensus to = adopt the set of 3 L4S drafts. >=20 > https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch > https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled > https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id >=20 > We've asked the authors to wait a week, just to confirm this with the = mailing list, before submitting the documents as draft-ietf-tsvwg-... >=20 > Please don't hesitate to start reviewing and discussing the open items = Koen highlighted yesterday. >=20 >=20 --Apple-Mail=_D973AE85-2192-4E00-8AB5-B4E0A7433AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

Sorry, I would have gone to the mic to say this yesterday, = but time was running short, there were lots of others going there, AND I = was scribing=E2=80=A6 hence now this email:

I=E2=80=99m a little worried that = we=E2=80=99re adopting a behavior inside the network, without specifying = how end systems should work with it. In particular, what makes me feel = uneasy is slide 2 from yesterday=E2=80=99s presentation:
https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sess= b-l4s-drafts-01.pdf
which showed TCP Prague as = an ICCRG item. I think this misrepresents the role of an IRTF group: yes = ICCRG can publish documents, but these have an IRTF boilerplate, and I = don=E2=80=99t think that=E2=80=99s the right way to publish an e2e = counterpart to an IETF Experimental RFC. As I explained in tsvarea = earlier this week:
https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-se= ssb-discussion-on-congestion-control-work-in-the-ietf-the-role-of-iccrg-mi= chael-welzl-00.pdf
=E2=80=A6 the more common = role of ICCRG is to pre-evaluate proposals before they=E2=80=99re even = ready for the IETF.

Technically, these are not so minor issues. DCTCP, as it = stands, doesn=E2=80=99t work on the Internet; there are = Internet-specific problems that would first need to be addressed. Two = cases were discussed yesterday:
1) how will = this work when there are two bottlenecks in a row?
2)= what if TCP Prague traffic gets into a =E2=80=9Cclassic=E2=80=9D ECN = queue?
=E2=80=A6 and these are likely not the only = ones. E.g., the second problem was identified long ago, at the L4S BoF - = see slide 3:
https://www.ietf.org/proceedings/96/slides/slides-96-l4s-6.pdf<= /a>
where it says "Fall-back to classic TCP on = classic ECN bottleneck=E2=80=9D. Worryingly, the =E2=80=9Cstarting = point=E2=80=9D column says =E2=80=9Cnone=E2=80=9D, and so far it = doesn=E2=80=99t seem that we have an answer to this question.
=3D> what will this do to the ongoing effort of Apple to = enable (classic) ECN?

Cheers,
Michael



On Mar 31, 2017, at 9:08 AM, Wesley Eddy <wes@mti-systems.com>= wrote:

Hello, this is a note to confirm that due to the positve = response at the last couple IETF meetings and on the mailing list, and = currently no negative responses, we (TSVWG co-chairs) think there's = consensus to adopt the set of 3 L4S drafts.

https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-archhttps://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupl= ed
https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id

We've asked the authors to wait a week, just = to confirm this with the mailing list, before submitting the documents = as draft-ietf-tsvwg-...

Please don't = hesitate to start reviewing and discussing the open items Koen = highlighted yesterday.



= --Apple-Mail=_D973AE85-2192-4E00-8AB5-B4E0A7433AD3--