From nobody Mon Feb 2 21:34:38 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3511A212D; Mon, 2 Feb 2015 21:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 frzlNUw6wS97; Mon, 2 Feb 2015 21:34:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD661A1EEC; Mon, 2 Feb 2015 21:34:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E7C5B180489; Mon, 2 Feb 2015 21:34:23 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150203053423.E7C5B180489@rfc-editor.org> Date: Mon, 2 Feb 2015 21:34:23 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 7414 on A Roadmap for Transmission Control Protocol (TCP) Specification Documents X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 05:34:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7414 Title: A Roadmap for Transmission Control Protocol (TCP) Specification Documents Author: M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann Status: Informational Stream: IETF Date: February 2015 Mailbox: m.duke@f5.com, braden@isi.edu, wes@mti-systems.com, elb@interruptsciences.com, alexander.zimmermann@netapp.com Pages: 57 Characters: 130622 Obsoletes: RFC 4614 I-D Tag: draft-ietf-tcpm-tcp-rfc4614bis-08.txt URL: https://www.rfc-editor.org/info/rfc7414 This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. This document is a product of the TCP Maintenance and Minor Extensions 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/rfc.html 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 Feb 3 07:38:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5ED1A1A10 for ; Tue, 3 Feb 2015 07:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G0ZgQo8qUXCX for ; Tue, 3 Feb 2015 07:38:02 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4451A1A06 for ; Tue, 3 Feb 2015 07:38:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,513,1418112000"; d="asc'?scan'208";a="20818500" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx141-out.netapp.com with ESMTP; 03 Feb 2015 07:32:53 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 3 Feb 2015 07:32:52 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Tue, 3 Feb 2015 07:32:52 -0800 From: "Eggert, Lars" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AdA6Gw2/aMIpCeKlQZ6aha0AlCWw1gF7qt0A Date: Tue, 3 Feb 2015 15:32:51 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_CC687BA5-9989-4C56-BF81-8F72FBD52B5B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 15:38:03 -0000 --Apple-Mail=_CC687BA5-9989-4C56-BF81-8F72FBD52B5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2015-1-27, at 11:21, Scharf, Michael (Michael) = wrote: > NEW: >=20 > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control. In addition, > TCPM may document alternative congestion control algorithms > that are known to be widely deployed, and that are considered > safe for large-scale deployment in the Internet. Changes of algorithms > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. as one of the authors of the DCTCP draft, it remains a bit unclear to me = whether that document would under the new text be something that TCPM = was OK to work on. DCTCP uses ECN (and redefines it, to some degree). That is certainly an = "alternative congestion control algorithm" and hence now in scope for = TCPM, unless it is also a "fundamental change", which would then mean = the DCTCP document would need to go somewhere else? Also, one could argue that DCTCP does not fulfill the "safe for = large-scale deployment in the Internet" clause, since it's not intended = to be used on the Internet and implementations typically have mechanisms = to restrict its use. This again may mean that DCTCP is (still) out of = scope for TCPM. For the record, I believe TCPM is the right group to give feedback on = the DCTCP document; the only viable alternative would be TSVWG, which = has too much else on their plate. So how about this new text? TCPM also provides a venue for the standardization and documentation of enhancements to TCP's standard congestion control, but such changes may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will require explicit Area Director approval before they may become work items of the WG, and may require rechartering. Lars --Apple-Mail=_CC687BA5-9989-4C56-BF81-8F72FBD52B5B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVNDqItZcnpRveo1xAQLa+QP/dzf1MUWCNxelCoqrL13jVYA2MMwivCN1 5OqGIqDE1cTeE+PUAUDZR0nIMwOEdVFIaFqERF3lqv9Q8JOA8oayz2ynxHBjS0c7 ePbObBm0uGLWl0iRq1bTF7yQgcEGABZVELmFlaB/Y56yNZuV0uYYztEBYhR++K72 YyyszkxRdVk= =WFzD -----END PGP SIGNATURE----- --Apple-Mail=_CC687BA5-9989-4C56-BF81-8F72FBD52B5B-- From nobody Tue Feb 3 08:21:41 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21861A1A14 for ; Tue, 3 Feb 2015 08:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CEnNeNPFetxH for ; Tue, 3 Feb 2015 08:21:34 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 5CD651A1A54 for ; Tue, 3 Feb 2015 08:21:34 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E4C4332F79E13; Tue, 3 Feb 2015 16:21:27 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t13GLSEK019435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:21:30 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.88]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 17:21:28 +0100 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AQHQP8a7EobaOJLXEEa3b0GSd4lXR5zfEPpg Date: Tue, 3 Feb 2015 16:21:28 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16BF22D9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:21:38 -0000 Hi Lars, > > NEW: > > > > TCPM also provides a venue for standardization of incremental > > enhancements of TCP's standard congestion control. In addition, > > TCPM may document alternative congestion control algorithms > > that are known to be widely deployed, and that are considered > > safe for large-scale deployment in the Internet. Changes of > algorithms > > may require additional review by the IRTF Congestion Control > > Research Group (ICCRG). Fundamental changes to TCP or its congestion > > control algorithms (e.g., departure from loss-based congestion > > control) will be handled by other working groups or will require > > rechartering. >=20 > as one of the authors of the DCTCP draft, it remains a bit unclear to > me whether that document would under the new text be something that > TCPM was OK to work on. >=20 > DCTCP uses ECN (and redefines it, to some degree). That is certainly an > "alternative congestion control algorithm" and hence now in scope for > TCPM, unless it is also a "fundamental change", which would then mean > the DCTCP document would need to go somewhere else? >=20 > Also, one could argue that DCTCP does not fulfill the "safe for large- > scale deployment in the Internet" clause, since it's not intended to be > used on the Internet and implementations typically have mechanisms to > restrict its use. This again may mean that DCTCP is (still) out of > scope for TCPM. I guess TCPM would have to decide in a consensus call whether the mechanism= s that restrict the use of DCTCP are reasonably "safe for avoiding Internet= paths". Possibly TCPM would demand a special boilerblade text. Yet, we don= 't have to discuss this in this thread. > For the record, I believe TCPM is the right group to give feedback on > the DCTCP document; the only viable alternative would be TSVWG, which > has too much else on their plate. >=20 > So how about this new text? >=20 > TCPM also provides a venue for the standardization and documentation of > enhancements to TCP's standard congestion control, but such changes > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will require explicit Area Director approval before they may > become work items of the WG, and may require rechartering. To me, the suggested statement on Area Director approval has no effect, sin= ce *any* new milestone for TCPM already requires "consensus on acceptance i= n the working group and approval by the responsible Area Director" accordin= g to the last paragraph of the current TCPM charter (see https://datatracke= r.ietf.org/wg/tcpm/charter/). Right now, the AD has to approve even purely = incremental changes of the congestion control. Recall that our previous cha= rter in theory required even IESG approval for all milestones, so this was = a significant improvement ;) Assuming that we will not change this requirement of AD approval for all TC= PM work, your suggested paragraph seems to be equivalent to: TCPM also provides a venue for standardization and documentation of enhancements of TCP's standard congestion control, but such changes may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) may require rechartering. My understanding is that such a wording would be more liberal, since it doe= s not specify any constraints. Thoughts and feedback from the community on = such a wording would be very welcome. Thanks Michael From nobody Tue Feb 3 21:19:10 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9DB1A1BE4 for ; Tue, 3 Feb 2015 21:19:09 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 c6BGKJyHFis5 for ; Tue, 3 Feb 2015 21:19:07 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9813D1A1AB2 for ; Tue, 3 Feb 2015 21:19:06 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so42448315lbi.1 for ; Tue, 03 Feb 2015 21:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yh2JnylXsyMpJxclLAJOVnI8NZiS7dIhSo09UY3IRDo=; b=EfP2Ni0J9dgOukoNFedou2ZWg5bhJSuH+NmAG8YD1/nCdBmzloAJmxGwZJxA5UNMNQ iHLp1stJhmKYzxalCpY828EAtHaHJ7nlkp/95n/yxjfXqW0jLRO7W9w/AjYM/CIivyKA qyVGLDvzGH0i31yNv4ZZ3m6sOBNfk0e30gX2FLYBmet0DjGWN/Wytq7sVIvNUEXSBwIL UxaqqnRLZGQV93Tagx1EzTLAw+dHj7ONjfbSCqMOHAzFn6Js+6XQJF6+B420H0d0OkFZ tdksZZicQ20BCJp94+woGGK/awu54IYCQbXTfwblP7T0CGM3nXvc/GXa5jPBjLWaIwxW +gvg== MIME-Version: 1.0 X-Received: by 10.152.29.66 with SMTP id i2mr7689711lah.64.1423027145010; Tue, 03 Feb 2015 21:19:05 -0800 (PST) Received: by 10.152.4.167 with HTTP; Tue, 3 Feb 2015 21:19:04 -0800 (PST) Received: by 10.152.4.167 with HTTP; Tue, 3 Feb 2015 21:19:04 -0800 (PST) In-Reply-To: <20150203053423.E7C5B180489@rfc-editor.org> References: <20150203053423.E7C5B180489@rfc-editor.org> Date: Tue, 3 Feb 2015 23:19:04 -0600 Message-ID: From: Spencer Dawkins at IETF To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=089e0160bac07bf462050e3c5369 Archived-At: Cc: Martin Stiemerling Subject: [tcpm] Fwd: RFC 7414 on A Roadmap for Transmission Control Protocol (TCP) Specification Documents X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:19:09 -0000 --089e0160bac07bf462050e3c5369 Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: Date: Feb 2, 2015 11:34 PM Subject: [tcpm] RFC 7414 on A Roadmap for Transmission Control Protocol (TCP) Specification Documents To: , Cc: , , < rfc-editor@rfc-editor.org> A new Request for Comments is now available in online RFC libraries. RFC 7414 Title: A Roadmap for Transmission Control Protocol (TCP) Specification Documents Author: M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann Status: Informational Stream: IETF Date: February 2015 Mailbox: m.duke@f5.com, braden@isi.edu, wes@mti-systems.com, elb@interruptsciences.com, alexander.zimmermann@netapp.com Pages: 57 Characters: 130622 Obsoletes: RFC 4614 I-D Tag: draft-ietf-tcpm-tcp-rfc4614bis-08.txt URL: https://www.rfc-editor.org/info/rfc7414 This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. This document is a product of the TCP Maintenance and Minor Extensions 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/rfc.html 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --089e0160bac07bf462050e3c5369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From:= <rfc-editor@rfc-editor.or= g>
Date: Feb 2, 2015 11:34 PM
Subject: [tcpm] RFC 7414 on A Ro= admap for Transmission Control Protocol (TCP) Specification Documents
To= : <ietf-announce@ietf.org= >, <rfc-dist@rfc-editor.o= rg>
Cc: <drafts= -update-ref@iana.org>, <tcpm@ie= tf.org>, <rfc-edito= r@rfc-editor.org>

A new Request for Comm= ents is now available in online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7414

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 A Roadmap for Transm= ission Control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Proto= col (TCP) Specification Documents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0M. Duke, R. Braden,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 W. Ed= dy, E. Blanton,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A. Zi= mmermann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Informational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0February 2015 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 m.duke@f5.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 braden@isi.edu,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wes@mti-systems.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 elb@interruptsciences.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alexander.zimmermann@netapp.c= om
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 57
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 130622
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Obsoletes:=C2=A0 RFC 4614

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-tcpm-tcp-rfc46= 14bis-08.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.rfc-edit= or.org/info/rfc7414

This document contains a roadmap to the Request for Comments (RFC)
documents relating to the Internet's Transmission Control Protocol
(TCP).=C2=A0 This roadmap provides a brief summary of the documents
defining TCP and various TCP extensions that have accumulated in the
RFC series.=C2=A0 This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in
the TCP-related RFCs.

This document obsoletes RFC 4614.

This document is a product of the TCP Maintenance and Minor Extensions Work= ing 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
=C2=A0 https://www.ietf.org/mailman/listinfo/ietf-announce
=C2=A0 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/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
--089e0160bac07bf462050e3c5369-- From nobody Thu Feb 5 11:48:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5351A1AE3 for ; Thu, 5 Feb 2015 11:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 o8nIX1SSe1fU for ; Thu, 5 Feb 2015 11:48:45 -0800 (PST) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8B64C1A1B0A for ; Thu, 5 Feb 2015 11:48:41 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t15JmcNV007470 for ; Thu, 5 Feb 2015 14:48:38 -0500 Received: (qmail 26638 invoked by uid 0); 5 Feb 2015 19:48:38 -0000 X-TCPREMOTEIP: 207.54.183.210 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@207.54.183.210) by 0 with ESMTPA; 5 Feb 2015 19:48:38 -0000 Message-ID: <54D3C911.6020205@mti-systems.com> Date: Thu, 05 Feb 2015 14:48:33 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 19:48:47 -0000 I reviewed the reordering detection algorithm document: https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 The document is very well written. The specification in the draft seems quite clear and like it would be easy to implement directly from the document. The purpose of section 4.7 ("Placeholder for Response Algorithm") isn't clear to me, especially in relation to the separate reaction draft (draft-zimmermann-tcpm-reordering-reaction). One thing that was unclear to me, and seems useful, is a discussion of the potential sources of error. In other words, what events would cause the computed metrics to be wrong and how significantly wrong? There are a number of different events and potential corner cases that are already addressed in the algorithm, and it wasn't clear to me "what's left" or if it's supposed to just work perfectly in all cases. (I'm sure it's not!) Obvious things that occurred to me were: - different compositions of loss and reordering "features" in the forward path: - lossiness followed by reordering - reordering followed by lossiness - reordering followed by reordering somewhere else (and do we even care about this, since it's the state of the packets at the receiver that matters, and not how many times the order has been shuffled) - loss and reordering in the ACK path The sensitivity to these things, I think, matters in understanding the utility of the computed metrics, and their feedback into a response function. -- Wes Eddy MTI Systems From nobody Thu Feb 5 21:18:38 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9D71A01F2 for ; Thu, 5 Feb 2015 21:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 qVevGg8o2XkO for ; Thu, 5 Feb 2015 21:18:33 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701E51A039C for ; Thu, 5 Feb 2015 21:18:31 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D17332A0015 for ; Fri, 6 Feb 2015 14:18:29 +0900 (JST) Received: by mail-wi0-f173.google.com with SMTP id r20so2330582wiv.0 for ; Thu, 05 Feb 2015 21:18:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.89.210 with SMTP id bq18mr922784wib.45.1423199907494; Thu, 05 Feb 2015 21:18:27 -0800 (PST) Received: by 10.194.185.43 with HTTP; Thu, 5 Feb 2015 21:18:27 -0800 (PST) In-Reply-To: <54D3C911.6020205@mti-systems.com> References: <54D3C911.6020205@mti-systems.com> Date: Thu, 5 Feb 2015 21:18:27 -0800 Message-ID: From: Yoshifumi Nishida To: Wesley Eddy Content-Type: multipart/alternative; boundary=e89a8f3ba5e3ee4323050e648c59 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 05:18:35 -0000 --e89a8f3ba5e3ee4323050e648c59 Content-Type: text/plain; charset=UTF-8 Hi, I also agree that this document is well written and we already have seen some consensus to explore solutions for reordering issue in the WG. However, I personally have the following high-level questions on the draft in order to think about it more. Q1: Do we think that measuring reordering extent can be an approach for reordering issue? One thing I'm wondering is that measured reordering extent is a kind of historic data. So, to utilize this data properly, we might need to understand how previous reorder extent is relevant to present or future trends. Do we have some understandings or consensus on this? Or, can we utilize this data in other ways? Q2: Even if we're not very sure about Q1, do we think we can proceed this idea in order to explore the answers for Q1? Thanks, -- Yoshi On Thu, Feb 5, 2015 at 11:48 AM, Wesley Eddy wrote: > I reviewed the reordering detection algorithm document: > https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 > > The document is very well written. The specification in the draft seems > quite clear and like it would be easy to implement directly from the > document. > > The purpose of section 4.7 ("Placeholder for Response Algorithm") isn't > clear to me, especially in relation to the separate reaction draft > (draft-zimmermann-tcpm-reordering-reaction). > > One thing that was unclear to me, and seems useful, is a discussion of > the potential sources of error. In other words, what events would > cause the computed metrics to be wrong and how significantly wrong? > There are a number of different events and potential corner cases that > are already addressed in the algorithm, and it wasn't clear to me > "what's left" or if it's supposed to just work perfectly in all cases. > (I'm sure it's not!) > > Obvious things that occurred to me were: > - different compositions of loss and reordering "features" in the > forward path: > - lossiness followed by reordering > - reordering followed by lossiness > - reordering followed by reordering somewhere else (and do we even > care about this, since it's the state of the packets at the > receiver that matters, and not how many times the order has been > shuffled) > - loss and reordering in the ACK path > > The sensitivity to these things, I think, matters in understanding the > utility of the computed metrics, and their feedback into a response > function. > > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --e89a8f3ba5e3ee4323050e648c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
I also agree that this document is well= written and we already have seen some consensus to explore solutions for r= eordering issue in the WG.

However, I personally h= ave the following high-level questions on the draft in order to think about= it more.=C2=A0

Q1: Do we think that measuring reo= rdering extent can be an approach for reordering issue?
=C2=A0 = =C2=A0 One thing I'm wondering is that measured reordering extent is a = kind of historic data. So, to utilize this data properly, we might need to = understand how previous reorder extent is relevant to present or future tre= nds. Do we have some understandings or consensus on this? Or, can we utiliz= e this data in other ways?

Q2: Even if we're n= ot very sure about Q1, do we think we can proceed this idea in order to exp= lore the answers for Q1?

Thanks,
--
Yoshi
=C2=A0 =C2=A0=C2=A0
<= br>
On Thu, Feb 5, 2015 at 11:48 AM, Wesley Eddy = <wes@mti-systems.com> wrote:
I reviewed the reordering detection algorithm document:
https://tools.ietf.org/html/draft-zimmermann-t= cpm-reordering-detection-02

The document is very well written.=C2=A0 The specification in the draft see= ms
quite clear and like it would be easy to implement directly from the
document.

The purpose of section 4.7 ("Placeholder for Response Algorithm")= isn't
clear to me, especially in relation to the separate reaction draft
(draft-zimmermann-tcpm-reordering-reaction).

One thing that was unclear to me, and seems useful, is a discussion of
the potential sources of error.=C2=A0 In other words, what events would
cause the computed metrics to be wrong and how significantly wrong?
There are a number of different events and potential corner cases that
are already addressed in the algorithm, and it wasn't clear to me
"what's left" or if it's supposed to just work perfectly = in all cases.
(I'm sure it's not!)

Obvious things that occurred to me were:
- different compositions of loss and reordering "features" in the=
=C2=A0 forward path:
=C2=A0 - lossiness followed by reordering
=C2=A0 - reordering followed by lossiness
=C2=A0 - reordering followed by reordering somewhere else (and do we even =C2=A0 =C2=A0 care about this, since it's the state of the packets at t= he
=C2=A0 =C2=A0 receiver that matters, and not how many times the order has b= een
=C2=A0 =C2=A0 shuffled)
- loss and reordering in the ACK path

The sensitivity to these things, I think, matters in understanding the
utility of the computed metrics, and their feedback into a response
function.


--
Wes Eddy
MTI Systems

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--e89a8f3ba5e3ee4323050e648c59-- From nobody Thu Feb 5 21:40:31 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318F31A01F2 for ; Thu, 5 Feb 2015 21:40:29 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 euGoPzin5GMl for ; Thu, 5 Feb 2015 21:40:27 -0800 (PST) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3431A01AE for ; Thu, 5 Feb 2015 21:40:27 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t165eP1i008929 for ; Fri, 6 Feb 2015 00:40:25 -0500 Received: (qmail 3698 invoked by uid 0); 6 Feb 2015 05:40:25 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 6 Feb 2015 05:40:25 -0000 Message-ID: <54D453C4.7070107@mti-systems.com> Date: Fri, 06 Feb 2015 00:40:20 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <54D3C911.6020205@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 05:40:29 -0000 On 2/6/2015 12:18 AM, Yoshifumi Nishida wrote: > Hi, > I also agree that this document is well written and we already have seen > some consensus to explore solutions for reordering issue in the WG. > > However, I personally have the following high-level questions on the > draft in order to think about it more. > > Q1: Do we think that measuring reordering extent can be an approach for > reordering issue? > One thing I'm wondering is that measured reordering extent is a kind > of historic data. So, to utilize this data properly, we might need to > understand how previous reorder extent is relevant to present or future > trends. Do we have some understandings or consensus on this? Or, can we > utilize this data in other ways? > This is a good point, since reordering could be due to a transient that occurs once during a connection and never again (e.g. some change in the underlying path), or it could be persistent due to properties of the path fixed for the life of the connection. It's difficult / impossible to tell the difference on a shorter connection, or even on many short connections between the same hosts, but if you could tell the difference, that would determine the proper use of the metrics. In the 1st case, it doesn't seem like TCP should be doing anything beyond just reversing state changes made due to a spurious decision. In the 2nd case, the reordering metrics that are measured would be useful to cache along with the other path metrics that are already cached. -- Wes Eddy MTI Systems From nobody Fri Feb 6 09:46:12 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1351D1A700C for ; Fri, 6 Feb 2015 09:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8DAfBBMsFvsK for ; Fri, 6 Feb 2015 09:46:06 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5F01A1E0F for ; Fri, 6 Feb 2015 09:46:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,530,1418112000"; d="asc'?scan'208";a="20937212" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 06 Feb 2015 09:41:05 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 6 Feb 2015 09:41:05 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5ceb:17f1:1ecd:c4c9%21]) with mapi id 15.00.0995.031; Fri, 6 Feb 2015 09:41:05 -0800 From: "Zimmermann, Alexander" To: Wesley Eddy Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-reordering-detection Thread-Index: AQHQQXzFva7VDhVhZUSRjwVCoGgnfpzka0qA Date: Fri, 6 Feb 2015 17:41:04 +0000 Message-ID: <1E453322-868C-4569-8635-231440E04417@netapp.com> References: <54D3C911.6020205@mti-systems.com> In-Reply-To: <54D3C911.6020205@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_B1B676FC-F386-407D-B79A-A51398AC67C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:46:12 -0000 --Apple-Mail=_B1B676FC-F386-407D-B79A-A51398AC67C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Wes, thanks a lot for looking into the draft! Comments below. > Am 05.02.2015 um 20:48 schrieb Wesley Eddy : >=20 > I reviewed the reordering detection algorithm document: > = https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 >=20 > The document is very well written. The specification in the draft = seems > quite clear and like it would be easy to implement directly from the > document. >=20 > The purpose of section 4.7 ("Placeholder for Response Algorithm") = isn't > clear to me, especially in relation to the separate reaction draft > (draft-zimmermann-tcpm-reordering-reaction). The purpose of section 4.7 is to have a hook for a further reordering reaction algorithm. RFC 4015 has something similar. However, Eifel reaction is maybe a bit more explicit and clear at this point (see step (DET) in RFC 4015) >=20 > One thing that was unclear to me, and seems useful, is a discussion of > the potential sources of error. In other words, what events would > cause the computed metrics to be wrong and how significantly wrong? > There are a number of different events and potential corner cases that > are already addressed in the algorithm, and it wasn't clear to me > "what's left" or if it's supposed to just work perfectly in all cases. > (I=E2=80=99m sure it's not!) Very good point! I agree. We will add some text in the next version. >=20 > Obvious things that occurred to me were: > - different compositions of loss and reordering "features" in the > forward path: > - lossiness followed by reordering > - reordering followed by lossiness > - reordering followed by reordering somewhere else (and do we even > care about this, since it's the state of the packets at the > receiver that matters, and not how many times the order has been > shuffled) > - loss and reordering in the ACK path + packet duplication >=20 > The sensitivity to these things, I think, matters in understanding the > utility of the computed metrics, and their feedback into a response > function. I agree. Have a nice WE Alex >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_B1B676FC-F386-407D-B79A-A51398AC67C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTU/LAACgkQdyiq39b9uS4Z3wCgzC+EVRKH0T8/QyFpAHZO9UHT BRoAoI4gb1EdeOCkmUX2Bi/uAieJLQnR =Ef1O -----END PGP SIGNATURE----- --Apple-Mail=_B1B676FC-F386-407D-B79A-A51398AC67C6-- From nobody Fri Feb 6 10:29:31 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F821A1A02 for ; Fri, 6 Feb 2015 10:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 y7o1yGh0Q4G0 for ; Fri, 6 Feb 2015 10:29:17 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF621A19E3 for ; Fri, 6 Feb 2015 10:29:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,530,1418112000"; d="asc'?scan'208,217";a="20948535" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 06 Feb 2015 10:24:17 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 6 Feb 2015 10:24:16 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5ceb:17f1:1ecd:c4c9%21]) with mapi id 15.00.0995.031; Fri, 6 Feb 2015 10:24:16 -0800 From: "Zimmermann, Alexander" To: Yoshifumi Nishida Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-reordering-detection Thread-Index: AQHQQXzFva7VDhVhZUSRjwVCoGgnfpzjm8+AgADbewA= Date: Fri, 6 Feb 2015 18:24:16 +0000 Message-ID: <2D80ECE1-AB25-4A39-8D43-92862C90A5EF@netapp.com> References: <54D3C911.6020205@mti-systems.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_C4BF541F-6C72-461C-A893-9632B9ADFDDE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:29:24 -0000 --Apple-Mail=_C4BF541F-6C72-461C-A893-9632B9ADFDDE Content-Type: multipart/alternative; boundary="Apple-Mail=_35ABD6DD-81D7-499E-BD9A-B859C6203DB1" --Apple-Mail=_35ABD6DD-81D7-499E-BD9A-B859C6203DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoshimumi, > Am 06.02.2015 um 06:18 schrieb Yoshifumi Nishida = : >=20 > Hi, > I also agree that this document is well written and we already have = seen some consensus to explore solutions for reordering issue in the WG. >=20 > However, I personally have the following high-level questions on the = draft in order to think about it more. >=20 > Q1: Do we think that measuring reordering extent can be an approach = for reordering issue? Measuring reordering per se or the extent itself? It=E2=80=99s not a big = deal to compute for example the reordering delay too. Basically, or draft compute the reordering extent of the IPPM RFC4737 on = the transport layer. > One thing I'm wondering is that measured reordering extent is a = kind of historic data. So, to utilize this data properly, we might need = to understand how previous reorder extent is relevant to present or = future trends. Yes this is right. But this discussion belongs not to this draft. I = belongs to the reaction draft. It=E2=80=99s clear that all adaptive reordering =E2=80=9Ereaction=E2=80=9C= algorithms have the problem that they need a couple of old events to set the threshold right, which maybe too late = for short TCP flows. But have in mind, TCP-aNCR has two modi. We can run it w/ and w/o the = adaptive part. This is exactly the reason why at least the reaction draft is = experimental. It should be part of the experiment to investigate in which cases an adaptive = algorithms makes more sense than a non-adaptive one. > Do we have some understandings or consensus on this? IMO yes because we have an song consensus on the question if we would = like to make TCP more robust against reordering. The first step in this direction is = to detected and quantify the perceived reordering. This is what the draft is about. We = do not change anything at TCP layer (protocol, behavior). What we can discuss is if extent is = the only metric we should implement, but IMO we can do that after an adoption call. > Or, can we utilize this data in other ways? IPPM? >=20 > Q2: Even if we=E2=80=99re not very sure about Q1, do we think we can = proceed this idea in order to explore the answers for Q1? Yes, I believe so. >=20 > Thanks, > -- > Yoshi >=20 >=20 > On Thu, Feb 5, 2015 at 11:48 AM, Wesley Eddy > wrote: > I reviewed the reordering detection algorithm document: > = https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 = >=20 > The document is very well written. The specification in the draft = seems > quite clear and like it would be easy to implement directly from the > document. >=20 > The purpose of section 4.7 ("Placeholder for Response Algorithm") = isn't > clear to me, especially in relation to the separate reaction draft > (draft-zimmermann-tcpm-reordering-reaction). >=20 > One thing that was unclear to me, and seems useful, is a discussion of > the potential sources of error. In other words, what events would > cause the computed metrics to be wrong and how significantly wrong? > There are a number of different events and potential corner cases that > are already addressed in the algorithm, and it wasn't clear to me > "what's left" or if it's supposed to just work perfectly in all cases. > (I'm sure it's not!) >=20 > Obvious things that occurred to me were: > - different compositions of loss and reordering "features" in the > forward path: > - lossiness followed by reordering > - reordering followed by lossiness > - reordering followed by reordering somewhere else (and do we even > care about this, since it's the state of the packets at the > receiver that matters, and not how many times the order has been > shuffled) > - loss and reordering in the ACK path >=20 > The sensitivity to these things, I think, matters in understanding the > utility of the computed metrics, and their feedback into a response > function. >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_35ABD6DD-81D7-499E-BD9A-B859C6203DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Yoshimumi,

Am 06.02.2015 um 06:18 schrieb = Yoshifumi Nishida <nishida@sfc.wide.ad.jp>:

Hi,
I also agree that this document is well written and we = already have seen some consensus to explore solutions for reordering = issue in the WG.

However, I personally have the following high-level questions = on the draft in order to think about it more. 

Q1: Do we think that = measuring reordering extent can be an approach for reordering = issue?

Measuring reordering per se or the extent itself? = It=E2=80=99s not a big deal to compute for example
the = reordering delay too.

Basically, or = draft compute the reordering extent of the IPPM RFC4737 on the transport = layer. 

    = One thing I'm wondering is that measured reordering extent is a kind of = historic data. So, to utilize this data properly, we might need to = understand how previous reorder extent is relevant to present or future = trends.

Yes = this is right. But this discussion belongs not to this draft. I belongs = to the reaction draft.
It=E2=80=99s clear that all adaptive = reordering =E2=80=9Ereaction=E2=80=9C algorithms have the problem that = they need
a couple of old events to set the threshold right, = which maybe too late for short TCP flows.
But have in mind, = TCP-aNCR has two modi. We can run it w/ and w/o the = adaptive
part. This is exactly the reason why at least the = reaction draft is experimental. It should be
part of the = experiment to investigate in which cases an adaptive algorithms makes = more
sense than a non-adaptive one.

Do we have some understandings = or consensus on this?

IMO yes because we have an song consensus on the = question if we would like to make
TCP more robust against = reordering. The first step in this direction is to detected = and
quantify the perceived reordering. This is what the draft = is about. We do not change anything
at TCP layer (protocol, = behavior). What we can discuss is if extent is the only metric = we
should implement, but IMO we can do that after an adoption = call.

Or, can we = utilize this data in other ways?

IPPM?

Q2: Even if we=E2=80=99re not very = sure about Q1, do we think we can proceed this idea in order to explore = the answers for Q1?

Yes, I believe so.


Thanks,
--
Yoshi
  =   

On Thu, Feb 5, 2015 at 11:48 AM, Wesley Eddy <wes@mti-systems.com> = wrote:
I reviewed the = reordering detection algorithm document:
https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-de= tection-02

The document is very well written.  The specification in the draft = seems
quite clear and like it would be easy to implement directly from the
document.

The purpose of section 4.7 ("Placeholder for Response Algorithm") = isn't
clear to me, especially in relation to the separate reaction draft
(draft-zimmermann-tcpm-reordering-reaction).

One thing that was unclear to me, and seems useful, is a discussion = of
the potential sources of error.  In other words, what events = would
cause the computed metrics to be wrong and how significantly wrong?
There are a number of different events and potential corner cases = that
are already addressed in the algorithm, and it wasn't clear to me
"what's left" or if it's supposed to just work perfectly in all = cases.
(I'm sure it's not!)

Obvious things that occurred to me were:
- different compositions of loss and reordering "features" in the
  forward path:
  - lossiness followed by reordering
  - reordering followed by lossiness
  - reordering followed by reordering somewhere else (and do we = even
    care about this, since it's the state of the packets at = the
    receiver that matters, and not how many times the order = has been
    shuffled)
- loss and reordering in the ACK path

The sensitivity to these things, I think, matters in understanding = the
utility of the computed metrics, and their feedback into a response
function.


--
Wes Eddy
MTI Systems

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

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

= --Apple-Mail=_35ABD6DD-81D7-499E-BD9A-B859C6203DB1-- --Apple-Mail=_C4BF541F-6C72-461C-A893-9632B9ADFDDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTVBsAACgkQdyiq39b9uS71tgCfSOlWNSpD7ZQGVudxWHcgxsQI 9W8An3R0cN7cjooTMl0W2lLLcyAgf2AG =aE1q -----END PGP SIGNATURE----- --Apple-Mail=_C4BF541F-6C72-461C-A893-9632B9ADFDDE-- From nobody Fri Feb 6 10:46:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826841A876B for ; Fri, 6 Feb 2015 10:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D-ltorkEqnX5 for ; Fri, 6 Feb 2015 10:46:43 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566C31A19F0 for ; Fri, 6 Feb 2015 10:46:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,530,1418112000"; d="asc'?scan'208";a="21411429" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 06 Feb 2015 10:41:42 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 6 Feb 2015 10:41:42 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5ceb:17f1:1ecd:c4c9%21]) with mapi id 15.00.0995.031; Fri, 6 Feb 2015 10:41:42 -0800 From: "Zimmermann, Alexander" To: Wesley Eddy Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-reordering-detection Thread-Index: AQHQQXzFva7VDhVhZUSRjwVCoGgnfpzjm8+AgAAGHQCAANo/AA== Date: Fri, 6 Feb 2015 18:41:41 +0000 Message-ID: <71D50EDC-8253-4A5D-9FA2-D5C4BC34FD7C@netapp.com> References: <54D3C911.6020205@mti-systems.com> <54D453C4.7070107@mti-systems.com> In-Reply-To: <54D453C4.7070107@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_BE603F55-703B-4BD9-8D88-0A737704FDF9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:46:47 -0000 --Apple-Mail=_BE603F55-703B-4BD9-8D88-0A737704FDF9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Wes, > Am 06.02.2015 um 06:40 schrieb Wesley Eddy : > > On 2/6/2015 12:18 AM, Yoshifumi Nishida wrote: >> Hi, >> I also agree that this document is well written and we already have seen >> some consensus to explore solutions for reordering issue in the WG. >> >> However, I personally have the following high-level questions on the >> draft in order to think about it more. >> >> Q1: Do we think that measuring reordering extent can be an approach for >> reordering issue? >> One thing I'm wondering is that measured reordering extent is a kind >> of historic data. So, to utilize this data properly, we might need to >> understand how previous reorder extent is relevant to present or future >> trends. Do we have some understandings or consensus on this? Or, can we >> utilize this data in other ways? >> > > > This is a good point, since reordering could be due to a transient > that occurs once during a connection and never again (e.g. some > change in the underlying path), or it could be persistent due to > properties of the path fixed for the life of the connection. > > It's difficult / impossible to tell the difference on a shorter > connection, or even on many short connections between the same > hosts, but if you could tell the difference, that would determine > the proper use of the metrics. > > In the 1st case, it doesn't seem like TCP should be doing anything > beyond just reversing state changes made due to a spurious decision. > > In the 2nd case, the reordering metrics that are measured would be > useful to cache along with the other path metrics that are already > cached. > You are right. This discussion is currently missing in the (reaction draft. I need to write a paragraph w/o a couple of recommendation in which scenarios the non-adaptive mode may lead to better performance. For example I run my experience in Linux, which has a (more or less) proper undoing strategy. In case undoing is not implemented, the adaptive mode could be have negative effects since you need a couple reordering events (which will be let to spurious retransmissions) to set the threshold appropriate. Alex > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_BE603F55-703B-4BD9-8D88-0A737704FDF9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTVCtgACgkQdyiq39b9uS58IgCg3EViVk4LHwGFAMiCss+UIa4m 528AoJyGffcD61FVulvO28VZy7UXPzAt =2EQ6 -----END PGP SIGNATURE----- --Apple-Mail=_BE603F55-703B-4BD9-8D88-0A737704FDF9-- From nobody Fri Feb 6 12:11:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46421A1AF4 for ; Fri, 6 Feb 2015 12:11:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 Nhb5ISJqgJ9m for ; Fri, 6 Feb 2015 12:11:36 -0800 (PST) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB9E1A0377 for ; Fri, 6 Feb 2015 12:11:35 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t16KBXit011811 for ; Fri, 6 Feb 2015 15:11:33 -0500 Received: (qmail 11583 invoked by uid 0); 6 Feb 2015 20:11:33 -0000 X-TCPREMOTEIP: 207.54.183.210 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@207.54.183.210) by 0 with ESMTPA; 6 Feb 2015 20:11:33 -0000 Message-ID: <54D51FEF.9080607@mti-systems.com> Date: Fri, 06 Feb 2015 15:11:27 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] 793bis update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 20:11:39 -0000 FYI - I posted an update to the proposed RFC793bis (still an individual, not a working group draft): http://tools.ietf.org/html/draft-eddy-rfc793bis-05 The main goals in this revision was to introduce a section on segmentation of data and place into that section the normative content from RFCs that updated 793 and cover the MSS & PMTU topics. You can easily view the diffs from -04 here: http://tools.ietf.org/rfcdiff?url2=draft-eddy-rfc793bis-05.txt -- Wes Eddy MTI Systems From nobody Sat Feb 7 00:17:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798281A888C for ; Sat, 7 Feb 2015 00:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 wBpy8qRijolR for ; Sat, 7 Feb 2015 00:17:40 -0800 (PST) Received: from h1346787.stratoserver.net (h1346787.stratoserver.net [85.214.49.182]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5281A1A50 for ; Sat, 7 Feb 2015 00:17:40 -0800 (PST) Received: from 44.173-67-87.adsl-dyn.isp.belgacom.be ([87.67.173.44] helo=ultra.localnet) by h1346787.stratoserver.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YK0aA-0003pW-16 for tcpm@ietf.org; Sat, 07 Feb 2015 09:17:38 +0100 From: Carsten Wolff To: tcpm@ietf.org Date: Sat, 07 Feb 2015 09:17:36 +0100 Message-ID: <3287037.dCkuTZL5zl@ultra> User-Agent: KMail/4.14.2 (Linux/3.13.0-45-generic; KDE/4.14.2; x86_64; ; ) In-Reply-To: <2D80ECE1-AB25-4A39-8D43-92862C90A5EF@netapp.com> References: <54D3C911.6020205@mti-systems.com> <2D80ECE1-AB25-4A39-8D43-92862C90A5EF@netapp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 08:17:44 -0000 Hi, On Friday 06 February 2015 18:24:16 Zimmermann, Alexander wrote: > > > > Am 06.02.2015 um 06:18 schrieb Yoshifumi Nishida : > > > > Q1: Do we think that measuring reordering extent can be an approach= for > > reordering issue? > > Measuring reordering per se or the extent itself? It=E2=80=99s not a = big deal to > compute for example the reordering delay too. I think the answer to this lies in RFC5681. The current approach counts= =20 dupacks with a threshold of 3 to distinguish loss from reordering. If a= =20 possible reaction algorithm stays with counting dupacks and adapting th= e=20 threshold (like our proposed reaction), then the extent is the metric i= t=20 needs. If the detection draft should want to keep the door open for a r= eaction=20 that replaces the dupack-counting by e.g. a timer, then it would be nee= ding a=20 metric that measures time in the detection. More generally, RFC4653 is a good approach at reordering without a dete= ction=20 and the reaction draft is based on it. Adding a detection and making th= e=20 threshold adaptive is a way of fixing the problem of RFC4653 that it hu= rts=20 performance in the common case where the path has loss and no reorderin= g.=20 Judging from old netdev-discussions, this always was the argument again= st 4653=20 that kept people from implementing it for Linux. Thanks for the review! Carsten From nobody Mon Feb 9 18:12:05 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8651A8A8D for ; Mon, 9 Feb 2015 18:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BQ2QTBTaFX6Y for ; Mon, 9 Feb 2015 18:11:47 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (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 2623D1A6F96 for ; Mon, 9 Feb 2015 18:11:47 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id r5so4650432qcx.10 for ; Mon, 09 Feb 2015 18:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lmkz3QEZ/ocj96CtPv9N3AK2uJjGrnaQuleCfuAxC44=; b=MfzEjUe8UsVZjeiPU/8LcQtuij8d5kMLsbQ6ZaPJrlmTw22hmjtL0JbYw2ql+AIHgq uQBpgOoNpuhuGe63aH76jWbABzpaz5h8T2FGyi604yAQ08bIE9sh/s5xMzePPiJZKgF3 IxtQENdkeugFGF04ixyo5xCoEK9iCmS908NmOxhDCk2KpDaNwvnP900UrEDa5AY7n1uv 46Oe1a7+3fL9HPQKtfEaCKAsdub/Fdjk8gjeJdc7P4i9hifO6kICnd9mwlkYCJ6MIKXU LSYPAfBAWMedEBdU/VCVy76ifyJx1S7Yik6+J72rszFCgigrg5slTOFEZN0c3MT8rEyb KgIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=lmkz3QEZ/ocj96CtPv9N3AK2uJjGrnaQuleCfuAxC44=; b=lz5dwy8PcrD0y4TpFUS6oJGICrfnAfQMHQPSw1CZoINpbavC/xghGUKDXFKhnQhxXJ 2OGlwxj2tiPcamJK6Eg6nlCBu/ExSsr23u9iomk7Z92KjqJNyxt+DN5E8lYyvJGmR/Ex FvpFLEBB1w3uCleteHIFVRmrjBwPctFAdEKzFJ43s94Po7CioaYzcTVQC6dmIin7opzq hpr4peaVXxaxbfVJTBK7o+ZdKvaMr5YXRRuEvIAmDya9NJsnjsxZOfe8iZcOw12YH8rz B6Hblbv4l+DZ4Al9Z8wuGrW+rIZEkVO99b9etlTZOxo47gUmV515OEujN5dWpo9Y6MAJ 914w== X-Gm-Message-State: ALoCoQlMcb659rUqrtTiNoEa/7B/auC8TwtPdcnO6hrVzmj1HdD8AKlWNvCFQz2kYBkbNnBbKmMc MIME-Version: 1.0 X-Received: by 10.140.86.75 with SMTP id o69mr45995447qgd.98.1423534306301; Mon, 09 Feb 2015 18:11:46 -0800 (PST) Received: by 10.140.137.68 with HTTP; Mon, 9 Feb 2015 18:11:46 -0800 (PST) Date: Mon, 9 Feb 2015 21:11:46 -0500 Message-ID: From: Neal Cardwell To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Dumazet Subject: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 02:11:50 -0000 TCP DoS scenarios involving ACK loops (aka "ACK storms" or "packet wars") have come up previously on the TCPM list. For example, Anil Agarwal brought them up in the Nov 2013 TCPM thread "TCP mismatched sequence numbers issue" I wanted to mention that our TCP team at Google has recently submitted a patch series for Linux that mitigates such attacks by rate-limiting the dupacks that are sent in response to out-of-window incoming packets. The code has been in use at Google and was recently merged into the official Linux "net-next" tree, which means that it should land in the next official Linux release. The patch series summary can be browsed at the following URL: http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=f06535c599354816cfbc653ce8965804c7385c61 Below I'm including the cover letter summarizing the patch series, for convenience/reference. We are interested to hear any feedback folks may have. Thanks! neal ============== tcp: mitigate TCP ACK loops due to out-of-window validation dupacks This patch series mitigates "ack loop" DoS scenarios by rate-limiting outgoing duplicate ACKs sent in response to incoming "out of window" segments. Background ----------- There are several cases in which the TCP RFCs specify that a TCP endpoint should send a pure duplicate ACK in response to a pure duplicate ACK that appears to be invalid due to being "out of window": (1) RFC 793 (section 3.9, page 69) specifies that endpoints should send a duplicate ACK in response to an ACK when the incoming sequence number is invalid due to being outside the receive window: "If an incoming segment is not acceptable, an acknowledgment should be sent in reply". (2) RFC 793 (section 3.9, page 72) says: "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK". (3) RFC 1323 (section 4.2.1, page 18) specifies that endpoints should send a duplicate ACK in response to an ACK when the PAWS check for the incoming timestamp value fails: "If .... SEG.TSval < TS.Recent and if TS.Recent is valid ... Send an acknowledgement in reply" The problem ------------ Normally, this is not a problem. However, a buggy middlebox or malicious man-in-the-middle can inject a few packets into the conversation that advance each endpoint's notion of the current window (sequence, ACK, or timestamp), without either side noticing. In this case, from then on each side can think the other is sending invalid segments. Thus an infinite feedback loop of duplicate ACKs can ensue, as each endpoint receives a duplicate ACK, decides that it is invalid (due to sequence number, ACK number, or timestamp), and then sends a dupack in reply, which the other side decides is invalid, responding with a dupack... ad infinitum. This ping-pong feedback loop can happen at a very high rate. This phenomenon can and does happen in practice. It has been seen in datacenter and Internet contexts at Google, and has been documented by Anil Agarwal in the Nov 2013 tcpm thread "TCP mismatched sequence numbers issue", and Avery Fay in the Feb 2015 Linux netdev thread "Invalid timestamp? causing tight ack loop (hundreds of thousands of packets / sec)". This patch series ------------------ This patch series mitigates such ack loops by rate-limiting outgoing duplicate ACKs sent in response to incoming TCP packets that are for an existing connection but that are invalid due to any of the reasons mentioned above: sequence number (1), ACK field (2), or timestamp value (3). The rate limit for such duplicate ACKs is specified by a new sysctl, tcp_invalid_ratelimit, which specifies the minimal space between such outbound duplicate ACKs, in milliseconds. The default is 500 (500ms), and 0 disables the mechanism. We rate-limit these duplicate ACK responses rather than blocking them entirely or resetting the connection, because legitimate connections can rely on dupacks in response to some out-of-window segments. For example, zero window probes are typically sent with a sequence number that is below the current window, and ZWPs thus expect to thus elicit a dupack in response. Testing: this approach has been in use at Google for a while. From nobody Tue Feb 10 00:08:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A709D1A0275 for ; Tue, 10 Feb 2015 00:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.311 X-Spam-Level: X-Spam-Status: No, score=-8.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xUrzOAFJr8-A for ; Tue, 10 Feb 2015 00:08:28 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651091A0173 for ; Tue, 10 Feb 2015 00:08:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,548,1418112000"; d="asc'?scan'208";a="22867095" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 10 Feb 2015 00:03:27 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 10 Feb 2015 00:03:26 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::fd84:3b4:c925:550f%21]) with mapi id 15.00.0995.031; Tue, 10 Feb 2015 00:03:27 -0800 From: "Zimmermann, Alexander" To: Eddy Wesley , "tcpm@ietf.org" , "Neal Cardwell" Thread-Topic: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks Thread-Index: AQHQRNby64zDLyB9ekq+ZyjM0ZzskZzqDIQA Date: Tue, 10 Feb 2015 08:03:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_56FABF39-C409-4C36-8B10-5AA0BE1F4194"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 08:08:35 -0000 --Apple-Mail=_56FABF39-C409-4C36-8B10-5AA0BE1F4194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I discussed this patch a bit w/ Neal yesterday. It was not clear to me (and maybe shame on me) that exist cases in which TCP sends an (DUP)ACK in response to a pure ACK. Parts of this =E2=80=9Eproblem=E2=80=9C = belongs to RFC793 (see background below). It=E2=80=99s maybe a good opportunity to include = some text about this in RFC793bis. BTW: Do we think as WG that 793bis is a good thing to do? And if the answer is yes, why do we not start an adoption call? Alex > Am 10.02.2015 um 03:11 schrieb Neal Cardwell : >=20 > TCP DoS scenarios involving ACK loops (aka "ACK storms" or "packet > wars") have come up previously on the TCPM list. For example, Anil > Agarwal brought them up in the Nov 2013 TCPM thread "TCP mismatched > sequence numbers issue" >=20 > I wanted to mention that our TCP team at Google has recently submitted > a patch series for Linux that mitigates such attacks by rate-limiting > the dupacks that are sent in response to out-of-window incoming > packets. The code has been in use at Google and was recently merged > into the official Linux "net-next" tree, which means that it should > land in the next official Linux release. >=20 > The patch series summary can be browsed at the following URL: >=20 > = http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=3D= f06535c599354816cfbc653ce8965804c7385c61 >=20 > Below I'm including the cover letter summarizing the patch series, for > convenience/reference. >=20 > We are interested to hear any feedback folks may have. >=20 > Thanks! >=20 > neal >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > tcp: mitigate TCP ACK loops due to out-of-window validation dupacks >=20 > This patch series mitigates "ack loop" DoS scenarios by rate-limiting > outgoing duplicate ACKs sent in response to incoming "out of window" > segments. >=20 > Background > ----------- >=20 > There are several cases in which the TCP RFCs specify that a TCP > endpoint should send a pure duplicate ACK in response to a pure > duplicate ACK that appears to be invalid due to being "out of window": >=20 > (1) RFC 793 (section 3.9, page 69) specifies that endpoints should > send a duplicate ACK in response to an ACK when the incoming > sequence number is invalid due to being outside the receive > window: "If an incoming segment is not acceptable, an > acknowledgment should be sent in reply". >=20 > (2) RFC 793 (section 3.9, page 72) says: "If the ACK acknowledges > something not yet sent (SEG.ACK > SND.NXT) then send an ACK". >=20 > (3) RFC 1323 (section 4.2.1, page 18) specifies that endpoints should > send a duplicate ACK in response to an ACK when the PAWS check for > the incoming timestamp value fails: "If .... SEG.TSval < TS.Recent > and if TS.Recent is valid ... Send an acknowledgement in reply" >=20 > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_56FABF39-C409-4C36-8B10-5AA0BE1F4194 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTZu00ACgkQdyiq39b9uS43fwCg7pz9ZuAPk2Cslon6duzaItGy m7gAn3Qmex0W2bknj3oESTjz4fJHdKRW =giz3 -----END PGP SIGNATURE----- --Apple-Mail=_56FABF39-C409-4C36-8B10-5AA0BE1F4194-- From nobody Tue Feb 10 17:20:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D371A1AA4 for ; Tue, 10 Feb 2015 17:20:03 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 WYEGzaaeDe2P for ; Tue, 10 Feb 2015 17:19:52 -0800 (PST) Received: from atl4mhob02.myregisteredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) by ietfa.amsl.com (Postfix) with ESMTP id 221531A1A46 for ; Tue, 10 Feb 2015 17:19:50 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t1B1Jmlj010317 for ; Tue, 10 Feb 2015 20:19:48 -0500 Received: (qmail 13079 invoked by uid 0); 11 Feb 2015 01:19:48 -0000 X-TCPREMOTEIP: 162.17.211.93 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?10.128.2.10?) (wes@mti-systems.com@162.17.211.93) by 0 with ESMTPA; 11 Feb 2015 01:19:48 -0000 Message-ID: <54DAAE2B.3020002@mti-systems.com> Date: Tue, 10 Feb 2015 20:19:39 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" , "tcpm@ietf.org" , Neal Cardwell References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:20:03 -0000 On 2/10/2015 3:03 AM, Zimmermann, Alexander wrote: > Hi all, > > I discussed this patch a bit w/ Neal yesterday. It was not clear to me > (and maybe shame on me) that exist cases in which TCP sends an (DUP)ACK > in response to a pure ACK. Parts of this „problem“ belongs to RFC793 > (see background below). It’s maybe a good opportunity to include some > text about this in RFC793bis. I would be tempted to say "yes", however, to keep from opening the door to all kinds of changes and making RFC793bis intractable to get consensus on, I had proposed to only make changes that are already in other RFCs updating 793 or in verified errata. So, maybe someone should submit an errata on this? :) > BTW: Do we think as WG that 793bis is a good thing to do? And if the > answer is yes, why do we not start an adoption call? Sounds good to me :). -- Wes Eddy MTI Systems From nobody Wed Feb 11 02:39:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500C1A87CC for ; Wed, 11 Feb 2015 02:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Uh2oQMlR2ve9 for ; Wed, 11 Feb 2015 02:39:43 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 1E3711A87CB for ; Wed, 11 Feb 2015 02:39:42 -0800 (PST) Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85_42-aebaf3d) id 1YLUho-00028S-KS for tcpm@ietf.org (return-path ); Wed, 11 Feb 2015 10:39:40 +0000 Message-ID: <54DB316B.3030301@wizmail.org> Date: Wed, 11 Feb 2015 10:39:39 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) Archived-At: Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 10:39:45 -0000 On 10/02/15 02:11, Neal Cardwell wrote: > This patch series mitigates such ack loops by rate-limiting outgoing > duplicate ACKs sent in response to incoming TCP packets that are for > an existing connection but that are invalid due to any of the reasons > mentioned above: sequence number (1), ACK field (2), or timestamp > value (3). The rate limit for such duplicate ACKs is specified by a > new sysctl, tcp_invalid_ratelimit, which specifies the minimal space > between such outbound duplicate ACKs, in milliseconds. The default is > 500 (500ms), and 0 disables the mechanism. Would it not scale better over different link speeds to use a packet-counting approach rather than a rate limit? For example, output a dupACK only for alternate triggers. -- Cheers, Jeremy From nobody Wed Feb 11 05:21:05 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28101A88AD for ; Wed, 11 Feb 2015 05:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 lFvgqgPu3zny for ; Wed, 11 Feb 2015 05:20:55 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E3E1A8899 for ; Wed, 11 Feb 2015 05:20:53 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id p6so2617359qcv.12 for ; Wed, 11 Feb 2015 05:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WixcvJnBvJkN/P4sMCJO3IiVSJYsd+EI1SoaM9J6UFQ=; b=bcJJDBQpxMMLJCdSCIxWl0nCKccSdnn82MsrquadD5wCytGBl9Ca4FSkwguPMI4ovz BlnMoK7zMiuFMY6ngDWDEHfRvJjC9ohtFcVrmUjlNr2ylzgxKupVBhpGZcBxMNJg6g/f DG6vFa61blFnzcUsBRTFF4aGsZrNXo30wmHx83KiLlrBL9zaYpKDNOWyVq0vqZ7FfwGA apZwtTuO0bsJDL5XeiabOB+c2veGi6WIwP7U/vmSrrA8jTOdlK+lZ99uYuhNUHLc9MrY IcnoAmxVreGg6Kdz68yfaLWS+sVJ03OqgDWPcXyMRkoZmdxmgoWRfHaupk9TF5cBMf8K 53KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WixcvJnBvJkN/P4sMCJO3IiVSJYsd+EI1SoaM9J6UFQ=; b=CweU9PiG9s8tUvYfBTtu8gfo+R758vfyxorY92pfoQTO9mHtJlgr1BgaqUuvWk2S1P WUO3mFPOUhiV5ZoGBupdNX76fXr4L9a/fbvQscwmh4ASaxloMptXjCWPZC7mcaFHp3fS XyzAX5iJe+4UFhhHMsTKPj3e8CPOmCfqk5IH97CsvznNnnajrffBlDCufxDdCKHgsOAJ FTHSfVpHDc0m3R/M3DEdFnwxHWwJxPP4xO2NWFEe5wAj1FEwejEU4RNuNVBCVLO1dYac cSSUF1N+a6bBlLr7oEOWwVLaOLwkE1tIaK/d/9iKg6CM4b4rYe1LhefYBzYsbAmxFxTZ FsWQ== X-Gm-Message-State: ALoCoQnn7PmQ+GsvuFL6dTzzrPCwIkqmZin1Zado/VJfSYfsOBgRzHKAsN1vJN6Ei2VCcrVCXf9b MIME-Version: 1.0 X-Received: by 10.224.55.71 with SMTP id t7mr64659209qag.53.1423660852655; Wed, 11 Feb 2015 05:20:52 -0800 (PST) Received: by 10.140.137.68 with HTTP; Wed, 11 Feb 2015 05:20:52 -0800 (PST) In-Reply-To: <54DB316B.3030301@wizmail.org> References: <54DB316B.3030301@wizmail.org> Date: Wed, 11 Feb 2015 08:20:52 -0500 Message-ID: From: Neal Cardwell To: Jeremy Harris Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:20:57 -0000 On Wed, Feb 11, 2015 at 5:39 AM, Jeremy Harris wrote: > On 10/02/15 02:11, Neal Cardwell wrote: >> This patch series mitigates such ack loops by rate-limiting outgoing >> duplicate ACKs sent in response to incoming TCP packets that are for >> an existing connection but that are invalid due to any of the reasons >> mentioned above: sequence number (1), ACK field (2), or timestamp >> value (3). The rate limit for such duplicate ACKs is specified by a >> new sysctl, tcp_invalid_ratelimit, which specifies the minimal space >> between such outbound duplicate ACKs, in milliseconds. The default is >> 500 (500ms), and 0 disables the mechanism. > > Would it not scale better over different link speeds to use a > packet-counting approach rather than a rate limit? For example, > output a dupACK only for alternate triggers. In our case the most common problem was with a middlebox that was not only (a) desynchronizing the endpoints' notions of the window, but also (b) duplicating packets to a high degree. So sending a dupack once per 2 or even once per 32 packets was not enough to break the loop. If we had responded to one in every 64 incoming out-of-window packets, that probably would have broken the DoS loop. However, if we respond to only one in every 64 incoming out-of-window packets then responses to legitimate traffic become too infrequent. For example, if the out-of-window packets are zero window probes that the remote endpoint is sending in an exponentially-backed-off fashion (very common), then I'd imagine that responding to only 1 in 64 exponentially-backed-off window-probe packets means that the remote endpoint is often going to give up and close the connection before they ever get an ACK with a non-zero window. As for different link speeds, two ACKs per second means we bound outgoing dupacks to 1Kbit/sec, which is tolerable for most Internet hosts. If we were to use a packet-counting approach, then with a middlebox multiplying incoming packets there is no bound on the outgoing bit rate of our dupacks, and we are more likely to overload the remote host's link. neal From nobody Tue Feb 17 05:47:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BEB1A896F for ; Tue, 17 Feb 2015 05:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 C1DVWLeCxg6J for ; Tue, 17 Feb 2015 05:47:38 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252941A899A for ; Tue, 17 Feb 2015 05:47:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DCA75D930D; Tue, 17 Feb 2015 14:47:28 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ru2nqtkon0qB; Tue, 17 Feb 2015 14:47:28 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A2F39D930C; Tue, 17 Feb 2015 14:47:28 +0100 (MET) Message-ID: <54E34670.1090305@tik.ee.ethz.ch> Date: Tue, 17 Feb 2015 14:47:28 +0100 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Neal Cardwell , "tcpm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Eric Dumazet Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 13:47:42 -0000 Hi all, I probably have a stupid question, but I'll ask anyway as rate-limiting the ACK seems to help the problem but also seems to be kind of a hack and might not resolvie the actually cause of the problem. The question is, why does RFC 793 (section 3.9, page 72) say: "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK"? In this situation the two end points seem to be out of syn, so you have two options: 1) reset the connection and start over. 2) try to resyn which probably means you discard/invalidate (?) the data that have been wrongly acknowledged... What do I miss? Mirja On 10.02.2015 03:11, Neal Cardwell wrote: > TCP DoS scenarios involving ACK loops (aka "ACK storms" or "packet > wars") have come up previously on the TCPM list. For example, Anil > Agarwal brought them up in the Nov 2013 TCPM thread "TCP mismatched > sequence numbers issue" > > I wanted to mention that our TCP team at Google has recently submitted > a patch series for Linux that mitigates such attacks by rate-limiting > the dupacks that are sent in response to out-of-window incoming > packets. The code has been in use at Google and was recently merged > into the official Linux "net-next" tree, which means that it should > land in the next official Linux release. > > The patch series summary can be browsed at the following URL: > > http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=f06535c599354816cfbc653ce8965804c7385c61 > > Below I'm including the cover letter summarizing the patch series, for > convenience/reference. > > We are interested to hear any feedback folks may have. > > Thanks! > > neal > > ============== > > tcp: mitigate TCP ACK loops due to out-of-window validation dupacks > > This patch series mitigates "ack loop" DoS scenarios by rate-limiting > outgoing duplicate ACKs sent in response to incoming "out of window" > segments. > > Background > ----------- > > There are several cases in which the TCP RFCs specify that a TCP > endpoint should send a pure duplicate ACK in response to a pure > duplicate ACK that appears to be invalid due to being "out of window": > > (1) RFC 793 (section 3.9, page 69) specifies that endpoints should > send a duplicate ACK in response to an ACK when the incoming > sequence number is invalid due to being outside the receive > window: "If an incoming segment is not acceptable, an > acknowledgment should be sent in reply". > > (2) RFC 793 (section 3.9, page 72) says: "If the ACK acknowledges > something not yet sent (SEG.ACK > SND.NXT) then send an ACK". > > (3) RFC 1323 (section 4.2.1, page 18) specifies that endpoints should > send a duplicate ACK in response to an ACK when the PAWS check for > the incoming timestamp value fails: "If .... SEG.TSval < TS.Recent > and if TS.Recent is valid ... Send an acknowledgement in reply" > > The problem > ------------ > > Normally, this is not a problem. However, a buggy middlebox or > malicious man-in-the-middle can inject a few packets into the > conversation that advance each endpoint's notion of the current window > (sequence, ACK, or timestamp), without either side noticing. In this > case, from then on each side can think the other is sending invalid > segments. Thus an infinite feedback loop of duplicate ACKs can ensue, > as each endpoint receives a duplicate ACK, decides that it is invalid > (due to sequence number, ACK number, or timestamp), and then sends a > dupack in reply, which the other side decides is invalid, responding > with a dupack... ad infinitum. This ping-pong feedback loop can happen > at a very high rate. > > This phenomenon can and does happen in practice. It has been seen in > datacenter and Internet contexts at Google, and has been documented by > Anil Agarwal in the Nov 2013 tcpm thread "TCP mismatched sequence > numbers issue", and Avery Fay in the Feb 2015 Linux netdev thread > "Invalid timestamp? causing tight ack loop (hundreds of thousands of > packets / sec)". > > This patch series > ------------------ > > This patch series mitigates such ack loops by rate-limiting outgoing > duplicate ACKs sent in response to incoming TCP packets that are for > an existing connection but that are invalid due to any of the reasons > mentioned above: sequence number (1), ACK field (2), or timestamp > value (3). The rate limit for such duplicate ACKs is specified by a > new sysctl, tcp_invalid_ratelimit, which specifies the minimal space > between such outbound duplicate ACKs, in milliseconds. The default is > 500 (500ms), and 0 disables the mechanism. > > We rate-limit these duplicate ACK responses rather than blocking them > entirely or resetting the connection, because legitimate connections > can rely on dupacks in response to some out-of-window segments. For > example, zero window probes are typically sent with a sequence number > that is below the current window, and ZWPs thus expect to thus elicit > a dupack in response. > > Testing: this approach has been in use at Google for a while. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Tue Feb 17 06:17:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63941A8948 for ; Tue, 17 Feb 2015 06:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rs7M354DCzQ9 for ; Tue, 17 Feb 2015 06:17:43 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 157551A8946 for ; Tue, 17 Feb 2015 06:17:42 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 520A459D9D5C5; Tue, 17 Feb 2015 14:17:35 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t1HEHUuX024440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 15:17:35 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.88]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 15:17:33 +0100 From: "Scharf, Michael (Michael)" To: Wesley Eddy , "Zimmermann, Alexander" , "tcpm@ietf.org" , "Neal Cardwell" Thread-Topic: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks Thread-Index: AQHQRNb0z7KIM1grsEi1eg+qn44RgZzpdaYAgAEhhICAClPM8A== Date: Tue, 17 Feb 2015 14:17:33 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C030CA@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <54DAAE2B.3020002@mti-systems.com> In-Reply-To: <54DAAE2B.3020002@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:17:44 -0000 PiA+IEkgZGlzY3Vzc2VkIHRoaXMgcGF0Y2ggYSBiaXQgdy8gTmVhbCB5ZXN0ZXJkYXkuIEl0IHdh cyBub3QgY2xlYXIgdG8NCj4gbWUNCj4gPiAoYW5kIG1heWJlIHNoYW1lIG9uIG1lKSB0aGF0IGV4 aXN0IGNhc2VzIGluIHdoaWNoIFRDUCBzZW5kcyBhbg0KPiAoRFVQKUFDSw0KPiA+IGluIHJlc3Bv bnNlIHRvIGEgcHVyZSBBQ0suIFBhcnRzIG9mIHRoaXMg4oCecHJvYmxlbeKAnCBiZWxvbmdzIHRv IFJGQzc5Mw0KPiA+IChzZWUgYmFja2dyb3VuZCBiZWxvdykuIEl04oCZcyBtYXliZSBhIGdvb2Qg b3Bwb3J0dW5pdHkgdG8gaW5jbHVkZSBzb21lDQo+ID4gdGV4dCBhYm91dCB0aGlzIGluIFJGQzc5 M2Jpcy4NCj4gDQo+IA0KPiBJIHdvdWxkIGJlIHRlbXB0ZWQgdG8gc2F5ICJ5ZXMiLCBob3dldmVy LCB0byBrZWVwIGZyb20gb3BlbmluZyB0aGUgZG9vcg0KPiB0byBhbGwga2luZHMgb2YgY2hhbmdl cyBhbmQgbWFraW5nIFJGQzc5M2JpcyBpbnRyYWN0YWJsZSB0byBnZXQNCj4gY29uc2Vuc3VzIG9u LCBJIGhhZCBwcm9wb3NlZCB0byBvbmx5IG1ha2UgY2hhbmdlcyB0aGF0IGFyZSBhbHJlYWR5IGlu DQo+IG90aGVyIFJGQ3MgdXBkYXRpbmcgNzkzIG9yIGluIHZlcmlmaWVkIGVycmF0YS4NCj4NCj4g U28sIG1heWJlIHNvbWVvbmUgc2hvdWxkIHN1Ym1pdCBhbiBlcnJhdGEgb24gdGhpcz8gOikNCg0K SW5kZWVkLCB0aGlzIGlzc3VlIHNob3VsZCBiZSByZWNvcmRlZC4gWWV0LCByZWdhcmRpbmcgYSBz b2x1dGlvbiwgSSB3b25kZXIgaWYgYW4gZXJyYXRhIHdvdWxkIGluZGVlZCBiZSBzdWZmaWNpZW50 LiBJZiB0aGUgZXZlbnQgcHJvY2Vzc2luZyBpbiBSRkMgNzkzIGhhcyB0byBiZSBtb2RpZmllZCwg aXQgc2VlbXMgdG8gbW9kaWZ5IFRDUCBvbi10aGUtd2lyZSBpbiB0aGlzIHNwZWNpZmljIGNvcm5l ciBjYXNlLg0KDQpEb2VzIHNvbWVib2R5IGtub3cgd2hhdCBzdGFja3Mgb3RoZXIgdGhhbiBMaW51 eCBkbyBpbiB0aGlzIGNhc2U/IA0KDQpNaWNoYWVsIChhcyBpbmRpdmlkdWFsKQ0KDQo= From nobody Tue Feb 17 06:32:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148511A1ADF for ; Tue, 17 Feb 2015 06:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RmnFxSwUJ-sS for ; Tue, 17 Feb 2015 06:32:49 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D7F301A8992 for ; Tue, 17 Feb 2015 06:32:48 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 8206C13028A6C; Tue, 17 Feb 2015 14:32:44 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t1HEWkIM021488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 15:32:46 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.88]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 15:32:46 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AQHQSr6YFTfwxNVfnkCR1/yAHO5MLA== Date: Tue, 17 Feb 2015 14:32:45 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C0312D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:32:51 -0000 If somebody should have further thoughts on the suggested rechartering, it = would be excellent to speak up NOW... Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Tuesday, January 27, 2015 11:22 AM > To: tcpm@ietf.org > Cc: tcpm-chairs@tools.ietf.org > Subject: [tcpm] Rechartering TCPM for alternative congestion control > algorithms >=20 > Hi, >=20 > This e-mails asks for community feedback on a suggested small addon to > the TCPM charter [1]. >=20 > In the last TCPM meeting [2] there was strong support for adopting a > document describing the CUBIC congestion control algorithm [3]. To the > chairs, it is not entirely obvious whether this document, or possibly > other similar documents, would indeed be in scope of the current TCPM > charter. Given the importance of the TCP congestion control, we prefer > a community consensus explicitly documented in the charter instead of > ambiguity. >=20 > The current charter limits the scope of TCPM to "modest changes to the > protocol, algorithms, and interfaces". It allows "incremental > enhancements of TCP's standard congestion control" but explicitly > mandates rechartering for fundamental changes [1]: >=20 > OLD: >=20 > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control, but such changes > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. >=20 > We suggest to update this paragraph in the TCPM charter by an explicit > statement that "TCPM may document alternative congestion control > algorithms that are known to be widely deployed, and that are > considered safe for large-scale deployment in the Internet": >=20 > NEW: >=20 > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control. In addition, > TCPM may document alternative congestion control algorithms > that are known to be widely deployed, and that are considered > safe for large-scale deployment in the Internet. Changes of algorithms > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. >=20 > In our reading, "TCP's standard congestion control" is currently > defined by RFC 5681. >=20 > This e-mail and the suggested rechartering does not imply any adoption > of one or more alternative congestion control algorithms. >=20 > Any feedback regarding this suggested rechartering would be very > welcome. In particular, please let us know if there are any concerns > with this proposal or if you have suggestions for a different wording. > Please let us know any thoughts until Feb. 15, 2015. >=20 > Thanks a lot! >=20 > Michael, Pasi, Yoshifumi >=20 >=20 > [1] https://datatracker.ietf.org/wg/tcpm/charter/ >=20 > [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >=20 > [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From edumazet@google.com Tue Feb 17 07:23:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908BF1A89C5 for ; Tue, 17 Feb 2015 07:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KkolNhrCRoqN for ; Tue, 17 Feb 2015 07:23:17 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E0B1A896B for ; Tue, 17 Feb 2015 07:23:17 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id f51so28344862qge.12 for ; Tue, 17 Feb 2015 07:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2kjg9KgXCb7FTKf9isOtcHBD8lgsib+Rb41up2Eq7GY=; b=UbRi1uTxrnxDChC50w1dBcYuh62Y3BWkNtvQtHnNZ/SLEZFlQV0JEIqFvLafYyE6Vl FsoaoyOKfpgn2hw1cs3b+wc9J+3Q9lQRPyotocmfNv8w9IBEAZQZFiax2MyYgng2xRlD NOupSXpRsyUSf+U1Mc8zxGfNEAdDlmhBeE1I6gIGEFhNMxz9nbdQR92T7w30wFP9YKRE BiDk8S0vhjChJy9io4GBvrJolGR0XSapoqBXxsHjPy2wWZYwSTvElOTJN/5jYXwPeJb8 nqj1fV0pXMDGCLwYUFY8kMncHcHPRyXPdwj6PCCkmv8H2pR+fVgnyBAp8mX/Q/BmjoGC PdJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2kjg9KgXCb7FTKf9isOtcHBD8lgsib+Rb41up2Eq7GY=; b=Brnq4MWb8iinRChsf8bpifYX0C8GTmAY/0qWyLQB7uEbGQWjvkIoiYKdl9S/5joy+9 vrUf6Y5g1N7s5gVZFVSm9Q+EeHwaEx5/LnLAgmmynNYGQy6AH7PVqGeS4cmtDUta9y1G xSEXSZhK6OEgXNeSzdI9qcffqZtZ3YdW215BNMqAqHg+/TCtreaeTRNbxochWysezVdQ rYeDY2LwKPD9cGMdOPbJW8olVzLPb46zVANo2VM5dEcS8kFa7z9+8I5C6BPe7f09FmEw Sqa7V7xxUgtIHgmG1FVGaKsamOodQvr3MWbsyyPAeyYWogjWLTkHdD//2zqV0luHWPZy lnnA== X-Gm-Message-State: ALoCoQnK/7iDteImQyfuiamfug2u6AFu6Cs1x8ygQcZ3FXxasO0WzZ41Sqn3DA8XobrClcmRW6QK MIME-Version: 1.0 X-Received: by 10.229.219.10 with SMTP id hs10mr616465qcb.11.1424186596278; Tue, 17 Feb 2015 07:23:16 -0800 (PST) Received: by 10.229.70.196 with HTTP; Tue, 17 Feb 2015 07:23:16 -0800 (PST) In-Reply-To: <54E34670.1090305@tik.ee.ethz.ch> References: <54E34670.1090305@tik.ee.ethz.ch> Date: Tue, 17 Feb 2015 07:23:16 -0800 Message-ID: From: Eric Dumazet To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Tue, 17 Feb 2015 08:06:22 -0800 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] mitigating TCP ACK loop ("ACK storm") DoS attacks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:26:52 -0000 Hi Mirja I believe RFC 5961 might give appropriate answers to your question ? In general, we try to be conservative and gentle in our responses to apparently 'bad incoming' packets. Resetting a connection should only happen if we are certain the incoming packet is totally legitimate, not some leftover or malicious packet. But in some cases, being gentle can generate pathological ack storms. On Tue, Feb 17, 2015 at 5:47 AM, Mirja K=C3=BChlewind wrote: > Hi all, > > I probably have a stupid question, but I'll ask anyway as rate-limiting t= he > ACK seems to help the problem but also seems to be kind of a hack and mig= ht > not resolvie the actually cause of the problem. > > The question is, why does RFC 793 (section 3.9, page 72) say: "If the ACK > acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK"= ? > > In this situation the two end points seem to be out of syn, so you have t= wo > options: > 1) reset the connection and start over. > 2) try to resyn which probably means you discard/invalidate (?) the data > that have been wrongly acknowledged... > > What do I miss? > > Mirja > > > > > On 10.02.2015 03:11, Neal Cardwell wrote: >> >> TCP DoS scenarios involving ACK loops (aka "ACK storms" or "packet >> wars") have come up previously on the TCPM list. For example, Anil >> Agarwal brought them up in the Nov 2013 TCPM thread "TCP mismatched >> sequence numbers issue" >> >> I wanted to mention that our TCP team at Google has recently submitted >> a patch series for Linux that mitigates such attacks by rate-limiting >> the dupacks that are sent in response to out-of-window incoming >> packets. The code has been in use at Google and was recently merged >> into the official Linux "net-next" tree, which means that it should >> land in the next official Linux release. >> >> The patch series summary can be browsed at the following URL: >> >> >> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?i= d=3Df06535c599354816cfbc653ce8965804c7385c61 >> >> Below I'm including the cover letter summarizing the patch series, for >> convenience/reference. >> >> We are interested to hear any feedback folks may have. >> >> Thanks! >> >> neal >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> tcp: mitigate TCP ACK loops due to out-of-window validation dupacks >> >> This patch series mitigates "ack loop" DoS scenarios by rate-limiting >> outgoing duplicate ACKs sent in response to incoming "out of window" >> segments. >> >> Background >> ----------- >> >> There are several cases in which the TCP RFCs specify that a TCP >> endpoint should send a pure duplicate ACK in response to a pure >> duplicate ACK that appears to be invalid due to being "out of window": >> >> (1) RFC 793 (section 3.9, page 69) specifies that endpoints should >> send a duplicate ACK in response to an ACK when the incoming >> sequence number is invalid due to being outside the receive >> window: "If an incoming segment is not acceptable, an >> acknowledgment should be sent in reply". >> >> (2) RFC 793 (section 3.9, page 72) says: "If the ACK acknowledges >> something not yet sent (SEG.ACK > SND.NXT) then send an ACK". >> >> (3) RFC 1323 (section 4.2.1, page 18) specifies that endpoints should >> send a duplicate ACK in response to an ACK when the PAWS check for >> the incoming timestamp value fails: "If .... SEG.TSval < TS.Recent >> and if TS.Recent is valid ... Send an acknowledgement in reply" >> >> The problem >> ------------ >> >> Normally, this is not a problem. However, a buggy middlebox or >> malicious man-in-the-middle can inject a few packets into the >> conversation that advance each endpoint's notion of the current window >> (sequence, ACK, or timestamp), without either side noticing. In this >> case, from then on each side can think the other is sending invalid >> segments. Thus an infinite feedback loop of duplicate ACKs can ensue, >> as each endpoint receives a duplicate ACK, decides that it is invalid >> (due to sequence number, ACK number, or timestamp), and then sends a >> dupack in reply, which the other side decides is invalid, responding >> with a dupack... ad infinitum. This ping-pong feedback loop can happen >> at a very high rate. >> >> This phenomenon can and does happen in practice. It has been seen in >> datacenter and Internet contexts at Google, and has been documented by >> Anil Agarwal in the Nov 2013 tcpm thread "TCP mismatched sequence >> numbers issue", and Avery Fay in the Feb 2015 Linux netdev thread >> "Invalid timestamp? causing tight ack loop (hundreds of thousands of >> packets / sec)". >> >> This patch series >> ------------------ >> >> This patch series mitigates such ack loops by rate-limiting outgoing >> duplicate ACKs sent in response to incoming TCP packets that are for >> an existing connection but that are invalid due to any of the reasons >> mentioned above: sequence number (1), ACK field (2), or timestamp >> value (3). The rate limit for such duplicate ACKs is specified by a >> new sysctl, tcp_invalid_ratelimit, which specifies the minimal space >> between such outbound duplicate ACKs, in milliseconds. The default is >> 500 (500ms), and 0 disables the mechanism. >> >> We rate-limit these duplicate ACK responses rather than blocking them >> entirely or resetting the connection, because legitimate connections >> can rely on dupacks in response to some out-of-window segments. For >> example, zero window probes are typically sent with a sequence number >> that is below the current window, and ZWPs thus expect to thus elicit >> a dupack in response. >> >> Testing: this approach has been in use at Google for a while. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > -- > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland > > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ From nobody Tue Feb 17 11:09:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7B21A8882 for ; Tue, 17 Feb 2015 11:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 vlyO442URSjs for ; Tue, 17 Feb 2015 11:09:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EF51A8ABB for ; Tue, 17 Feb 2015 11:09:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217190942.20430.83312.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 11:09:42 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:09:45 -0000 Changed milestone "Submit document obsoleting undeployed TCP extensions to the IESG for publication as an Informational RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nobody Wed Feb 18 14:43:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDDF1A1B59; Wed, 18 Feb 2015 14:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wUp_c83VlesH; Wed, 18 Feb 2015 14:43:45 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA0D1A1B47; Wed, 18 Feb 2015 14:43:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,604,1418112000"; d="asc'?scan'208";a="25163208" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx141-out.netapp.com with ESMTP; 18 Feb 2015 14:38:44 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 18 Feb 2015 14:38:43 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::90b4:b24a:2e3b:2056%21]) with mapi id 15.00.0995.031; Wed, 18 Feb 2015 14:38:43 -0800 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-behave-requirements-update-01.txt Thread-Index: AQHQS3dswgmsO+I7ik64jTWP4nVMdpz3hnmA Date: Wed, 18 Feb 2015 22:38:43 +0000 Message-ID: <93B53A9C-BCDC-4254-8AC0-C7CBBDAEBEE6@netapp.com> References: <20150218123537.11748.78276.idtracker@ietfa.amsl.com> In-Reply-To: <20150218123537.11748.78276.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_F7E5816E-EB17-4E49-AFC0-BBFDDBAF2DB1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] I-D Action: draft-ietf-tsvwg-behave-requirements-update-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 22:43:47 -0000 --Apple-Mail=_F7E5816E-EB17-4E49-AFC0-BBFDDBAF2DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2015-2-18, at 04:35, internet-drafts@ietf.org wrote: >=20 > Title : Network Address Translation (NAT) Behavioral = Requirements Updates >=20 > Abstract: > This document clarifies and updates several requirements of RFC4787, > RFC5382 and RFC5508 based on operational and development experience. > The focus of this document is NAPT44. >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-tsvwg-behave-requirements-update-01 I gave this a quick read; here are some comments. Also CC'ing TCPM, as = this is of interest there. Lars Throughout: Please check your use of RFC2119 terms - some are user lowercase where I'd capitalize them, and vice versa. Section 2., paragraph 1: > [RFC5382] specifies TCP timers associated with various connection > states but does not specify the TCP state machine a NAPT44 should = use > as a basis to apply such timers. The TCP state machine depicted in > Figure 1, adapted from [RFC6146], provides guidance on how TCP > session tracking could be implemented - it is non-normative. So Figure 1 is not normative, but Section 2 is? (Because otherwise the RFC2119 language used in it doesn't make much sense.) Section 2.1., paragraph 2: > This document clarifies that a NAT device SHOULD provide different > knobs for configuring the open and closing idle timeouts. This > document further acknowledges that most TCP flows are very short > (less than 10 seconds) [FLOWRATE][TCPWILD] and therefore a = partially > open timeout of 4 minutes might be excessive if security is a > concern. Therefore, it MAY be configured to be less than 4 minutes > in such cases. There also may be cases that a timeout of 4 minutes > might be excessive. The case and the solution are written below. There seems to be some repetition in this paragraph. I also don't see the "case and the solution" anywhere following this. Finally, the average length of a TCP flow is completely unrelated to how long this timeout should be. The MSL, however, is related to this, and it's where the 4 minutes originated from. If you want to allow shortening this, you should explain why waiting for a fraction of an MSL is OK. Section 2.2., paragraph 0: > 2.2. TIME_WAIT State The language is pretty rough in some places in Section 2.2, to the point where it makes it difficult to understand what exactly is proposed. Section 2.2.1., paragraph 3: > Also, PAWS works to discard old duplicate packets at NAT. A packet > can be discarded as an old duplicate if it is received with a > timestamp or sequence number value less than a value recently > received on the connection. Why should the NAT not simply translate and forward these packets? This adds a bunch of complexity at the NAT that doesn't really seem to gain anything. Section 2.2.1.1., paragraph 3: > B: NAT rewrite timestamp and sequence number values of incoming > packets to be monotonically increasing. If the NAT mucks around with the timestamp options, how is this going ot affect TCP's RTT calculation? Which fields of the Timestamp option are being rewritten here? Section 2.2.1.2., paragraph 0: > 2.2.1.2. Split an assignable number of port space to each client This section needs more text. I can't understand what the proposal is. Section 2.3., paragraph 0: > To solve the port shortage problem on the client side, the behavior > of remote host should be compliant to [RFC6191] or the mechanism > written in Section 4.2.2.13 of [RFC1122], since NAT may reuse the > same 5 tuple for a new connection. We have investigated behaviors = of > OSes (e.g., Linux, FreeBSD, Windows, MacOS), and found that they > implemented the server side behavior of the above two. Which versions of these operating systems have you tested? Section 2.3., paragraph 1: > [RFC5382] leaves the handling of TCP RST packets unspecified. This > document does not try standardize such behavior but clarifies based > on operational experience that a NAT that receives a TCP RST for an > active mapping and performs session tracking MAY immediately delete > the sessions and remove any state associated with it. If the NAT > device that performs TCP session tracking receives a TCP RST for = the > first session that created a mapping, it MAY remove the session and > the mapping immediately. If the NAT kills the binding after forwarding an RST, and that RST is lost between the NAT and the recipient, any retransmission of the RST by the other end will not be forwarded. This may cause connection stalls. Section 3., paragraph 4: > [RFC4787] and [RFC5382] requires "endpoint-independent mapping" at > NAT, and port overlapping NAT cannot meet the requirement. This > mechanism can degrade the transparency of NAT in that its mapping > mechanism is endpoint-dependent and makes NAT traversal harder. > However, if a NAT adopts endpoint-independent mapping together with > endpoint-dependent filtering, then the actual behavior of the NAT > will be the same as port overlapping NAT. There was a reason why EIM was chosen in those past RFCs. Has the rationale here changed? Section 5., paragraph 1: > [RFC4787]:REQ-8 and [RFC5382]:REQ-3 End-point independent filtering > could potentially result in security attacks from the public realm. NATs do not perform a security function. That is why we have firewalls. We had long discussions in the past on this difference. --Apple-Mail=_F7E5816E-EB17-4E49-AFC0-BBFDDBAF2DB1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVOUUc9ZcnpRveo1xAQJQOgP+J+dTbd7pg/OSGT25T6NFCTVCDDtmCzEq SDDpcBXShVlqsXH4lN32kGPC1XwGR64vxIkk+Fs4fcEIcPRtxgCJhr9lwyx6RF+/ iSXPi2VMOKcpI63Sg0p1MVR7zLKq5NEodI0n+2hQq51uPA9o3QVQNKeJWHrLEQOh httuGa/l7mI= =uBI9 -----END PGP SIGNATURE----- --Apple-Mail=_F7E5816E-EB17-4E49-AFC0-BBFDDBAF2DB1-- From nobody Sat Feb 21 11:20:28 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA81A1AD3; Fri, 20 Feb 2015 20:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xyTummrFwJYX; Fri, 20 Feb 2015 20:47:10 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429AF1A1ADA; Fri, 20 Feb 2015 20:47:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,618,1418112000"; d="asc'?scan'208,217";a="24598061" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 20 Feb 2015 20:42:09 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Feb 2015 20:42:09 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::90b4:b24a:2e3b:2056%21]) with mapi id 15.00.0995.031; Fri, 20 Feb 2015 20:42:09 -0800 From: "Eggert, Lars" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Thread-Topic: [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt Thread-Index: AQHQTZC/SIQvY3u84UqUDGG56FgNbQ== Date: Sat, 21 Feb 2015 04:42:08 +0000 Message-ID: <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> References: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> In-Reply-To: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_6659FDC8-00EC-4963-AFF1-54529A957813"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 21 Feb 2015 11:20:27 -0800 Cc: "Arunachalam, Swaminathan \(NSN - US/Irving\)" , "tsvwg@ietf.org" , "tcpm@ietf.org" , Helen Parsons , "iccrg@irtf.org" , "ext Smith, Kevin, \(R&D\) Vodafone Group" , Ankur Jain , "Cosimini, Peter, Vodafone Group" , "Flinck, Hannu \(NSN - FI/Espoo\)" , "Klas, Guenter, Vodafone Group" Subject: Re: [tcpm] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 04:47:13 -0000 --Apple-Mail=_6659FDC8-00EC-4963-AFF1-54529A957813 Content-Type: multipart/alternative; boundary="Apple-Mail=_56B581BA-8D86-475E-A32E-0D729E182D51" --Apple-Mail=_56B581BA-8D86-475E-A32E-0D729E182D51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also CC'ing TCPM and ICCRG. Is there any experimental evaluation and/or = simulation results for the proposed mechanism? Lars On 2015-2-20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) = wrote: >=20 > Dear all, > Please be aware of the new I-D we have submitted on =E2=80=9CRequirement= s and reference architecture for Mobile Throughput Guidance Exposure=E2=80= =9D. > The draft proposes principles for a mobile throughput guidance = exposure mechanism that can be used to assist TCP in cellular networks, = and help to ensure better network efficiency and enhanced service = delivery performance. > The draft presents the problems that the rapidly-varying conditions in = a cellular network can cause to the TCP behavior and to the application = performance. > The draft specifies the requirements and reference architecture for = the mechanism. > While the proposed mechanism can be used to optimize any content = delivery application, the draft describes its applicability to video = delivery optimization in mobile networks. > Your review and comments will be much appreciated. Comments can be = sent on the tsvwg list or directly to the authors. > Best regards, > Nurit >=20 >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org = ] On Behalf Of ext = internet-drafts@ietf.org > Sent: Friday, February 20, 2015 3:04 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Requirements and reference architecture for = Mobile Throughput Guidance Exposure > Authors : Ankur Jain > Andreas Terzis > Nurit Sprecher > Swaminathan Arunachalam > Kevin Smith > Guenter Klas > Filename : = draft-sprecher-mobile-tg-exposure-req-arch-01.txt > Pages : 12 > Date : 2015-02-20 >=20 > Abstract: > Rapidly-varying conditions in a cellular network can cause problems > for the Transmission Control Protocol (TCP), which in turn can > degrade application performance. >=20 > This document presents the problem statement and proposes solution > principles. It specifies the requirements and reference = architecture > for a mobile throughput guidance exposure mechanism that can be = used > to assist TCP in cellular networks, ensuring better network > efficiency and enhanced service delivery performance. >=20 > The proposed mechanism can be applied to any content or TCP/IP = based > application content delivery. This document describes the > applicability of the mechanism for Intelligent Video Acceleration > over cellular networks. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arc= h/ = >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-01 = = >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-sprecher-mobile-tg-exposure-req-a= rch-01 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > 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 = --Apple-Mail=_56B581BA-8D86-475E-A32E-0D729E182D51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Also CC'ing TCPM and ICCRG. Is there any = experimental evaluation and/or simulation results for the proposed = mechanism?

Lars

On 2015-2-20, = at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com> wrote:

Dear all,

Please be aware of the new = I-D we have submitted on =E2=80=9CRequirements and reference = architecture for Mobile Throughput Guidance Exposure=E2=80=9D.

The draft proposes principles for = a mobile throughput guidance exposure mechanism that can be = used  to assist TCP in cellular networks, and help to ensure better = network  efficiency and enhanced service delivery = performance.  

The = draft presents the problems that the rapidly-varying conditions in a = cellular network can cause to the TCP behavior and to the application = performance.

The draft specifies the = requirements and reference architecture for the mechanism. 

While the proposed = mechanism can be used to optimize any content delivery = application, the draft describes its = applicability to video delivery optimization in mobile = networks.

Your review and comments = will be much appreciated. Comments can be sent on the tsvwg list or = directly to the authors.

Best regards,

Nurit

 
 
-----Original = Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = ext internet-drafts@ietf.org
Sent: Friday, February 20, 2015 3:04 PM
To: i-d-announce@ietf.org
Subject: I-D Action: = draft-sprecher-mobile-tg-exposure-req-arch-01.txt
 
 
A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
 
 
        = Title           : = Requirements and reference architecture for Mobile Throughput Guidance = Exposure
        = Authors         : Ankur Jain
          &nb= sp;            = ;   Andreas Terzis
          &nb= sp;            = ;   Nurit Sprecher
          &nb= sp;            = ;   Swaminathan Arunachalam
          &nb= sp;            = ;   Kevin Smith
          &nb= sp;            = ;   Guenter Klas
      Filename =        : = draft-sprecher-mobile-tg-exposure-req-arch-01.txt
      = Pages           : = 12
      = Date            : = 2015-02-20
 
Abstract:
   = Rapidly-varying conditions in a cellular network can cause problems
   for = the Transmission Control Protocol (TCP), which in turn can
   = degrade application performance.
 
   This document presents the problem = statement and proposes solution
   principles.  It specifies the = requirements and reference architecture
   for a mobile throughput guidance = exposure mechanism that can be used
  to assist TCP in cellular networks, = ensuring better network
   efficiency and enhanced service delivery = performance.
 
   The = proposed mechanism can be applied to any content or TCP/IP based
   = application content delivery.  This document describes the
  =  applicability of the mechanism for Intelligent Video = Acceleration
   over cellular networks.
 
 
The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-expos= ure-req-arch/
 
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-re= q-arch-01
 
A = diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-sprecher-mobile-tg-exp= osure-req-arch-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/
 
_______________________________________________
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

= --Apple-Mail=_56B581BA-8D86-475E-A32E-0D729E182D51-- --Apple-Mail=_6659FDC8-00EC-4963-AFF1-54529A957813 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVOgMn9ZcnpRveo1xAQIU9gQAk0LEII1n56hjCQjj95H1D8hj6T2BfjGN Ls20oBRO69yfXTlNH73jR1ZcGLoHeEuQCm9PbGWPqwRPF/msGJFp2jzXQvK29Pxd i44+bl8mrLIIlNGBkVNdUCf+LyMq6NpMLJ3+jKR8b4TBW85uFHHQmctwxM2omeMp GNyqbX62wcQ= =ZZPn -----END PGP SIGNATURE----- --Apple-Mail=_6659FDC8-00EC-4963-AFF1-54529A957813-- From nobody Sat Feb 21 11:20:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8A91A1B66 for ; Fri, 20 Feb 2015 23:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 2PsfNd5Eg6lC for ; Fri, 20 Feb 2015 23:21:55 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E131A1B63 for ; Fri, 20 Feb 2015 23:21:55 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id b16so8260333igk.1 for ; Fri, 20 Feb 2015 23:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XKu7zjeYM34LOGV6JdhiMYWafyiIFnSZiP1E4iKu0so=; b=RBwNQ+2p5fmVlwVfnT2P8GCOMP74SusWX6YkXDN6gbPosGBdIHP+UcQdXWNgiZhJ4h +V+qZ9lLT73XKTih+pnUAhLujVUOi72LqqSsabq9TQzubt+gYeHe4dffsy1FCa8qjzc0 O26YI7ZsDtZU4w4PTH54bkxBW5df245gT3OmtivDK6FDfDZjuUUaY++/m0FjZlB2GBr0 OZPC2TWA79z7ZCZRR2V2X2T73ePiTtqSEyt27DX9KbbFztI8jF6de8fNupIFQ9cv32es IIX0jEudJIk8/IJFkX9YELMvqeEJ8GaKKpmIHi0BK2WP8CY/SVuFIe2NrIwqPJYAyfxb o6eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XKu7zjeYM34LOGV6JdhiMYWafyiIFnSZiP1E4iKu0so=; b=GFVIBZREm+Sk53oAFj72Iw+1wFiPE6QWgS459wH0NxigVQIb3r3qVbyKK4BGVmb9pf ez6stAyD1hga3JV9UBFSwIABnySlpOoMfiGRr3ObAvbO6lTtCJgy7zxrAbNn8PNy+eIJ 75ETHaA69puwehcdUYsk8peKuhOjpUvdnO5TFEqOT+fdq8MOBTWz5rs3tf60kvi+ZwGz G/7DL669FXvmNatcJcgWnpLFjmMPC5S48rOl8kp5b89fKExnV9t8A7han65wmfJHjqfu uN2ZG/YLokMRtKKWA9JAnDSd64lyCapvRhHcnraRvmN5QqEOi3u1stRz5jf/FIrM7if2 Tjww== X-Gm-Message-State: ALoCoQmW1k3d2rAOrlTJLgZhrp1KzoHvKP1EfMFpCDiqsV2pzmU943TQd/eLcdAIfjvAW7gJpEwf MIME-Version: 1.0 X-Received: by 10.43.131.5 with SMTP id ho5mr1744398icc.82.1424503314728; Fri, 20 Feb 2015 23:21:54 -0800 (PST) Received: by 10.64.34.228 with HTTP; Fri, 20 Feb 2015 23:21:54 -0800 (PST) In-Reply-To: <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> References: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> Date: Fri, 20 Feb 2015 23:21:54 -0800 Message-ID: From: Andreas Terzis To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=20cf307f30ba0ea393050f94064c Archived-At: X-Mailman-Approved-At: Sat, 21 Feb 2015 11:20:49 -0800 Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "tcpm@ietf.org" , "tsvwg@ietf.org" , Helen Parsons , "iccrg@irtf.org" , "Arunachalam, Swaminathan \(NSN - US/Irving\)" , Ankur Jain , "Klas, Guenter, Vodafone Group" , "Flinck, Hannu \(NSN - FI/Espoo\)" , "ext Smith, Kevin, \(R&D\) Vodafone Group" , "Cosimini, Peter, Vodafone Group" Subject: Re: [tcpm] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 07:21:58 -0000 --20cf307f30ba0ea393050f94064c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lars, To be clear, the document that Nurit submitted talks about requirements and doesn't propose any mechanism. We will soon submit another document that describe one possible mechanism for providing throughput guidance and a strawman for leveraging this information. That draft will include preliminary results from lab tests. Best regards, Andreas On Fri, Feb 20, 2015 at 8:42 PM, Eggert, Lars wrote: > Also CC'ing TCPM and ICCRG. Is there any experimental evaluation and/or > simulation results for the proposed mechanism? > > Lars > > On 2015-2-20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) < > nurit.sprecher@nsn.com> wrote: > > > Dear all, > > Please be aware of the new I-D we have submitted on =E2=80=9CRequirements= and > reference architecture for Mobile Throughput Guidance Exposure=E2=80=9D. > > The draft proposes principles for a mobile throughput guidance exposure > mechanism that can be used to assist TCP in cellular networks, and help = to > ensure better network efficiency and enhanced service delivery performan= ce. > > > The draft presents the problems that the rapidly-varying conditions in a > cellular network can cause to the TCP behavior and to the application > performance. > > The draft specifies the requirements and reference architecture for the > mechanism. > > While the proposed mechanism can be used to optimize any content delivery > application, the draft describes its applicability to video delivery opti= mization > in mobile networks. > > Your review and comments will be much appreciated. Comments can be sent o= n > the tsvwg list or directly to the authors. > > Best regards, > > Nurit > > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org > ] On Behalf Of ext internet-drafts@ietf.or= g > Sent: Friday, February 20, 2015 3:04 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Requirements and reference architecture for > Mobile Throughput Guidance Exposure > Authors : Ankur Jain > Andreas Terzis > Nurit Sprecher > Swaminathan Arunachalam > Kevin Smith > Guenter Klas > Filename : draft-sprecher-mobile-tg-exposure-req-arch-01.txt > Pages : 12 > Date : 2015-02-20 > > Abstract: > Rapidly-varying conditions in a cellular network can cause problems > for the Transmission Control Protocol (TCP), which in turn can > degrade application performance. > > This document presents the problem statement and proposes solution > principles. It specifies the requirements and reference architecture > for a mobile throughput guidance exposure mechanism that can be used > to assist TCP in cellular networks, ensuring better network > efficiency and enhanced service delivery performance. > > The proposed mechanism can be applied to any content or TCP/IP based > application content delivery. This document describes the > applicability of the mechanism for Intelligent Video Acceleration > over cellular networks. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-ar= ch/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-01 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-sprecher-mobile-tg-exposure-req-= arch-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/ > > _______________________________________________ > 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 > > > --20cf307f30ba0ea393050f94064c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lars,

To be clear, the document that Nu= rit submitted talks about requirements and doesn't propose any mechanis= m.

We will soon submit another document that descr= ibe one possible mechanism for providing throughput guidance
and = a strawman for leveraging this information. That draft will include prelimi= nary results from lab tests.=C2=A0

Best regards,

Andreas=C2=A0



On Fri, Feb 20= , 2015 at 8:42 PM, Eggert, Lars <lars@netapp.com> wrote:
Also = CC'ing TCPM and ICCRG. Is there any experimental evaluation and/or simu= lation results for the proposed mechanism?

Lars

On 2015-2-20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaS= haron) <nuri= t.sprecher@nsn.com> wrote:

De= ar all,

Please be aware of the new I-D we have submitted on =E2=80=9CRequ= irements and reference architecture for Mobile Throughput Guidance Exposure= =E2=80=9D.

The draft proposes principles for a=C2=A0= mobile throughput guidance exposure mechanism that can be= used=C2=A0 to assist TCP in cellular networks, and help to ensure better n= etwork =C2=A0efficiency and enhanced service delivery performance.=C2=A0=C2=A0

The = draft presents the problems that the rapidly-varying conditions in a cellul= ar network can cause to the TCP behavior and to the application performance= .

The draft=C2=A0specifies = the requirements and reference architecture for the mechanism.=C2=A0<= /span>

While the proposed mechanism can be used to optimize any content= delivery application, the draft=C2=A0describes its applicability to= =C2=A0video delivery=C2=A0optimization in mobile= networks.=

= Your review and comments will be much appreciated. Comments can be sent on = the tsvwg list or directly to the authors.

Best regards,

Nurit

=C2=A0
=C2=A0
-= ----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=C2=A0internet-drafts@ietf.o= rg
Sent: Friday, February 20, 2015 3:04 PM
To:=C2=A0= i-d-announce@ietf.org
Subject: I-D = Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt
=C2=A0
=C2=A0
A New Internet-= Draft is available from the on-line Internet-Drafts directories.<= /u>
=C2=A0
=C2=A0
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 : Requirements and reference architecture for M= obile Throughput Guidance Exposure
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : Ankur Jain
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Andreas Terzis
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Nurit Sprecher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Swaminathan Arunachalam
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Kevin Smith
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Guenter Klas<= u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Filename =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0: draft-sprecher-mobile-tg-exposure-req-arch-01.txt=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 12
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : 2015-02-20
=C2=A0
Abstract:
=C2=A0=C2=A0 Rapidly-varying condit= ions in a cellular network can cause problems
=C2=A0= =C2=A0 for the Transmission Control Protocol (TCP), which in turn can
=C2=A0=C2=A0 degrade application performance.=
=C2=A0
=C2=A0=C2=A0 This document presents the= problem statement and proposes solution
=C2=A0=C2=A0 = principles.=C2=A0 It specifies the requirements and reference architecture<= u>
=C2=A0=C2=A0 for a mobile throughput guidance exposure= mechanism that can be used
=C2=A0=C2=A0to assist TCP = in cellular networks, ensuring better network
=C2=A0= =C2=A0 efficiency and enhanced service delivery performance.<= /div>
=C2=A0
=C2=A0=C2=A0 The proposed mechanism can = be applied to any content or TCP/IP based
=C2=A0=C2=A0= application content delivery.=C2=A0 This document describes the<= /u>
=C2=A0 =C2=A0applicability of the mechanism for Intelligent Vide= o Acceleration
=C2=A0=C2=A0 over cellular networks.=
=C2=A0
=C2=A0
= The IETF datatracker status page for this draft is:
https://datatrack= er.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arch/
=C2=A0
There's also a htmlized ve= rsion available at:
=C2=A0
A diff from the previous version is available at:
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:10.5pt;font-family:Consolas"= >http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-sprecher-mobile-tg-exposure-req-arch-01
=C2=A0
=C2=A0
Please note that it may take a couple of minutes from the time of= submission
until the htmlized version and diff are av= ailable at=C2=A0tools.ietf.org.=
=C2=A0
Internet-Drafts are also = available by anonymous FTP at:
=C2= =A0
_______________________________________________=
I-D-Announce mailing list
Internet-Draft directories:=C2=A0http://www.ietf.org/shadow.html

=

--20cf307f30ba0ea393050f94064c-- From nobody Sun Feb 22 09:33:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDEA1A0010; Sat, 21 Feb 2015 13:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham 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 YJ2O_NLdoKBD; Sat, 21 Feb 2015 13:39:55 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B91A005A; Sat, 21 Feb 2015 13:39:54 -0800 (PST) Received: from aputeaux-554-1-42-21.w90-35.abo.wanadoo.fr ([90.35.121.21] helo=[192.168.1.129]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1YPHmD-0006zk-8o; Sat, 21 Feb 2015 21:39:54 +0000 References: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-AC395CAD-0311-4827-85D7-9982DC3F2400 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12B466) From: Ben Niven-Jenkins Date: Sat, 21 Feb 2015 22:39:48 +0100 To: Andreas Terzis X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:33:53 -0800 Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , Helen Parsons , "Arunachalam, Swaminathan \(NSN - US/Irving\)" , Ankur Jain , "Cosimini, Peter, Vodafone Group" , "Flinck, Hannu \(NSN - FI/Espoo\)" , "ext Smith, Kevin, \(R&D\) Vodafone Group" , "Klas, Guenter, Vodafone Group" Subject: Re: [tcpm] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 21:40:03 -0000 --Apple-Mail-AC395CAD-0311-4827-85D7-9982DC3F2400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andreas, =46rom a quick read of the draft it seems to me that the functional architec= ture is only partially described as it is not clear to me how the Throughput= Guidance Provider discovers which TCP server(s) it should be providing thro= ughput guidance to or how a TCP server might discover & register with a Thro= ughput Guidance Provider.=20 Will the other document you mention also cover discovery? Also, where is this document primarily being discussed (TSVWG?) as I am inte= rested in the work but not sure which WG to subscribe to in order to follow/= contribute towards it? Thanks Ben > On 21 Feb 2015, at 08:21, Andreas Terzis wrote: >=20 > Lars, >=20 > To be clear, the document that Nurit submitted talks about requirements an= d doesn't propose any mechanism. >=20 > We will soon submit another document that describe one possible mechanism f= or providing throughput guidance > and a strawman for leveraging this information. That draft will include pr= eliminary results from lab tests.=20 >=20 > Best regards, >=20 > Andreas=20 >=20 >=20 >=20 >> On Fri, Feb 20, 2015 at 8:42 PM, Eggert, Lars wrote: >> Also CC'ing TCPM and ICCRG. Is there any experimental evaluation and/or s= imulation results for the proposed mechanism? >>=20 >> Lars >>=20 >>> On 2015-2-20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: >>>=20 >>> Dear all, >>> Please be aware of the new I-D we have submitted on =E2=80=9CRequirement= s and reference architecture for Mobile Throughput Guidance Exposure=E2=80=9D= . >>> The draft proposes principles for a mobile throughput guidance exposure m= echanism that can be used to assist TCP in cellular networks, and help to e= nsure better network efficiency and enhanced service delivery performance. = =20 >>> The draft presents the problems that the rapidly-varying conditions in a= cellular network can cause to the TCP behavior and to the application perfo= rmance. >>> The draft specifies the requirements and reference architecture for the m= echanism.=20 >>> While the proposed mechanism can be used to optimize any content deliver= y application, the draft describes its applicability to video delivery optim= ization in mobile networks. >>> Your review and comments will be much appreciated. Comments can be sent o= n the tsvwg list or directly to the authors. >>> Best regards, >>> Nurit >>> =20 >>> =20 >>> -----Original Message----- >>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of e= xt internet-drafts@ietf.org >>> Sent: Friday, February 20, 2015 3:04 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt >>> =20 >>> =20 >>> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>> =20 >>> =20 >>> Title : Requirements and reference architecture for Mo= bile Throughput Guidance Exposure >>> Authors : Ankur Jain >>> Andreas Terzis >>> Nurit Sprecher >>> Swaminathan Arunachalam >>> Kevin Smith >>> Guenter Klas >>> Filename : draft-sprecher-mobile-tg-exposure-req-arch-01.tx= t >>> Pages : 12 >>> Date : 2015-02-20 >>> =20 >>> Abstract: >>> Rapidly-varying conditions in a cellular network can cause problems >>> for the Transmission Control Protocol (TCP), which in turn can >>> degrade application performance. >>> =20 >>> This document presents the problem statement and proposes solution >>> principles. It specifies the requirements and reference architecture= >>> for a mobile throughput guidance exposure mechanism that can be used >>> to assist TCP in cellular networks, ensuring better network >>> efficiency and enhanced service delivery performance. >>> =20 >>> The proposed mechanism can be applied to any content or TCP/IP based >>> application content delivery. This document describes the >>> applicability of the mechanism for Intelligent Video Acceleration >>> over cellular networks. >>> =20 >>> =20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-a= rch/ >>> =20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-01= >>> =20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-sprecher-mobile-tg-exposure-req= -arch-01 >>> =20 >>> =20 >>> Please note that it may take a couple of minutes from the time of submis= sion >>> 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 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-AC395CAD-0311-4827-85D7-9982DC3F2400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Andreas,

=46rom= a quick read of the draft it seems to me that the functional architecture i= s only partially described as it is not clear to me how the Throughput Guida= nce Provider discovers which TCP server(s) it should be providing throughput= guidance to or how a TCP server might discover & register with a Throug= hput Guidance Provider. 

Will the other docume= nt you mention also cover discovery?

Also, where is this d= ocument primarily being discussed (TSVWG?) as I am interested in the work bu= t not sure which WG to subscribe to in order to follow/contribute towards it= ?

Thanks
Ben

On 21 Feb 2015= , at 08:21, Andreas Terzis <aterzis= @google.com> wrote:

Lars,

To be clear, the document that Nurit sub= mitted talks about requirements and doesn't propose any mechanism.

We will soon submit another document that describe one possi= ble mechanism for providing throughput guidance
and a strawman for= leveraging this information. That draft will include preliminary results fr= om lab tests. 

Best regards,

Andreas 



On Fri, Feb 20, 2015 at 8:42 PM,= Eggert, Lars <lars@netapp.com> wrote:
Also CC'ing TCPM and ICCRG.= Is there any experimental evaluation and/or simulation results for the prop= osed mechanism?

Lars

On 2015-2-= 20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@nsn.com> wro= te:

Dear all,

Please be aware of the new I-D= we have submitted on =E2=80=9CRequirements and reference architecture for M= obile Throughput Guidance Exposure=E2=80=9D.

The draft proposes prin= ciples for a mobile throughput guidance e= xposure mechanism that can be used  to assist TCP in cellular networks,= and help to ensure better network  efficiency and enhanced service del= ivery performance.  <= u>

The draft presents the problems that the rapidly-varying c= onditions in a cellular network can cause to the TCP behavior and to the app= lication performance.

The draft <= /span>specifies the requirements and reference architecture for the mechanis= m. 

While the proposed mechanism can be used to optimize= any content delivery application, the draft describes its applica= bility to video delivery optimization in= mobile networks.

Your review and comments will be much appreciated. Comments can be sent o= n the tsvwg list or directly to the authors.

Best regards,

Nurit=

 
 
-----Origina= l Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org
Sent: = Friday, February 20, 2015 3:04 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-sprec= her-mobile-tg-exposure-req-arch-01.txt
 <= /u>
 
A New Internet-Draft is available from t= he on-line Internet-Drafts directories.
 =
 
      &n= bsp; Title           : Req= uirements and reference architecture for Mobile Throughput Guidance Exposure=
        Authors = ;        : Ankur Jain
=
            &nb= sp;             A= ndreas Terzis
       =             &nbs= p;      Nurit Sprecher
 &n= bsp;            =             Swaminath= an Arunachalam
       = ;            &nb= sp;      Kevin Smith
  =             &nbs= p;           Guenter Klas<= u>
      Filename   &nbs= p;    : draft-sprecher-mobile-tg-exposure-req-arch-01.tx= t
      Pages   =         : 12
 &n= bsp;    Date        &= nbsp;   : 2015-02-20
 
   Rapidly-varying conditions in a= cellular network can cause problems
   for th= e Transmission Control Protocol (TCP), which in turn can
=
   degrade application performance.
&n= bsp;
   This document presents the problem statement a= nd proposes solution
   principles.  It s= pecifies the requirements and reference architecture
&nb= sp;  for a mobile throughput guidance exposure mechanism that can be us= ed
  to assist TCP in cellular networks, ensur= ing better network
   efficiency and enhanced s= ervice delivery performance.
 
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:10.5pt;font-family:Consolas">=    The proposed mechanism can be applied to any content or TCP/IP b= ased
   application content delivery.  Th= is document describes the
   applicability of t= he mechanism for Intelligent Video Acceleration
 &n= bsp; over cellular networks.
 
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:10.5pt;font-family:Consolas">=  
The IETF datatracker status page for this draft i= s:
 
There's also= a htmlized version available at:
 =
A diff from the previous version is available at:
 
 
Please note that it may take a couple of minutes from the time of submi= ssion
until the htmlized version and diff are available a= t tools.ietf.org.<= /u>
 
Internet-Drafts are also available by a= nonymous FTP at:
 
_____= __________________________________________
I-D-Announce m= ailing list
Internet-Draft direct= ories: http://www.ietf.org/shadow.html<= /a>
<= /div>

____________________= ___________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman= /listinfo/tcpm
= --Apple-Mail-AC395CAD-0311-4827-85D7-9982DC3F2400-- From nobody Sun Feb 22 09:33:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB711A0181; Sat, 21 Feb 2015 17:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xcvyVV9Tx1a7; Sat, 21 Feb 2015 17:34:26 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63591A017A; Sat, 21 Feb 2015 17:34:25 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1M1YMs6030056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2015 20:34:22 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1M1YMs6030056 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1424568863; bh=y7yDEqK674QjdxKPmV3G6gWns/4=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Sb08OyLveXgt95l6AnDGzZFaG0nhRe8lXciwyXUDpRdXl1D5HH7naIdypuL8amZ2J yLVL1e0Z6NqaEhBudPtNVuSIU8dKhR8adbMauPGFuhTNkNfT2glhdIIpWatETrFHdo hv53z5/Vvybclp1BDmW8yvpBY0qk9Ceo739yUCb8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t1M1YMs6030056 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd53.lss.emc.com (RSA Interceptor); Sat, 21 Feb 2015 20:33:32 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1M1Y1eM031242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 Feb 2015 20:34:02 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 21 Feb 2015 20:34:01 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.172]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Sat, 21 Feb 2015 20:34:01 -0500 From: "Black, David" To: Ben Niven-Jenkins Thread-Topic: draft-sprecher-mobile-tg-exposure-req-arch-01.txt - discussion forum Thread-Index: AdBOP5+K7z+QYO+WS8G+8rT8AaZDAw== Date: Sun, 22 Feb 2015 01:34:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.46.128] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936399249MX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:33:53 -0800 Cc: "Arunachalam, Swaminathan \(NSN - US/Irving\)" , "tsvwg@ietf.org" , "Black, David" , Helen Parsons , "iccrg@irtf.org" , "tcpm@ietf.org" , Ankur Jain , "Klas, Guenter, Vodafone Group" , "Flinck, Hannu \(NSN - FI/Espoo\)" , "ext Smith, Kevin, \(R&D\) Vodafone Group" , "Cosimini, Peter, Vodafone Group" Subject: [tcpm] draft-sprecher-mobile-tg-exposure-req-arch-01.txt - discussion forum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 01:34:32 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936399249MX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBBbHNvLCB3aGVyZSBpcyB0aGlzIGRvY3VtZW50IHByaW1hcmlseSBiZWluZyBkaXNjdXNzZWQg KFRTVldHPykgYXMgSSBhbSBpbnRlcmVzdGVkIGluIHRoZSB3b3JrIGJ1dCBub3Qgc3VyZQ0KPiB3 aGljaCBXRyB0byBzdWJzY3JpYmUgdG8gaW4gb3JkZXIgdG8gZm9sbG93L2NvbnRyaWJ1dGUgdG93 YXJkcyBpdD8NCg0KVGhlIG9yaWdpbmFsIGFubm91bmNlbWVudCB3YXMgc2VudCB0byB0c3Z3Zywg YW5kIGl0IGxvb2tzIGxpa2UgTGFycyBhZGRlZCB0Y3BtIGFuZCBpY2NyZyBpbiBoaXMgcmVwbHku DQpMZXTigJlzIHVzZSB0c3Z3ZyBhcyB0aGUgcHJpbWFyeSBkaXNjdXNzaW9uIGZvcnVtIGZvciBu b3cuDQoNClRoYW5rcywNCi0tRGF2aWQgKHRzdndnIFdHIGNvLWNoYWlyKQ0KDQpGcm9tOiB0c3Z3 ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4gTml2ZW4t SmVua2lucw0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDIxLCAyMDE1IDQ6NDAgUE0NClRvOiBB bmRyZWFzIFRlcnppcw0KQ2M6IHRjcG1AaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnOyBpY2NyZ0Bp cnRmLm9yZzsgSGVsZW4gUGFyc29uczsgQXJ1bmFjaGFsYW0sIFN3YW1pbmF0aGFuIChOU04gLSBV Uy9JcnZpbmcpOyBBbmt1ciBKYWluOyBDb3NpbWluaSwgUGV0ZXIsIFZvZGFmb25lIEdyb3VwOyBG bGluY2ssIEhhbm51IChOU04gLSBGSS9Fc3Bvbyk7IGV4dCBTbWl0aCwgS2V2aW4sIChSJkQpIFZv ZGFmb25lIEdyb3VwOyBLbGFzLCBHdWVudGVyLCBWb2RhZm9uZSBHcm91cA0KU3ViamVjdDogUmU6 IFt0c3Z3Z10gW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBv c3VyZS1yZXEtYXJjaC0wMS50eHQNCg0KQW5kcmVhcywNCg0KRnJvbSBhIHF1aWNrIHJlYWQgb2Yg dGhlIGRyYWZ0IGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJl IGlzIG9ubHkgcGFydGlhbGx5IGRlc2NyaWJlZCBhcyBpdCBpcyBub3QgY2xlYXIgdG8gbWUgaG93 IHRoZSBUaHJvdWdocHV0IEd1aWRhbmNlIFByb3ZpZGVyIGRpc2NvdmVycyB3aGljaCBUQ1Agc2Vy dmVyKHMpIGl0IHNob3VsZCBiZSBwcm92aWRpbmcgdGhyb3VnaHB1dCBndWlkYW5jZSB0byBvciBo b3cgYSBUQ1Agc2VydmVyIG1pZ2h0IGRpc2NvdmVyICYgcmVnaXN0ZXIgd2l0aCBhIFRocm91Z2hw dXQgR3VpZGFuY2UgUHJvdmlkZXIuDQoNCldpbGwgdGhlIG90aGVyIGRvY3VtZW50IHlvdSBtZW50 aW9uIGFsc28gY292ZXIgZGlzY292ZXJ5Pw0KQWxzbywgd2hlcmUgaXMgdGhpcyBkb2N1bWVudCBw cmltYXJpbHkgYmVpbmcgZGlzY3Vzc2VkIChUU1ZXRz8pIGFzIEkgYW0gaW50ZXJlc3RlZCBpbiB0 aGUgd29yayBidXQgbm90IHN1cmUgd2hpY2ggV0cgdG8gc3Vic2NyaWJlIHRvIGluIG9yZGVyIHRv IGZvbGxvdy9jb250cmlidXRlIHRvd2FyZHMgaXQ/DQoNClRoYW5rcw0KQmVuDQoNCk9uIDIxIEZl YiAyMDE1LCBhdCAwODoyMSwgQW5kcmVhcyBUZXJ6aXMgPGF0ZXJ6aXNAZ29vZ2xlLmNvbTxtYWls dG86YXRlcnppc0Bnb29nbGUuY29tPj4gd3JvdGU6DQpMYXJzLA0KDQpUbyBiZSBjbGVhciwgdGhl IGRvY3VtZW50IHRoYXQgTnVyaXQgc3VibWl0dGVkIHRhbGtzIGFib3V0IHJlcXVpcmVtZW50cyBh bmQgZG9lc24ndCBwcm9wb3NlIGFueSBtZWNoYW5pc20uDQoNCldlIHdpbGwgc29vbiBzdWJtaXQg YW5vdGhlciBkb2N1bWVudCB0aGF0IGRlc2NyaWJlIG9uZSBwb3NzaWJsZSBtZWNoYW5pc20gZm9y IHByb3ZpZGluZyB0aHJvdWdocHV0IGd1aWRhbmNlDQphbmQgYSBzdHJhd21hbiBmb3IgbGV2ZXJh Z2luZyB0aGlzIGluZm9ybWF0aW9uLiBUaGF0IGRyYWZ0IHdpbGwgaW5jbHVkZSBwcmVsaW1pbmFy eSByZXN1bHRzIGZyb20gbGFiIHRlc3RzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkFuZHJlYXMNCg0K DQoNCk9uIEZyaSwgRmViIDIwLCAyMDE1IGF0IDg6NDIgUE0sIEVnZ2VydCwgTGFycyA8bGFyc0Bu ZXRhcHAuY29tPG1haWx0bzpsYXJzQG5ldGFwcC5jb20+PiB3cm90ZToNCkFsc28gQ0MnaW5nIFRD UE0gYW5kIElDQ1JHLiBJcyB0aGVyZSBhbnkgZXhwZXJpbWVudGFsIGV2YWx1YXRpb24gYW5kL29y IHNpbXVsYXRpb24gcmVzdWx0cyBmb3IgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbT8NCg0KTGFycw0K DQpPbiAyMDE1LTItMjAsIGF0IDE0OjQ2LCBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBI YVNoYXJvbikgPG51cml0LnNwcmVjaGVyQG5zbi5jb208bWFpbHRvOm51cml0LnNwcmVjaGVyQG5z bi5jb20+PiB3cm90ZToNCg0KDQpEZWFyIGFsbCwNCg0KUGxlYXNlIGJlIGF3YXJlIG9mIHRoZSBu ZXcgSS1EIHdlIGhhdmUgc3VibWl0dGVkIG9uIOKAnFJlcXVpcmVtZW50cyBhbmQgcmVmZXJlbmNl IGFyY2hpdGVjdHVyZSBmb3IgTW9iaWxlIFRocm91Z2hwdXQgR3VpZGFuY2UgRXhwb3N1cmXigJ0u DQpUaGUgZHJhZnQgcHJvcG9zZXMgcHJpbmNpcGxlcyBmb3IgYSBtb2JpbGUgdGhyb3VnaHB1dCBn dWlkYW5jZSBleHBvc3VyZSBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZCAgdG8gYXNzaXN0IFRD UCBpbiBjZWxsdWxhciBuZXR3b3JrcywgYW5kIGhlbHAgdG8gZW5zdXJlIGJldHRlciBuZXR3b3Jr ICBlZmZpY2llbmN5IGFuZCBlbmhhbmNlZCBzZXJ2aWNlIGRlbGl2ZXJ5IHBlcmZvcm1hbmNlLg0K VGhlIGRyYWZ0IHByZXNlbnRzIHRoZSBwcm9ibGVtcyB0aGF0IHRoZSByYXBpZGx5LXZhcnlpbmcg Y29uZGl0aW9ucyBpbiBhIGNlbGx1bGFyIG5ldHdvcmsgY2FuIGNhdXNlIHRvIHRoZSBUQ1AgYmVo YXZpb3IgYW5kIHRvIHRoZSBhcHBsaWNhdGlvbiBwZXJmb3JtYW5jZS4NClRoZSBkcmFmdCBzcGVj aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBhbmQgcmVmZXJlbmNlIGFyY2hpdGVjdHVyZSBmb3IgdGhl IG1lY2hhbmlzbS4NCg0KV2hpbGUgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBjYW4gYmUgdXNlZCB0 byBvcHRpbWl6ZSBhbnkgY29udGVudCBkZWxpdmVyeSBhcHBsaWNhdGlvbiwgdGhlIGRyYWZ0IGRl c2NyaWJlcyBpdHMgYXBwbGljYWJpbGl0eSB0byB2aWRlbyBkZWxpdmVyeSBvcHRpbWl6YXRpb24g aW4gbW9iaWxlIG5ldHdvcmtzLg0KDQpZb3VyIHJldmlldyBhbmQgY29tbWVudHMgd2lsbCBiZSBt dWNoIGFwcHJlY2lhdGVkLiBDb21tZW50cyBjYW4gYmUgc2VudCBvbiB0aGUgdHN2d2cgbGlzdCBv ciBkaXJlY3RseSB0byB0aGUgYXV0aG9ycy4NCg0KQmVzdCByZWdhcmRzLA0KDQpOdXJpdA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJLUQtQW5ub3VuY2UgW21haWx0bzpp LWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMjAsIDIwMTUgMzowNCBQTQ0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y ZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJh ZnQtc3ByZWNoZXItbW9iaWxlLXRnLWV4cG9zdXJlLXJlcS1hcmNoLTAxLnR4dA0KDQoNCkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFJlcXVpcmVt ZW50cyBhbmQgcmVmZXJlbmNlIGFyY2hpdGVjdHVyZSBmb3IgTW9iaWxlIFRocm91Z2hwdXQgR3Vp ZGFuY2UgRXhwb3N1cmUNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQW5rdXIgSmFpbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBBbmRyZWFzIFRlcnppcw0KICAgICAgICAgICAgICAgICAg ICAgICAgICBOdXJpdCBTcHJlY2hlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBTd2FtaW5h dGhhbiBBcnVuYWNoYWxhbQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBLZXZpbiBTbWl0aA0K ICAgICAgICAgICAgICAgICAgICAgICAgICBHdWVudGVyIEtsYXMNCiAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJjaC0wMS50eHQN CiAgICAgIFBhZ2VzICAgICAgICAgICA6IDEyDQogICAgICBEYXRlICAgICAgICAgICAgOiAyMDE1 LTAyLTIwDQoNCkFic3RyYWN0Og0KICAgUmFwaWRseS12YXJ5aW5nIGNvbmRpdGlvbnMgaW4gYSBj ZWxsdWxhciBuZXR3b3JrIGNhbiBjYXVzZSBwcm9ibGVtcw0KICAgZm9yIHRoZSBUcmFuc21pc3Np b24gQ29udHJvbCBQcm90b2NvbCAoVENQKSwgd2hpY2ggaW4gdHVybiBjYW4NCiAgIGRlZ3JhZGUg YXBwbGljYXRpb24gcGVyZm9ybWFuY2UuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgdGhl IHByb2JsZW0gc3RhdGVtZW50IGFuZCBwcm9wb3NlcyBzb2x1dGlvbg0KICAgcHJpbmNpcGxlcy4g IEl0IHNwZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGFuZCByZWZlcmVuY2UgYXJjaGl0ZWN0dXJl DQogICBmb3IgYSBtb2JpbGUgdGhyb3VnaHB1dCBndWlkYW5jZSBleHBvc3VyZSBtZWNoYW5pc20g dGhhdCBjYW4gYmUgdXNlZA0KICB0byBhc3Npc3QgVENQIGluIGNlbGx1bGFyIG5ldHdvcmtzLCBl bnN1cmluZyBiZXR0ZXIgbmV0d29yaw0KICAgZWZmaWNpZW5jeSBhbmQgZW5oYW5jZWQgc2Vydmlj ZSBkZWxpdmVyeSBwZXJmb3JtYW5jZS4NCg0KICAgVGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBjYW4g YmUgYXBwbGllZCB0byBhbnkgY29udGVudCBvciBUQ1AvSVAgYmFzZWQNCiAgIGFwcGxpY2F0aW9u IGNvbnRlbnQgZGVsaXZlcnkuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUNCiAgIGFwcGxp Y2FiaWxpdHkgb2YgdGhlIG1lY2hhbmlzbSBmb3IgSW50ZWxsaWdlbnQgVmlkZW8gQWNjZWxlcmF0 aW9uDQogICBvdmVyIGNlbGx1bGFyIG5ldHdvcmtzLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtc3ByZWNoZXItbW9iaWxlLXRnLWV4cG9zdXJlLXJlcS1hcmNoLw0KDQpU aGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJj aC0wMQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zcHJlY2hlci1tb2JpbGUt dGctZXhwb3N1cmUtcmVxLWFyY2gtMDENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZy8+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnPG1h aWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz aGFkb3ctc2l0ZXMudHh0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3Bt QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo= --_000_CE03DB3D7B45C245BCA0D24327794936399249MX104CL02corpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jmd0Ow0KPC9zcGFuPkFsc28sIHdoZXJlIGlzIHRoaXMgZG9jdW1lbnQgcHJpbWFyaWx5IGJlaW5n IGRpc2N1c3NlZCAoVFNWV0c/KSBhcyBJIGFtIGludGVyZXN0ZWQgaW4gdGhlIHdvcmsgYnV0IG5v dCBzdXJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHdoaWNoIFdH IHRvIHN1YnNjcmliZSB0byBpbiBvcmRlciB0byBmb2xsb3cvY29udHJpYnV0ZSB0b3dhcmRzIGl0 PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgb3JpZ2luYWwgYW5ub3VuY2VtZW50IHdhcyBzZW50IHRv IHRzdndnLCBhbmQgaXQgbG9va3MgbGlrZSBMYXJzIGFkZGVkIHRjcG0gYW5kIGljY3JnIGluIGhp cyByZXBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+TGV04oCZcyB1c2UgdHN2d2cgYXMgdGhlIHByaW1hcnkgZGlzY3Vz c2lvbiBmb3J1bSBmb3Igbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGFua3MsPGJyPg0KLS1EYXZpZCAodHN2d2cgV0cgY28tY2hhaXIpPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRz dndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QmVuIE5pdmVuLUplbmtpbnM8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEZlYnJ1YXJ5IDIx LCAyMDE1IDQ6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlYXMgVGVyemlzPGJyPg0KPGI+Q2M6 PC9iPiB0Y3BtQGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZzsgaWNjcmdAaXJ0Zi5vcmc7IEhlbGVu IFBhcnNvbnM7IEFydW5hY2hhbGFtLCBTd2FtaW5hdGhhbiAoTlNOIC0gVVMvSXJ2aW5nKTsgQW5r dXIgSmFpbjsgQ29zaW1pbmksIFBldGVyLCBWb2RhZm9uZSBHcm91cDsgRmxpbmNrLCBIYW5udSAo TlNOIC0gRkkvRXNwb28pOyBleHQgU21pdGgsIEtldmluLCAoUiZhbXA7RCkgVm9kYWZvbmUgR3Jv dXA7IEtsYXMsIEd1ZW50ZXIsIFZvZGFmb25lDQogR3JvdXA8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt0c3Z3Z10gW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1l eHBvc3VyZS1yZXEtYXJjaC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVhcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBhIHF1aWNrIHJlYWQgb2YgdGhlIGRyYWZ0 IGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIGlzIG9ubHkg cGFydGlhbGx5IGRlc2NyaWJlZCBhcyBpdCBpcyBub3QgY2xlYXIgdG8gbWUgaG93IHRoZSBUaHJv dWdocHV0IEd1aWRhbmNlIFByb3ZpZGVyIGRpc2NvdmVycyB3aGljaCBUQ1Agc2VydmVyKHMpIGl0 IHNob3VsZCBiZSBwcm92aWRpbmcgdGhyb3VnaHB1dCBndWlkYW5jZQ0KIHRvIG9yIGhvdyBhIFRD UCBzZXJ2ZXIgbWlnaHQgZGlzY292ZXIgJmFtcDsgcmVnaXN0ZXIgd2l0aCBhIFRocm91Z2hwdXQg R3VpZGFuY2UgUHJvdmlkZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2lsbCB0 aGUgb3RoZXIgZG9jdW1lbnQgeW91IG1lbnRpb24gYWxzbyBjb3ZlciBkaXNjb3Zlcnk/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB3aGVy ZSBpcyB0aGlzIGRvY3VtZW50IHByaW1hcmlseSBiZWluZyBkaXNjdXNzZWQgKFRTVldHPykgYXMg SSBhbSBpbnRlcmVzdGVkIGluIHRoZSB3b3JrIGJ1dCBub3Qgc3VyZSB3aGljaCBXRyB0byBzdWJz Y3JpYmUgdG8gaW4gb3JkZXIgdG8gZm9sbG93L2NvbnRyaWJ1dGUgdG93YXJkcyBpdD88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjEgRmViIDIwMTUsIGF0IDA4OjIxLCBBbmRy ZWFzIFRlcnppcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmF0ZXJ6aXNAZ29vZ2xlLmNvbSI+YXRlcnpp c0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXJzLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gYmUgY2xlYXIsIHRoZSBkb2N1bWVudCB0aGF0 IE51cml0IHN1Ym1pdHRlZCB0YWxrcyBhYm91dCByZXF1aXJlbWVudHMgYW5kIGRvZXNuJ3QgcHJv cG9zZSBhbnkgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZSB3aWxsIHNvb24gc3VibWl0IGFub3RoZXIgZG9jdW1lbnQgdGhh dCBkZXNjcmliZSBvbmUgcG9zc2libGUgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgdGhyb3VnaHB1 dCBndWlkYW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YW5kIGEgc3RyYXdtYW4gZm9yIGxldmVyYWdpbmcgdGhpcyBpbmZvcm1hdGlvbi4gVGhh dCBkcmFmdCB3aWxsIGluY2x1ZGUgcHJlbGltaW5hcnkgcmVzdWx0cyBmcm9tIGxhYiB0ZXN0cy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmRyZWFzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRmViIDIwLCAyMDE1IGF0IDg6NDIg UE0sIEVnZ2VydCwgTGFycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIENDJ2luZyBUQ1BNIGFu ZCBJQ0NSRy4gSXMgdGhlcmUgYW55IGV4cGVyaW1lbnRhbCBldmFsdWF0aW9uIGFuZC9vciBzaW11 bGF0aW9uIHJlc3VsdHMgZm9yIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhcnM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMDE1LTItMjAsIGF0IDE0OjQ2 LCBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikgJmx0OzxhIGhyZWY9Im1h aWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tIiB0YXJnZXQ9Il9ibGFuayI+bnVyaXQuc3ByZWNo ZXJAbnNuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tbGVmdDowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0 OjEyLjFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlYXIgYWxsLDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo2LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6MTIuMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UGxlYXNlIGJlIGF3YXJlIG9mIHRoZSBuZXcgSS1EIHdlIGhhdmUgc3VibWl0dGVkIG9u IOKAnFJlcXVpcmVtZW50cyBhbmQgcmVmZXJlbmNlIGFyY2hpdGVjdHVyZSBmb3IgTW9iaWxlIFRo cm91Z2hwdXQgR3VpZGFuY2UgRXhwb3N1cmXigJ0uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDtsaW5lLWhlaWdodDox Mi42NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBkcmFmdCBwcm9wb3NlcyBw cmluY2lwbGVzIGZvciBhJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPm1vYmlsZQ0KIHRocm91Z2hwdXQgZ3VpZGFuY2UgZXhwb3N1cmUgbWVjaGFuaXNt IHRoYXQgY2FuIGJlIHVzZWQmbmJzcDsgdG8gYXNzaXN0IFRDUCBpbiBjZWxsdWxhciBuZXR3b3Jr cywgYW5kIGhlbHAgdG8gZW5zdXJlIGJldHRlciBuZXR3b3JrICZuYnNwO2VmZmljaWVuY3kgYW5k IGVuaGFuY2VkIHNlcnZpY2UgZGVsaXZlcnkgcGVyZm9ybWFuY2UuJm5ic3A7Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGluZS1oZWlnaHQ6MTIu NjVwdCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIGRyYWZ0IHBy ZXNlbnRzIHRoZSBwcm9ibGVtcyB0aGF0IHRoZSByYXBpZGx5LXZhcnlpbmcgY29uZGl0aW9ucyBp biBhIGNlbGx1bGFyIG5ldHdvcmsgY2FuIGNhdXNlIHRvIHRoZSBUQ1AgYmVoYXZpb3INCiBhbmQg dG8gdGhlIGFwcGxpY2F0aW9uIHBlcmZvcm1hbmNlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2xpbmUtaGVpZ2h0OjEyLjY1cHQiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBkcmFmdCZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPnNwZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGFuZCByZWZlcmVu Y2UNCiBhcmNoaXRlY3R1cmUgZm9yIHRoZSBtZWNoYW5pc20uJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo2LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGlsZSB0aGUgcHJvcG9zZWQgbWVj aGFuaXNtIGNhbiBiZSB1c2VkIHRvIG9wdGltaXplIGFueSBjb250ZW50IGQ8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPmVsaXZlcnkgYXBw bGljYXRpb24sIHRoZSBkcmFmdCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmRlc2NyaWJlcw0KIGl0cyBhcHBsaWNhYmlsaXR5IHRvJm5ic3A7dmlkZW8gZGVsaXZlcnk8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PiZuYnNwO29wdGltaXphdGlvbiBpbiBtb2JpbGUgbmV0d29ya3M8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47 bWFyZ2luLWxlZnQ6MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxMi4xcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Zb3VyIHJldmlldyBhbmQgY29tbWVudHMg d2lsbCBiZSBtdWNoIGFwcHJlY2lhdGVkLiBDb21tZW50cyBjYW4gYmUgc2VudCBvbiB0aGUgdHN2 d2cgbGlzdCBvciBkaXJlY3RseSB0byB0aGUgYXV0aG9ycy48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xp bmUtaGVpZ2h0OjEyLjFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVn YXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u c29sYXMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0OjEyLjFwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPk51cml0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpDb25zb2xhcyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBJLUQtQW5ub3VuY2UgWzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhhbGYgT2Yg ZXh0Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvc3Bhbj48L2E+PGJyPg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyMCwgMjAxNSAzOjA0 IFBNPGJyPg0KVG86Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmktZC1hbm5vdW5jZUBp ZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtc3ByZWNo ZXItbW9iaWxlLXRnLWV4cG9zdXJlLXJlcS1hcmNoLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPkEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25z b2xhcyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgOiBSZXF1aXJlbWVudHMgYW5kIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUgZm9yIE1v YmlsZSBUaHJvdWdocHV0IEd1aWRhbmNlIEV4cG9zdXJlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDogQW5rdXIgSmFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQW5kcmVhcyBUZXJ6aXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE51 cml0IFNwcmVjaGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTd2FtaW5hdGhh biBBcnVuYWNoYWxhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgS2V2aW4gU21p dGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEd1ZW50ZXIgS2xhczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFy Y2gtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u c29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDEyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAxNS0wMi0yMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+QWJzdHJh Y3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PiZuYnNwOyZuYnNwOyBSYXBpZGx5LXZhcnlpbmcgY29uZGl0aW9ucyBpbiBhIGNlbGx1bGFyIG5l dHdvcmsgY2FuIGNhdXNlIHByb2JsZW1zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyBmb3IgdGhlIFRyYW5zbWlzc2lvbiBD b250cm9sIFByb3RvY29sIChUQ1ApLCB3aGljaCBpbiB0dXJuIGNhbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsgZGVncmFk ZSBhcHBsaWNhdGlvbiBwZXJmb3JtYW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IHBy ZXNlbnRzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcHJvcG9zZXMgc29sdXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5i c3A7IHByaW5jaXBsZXMuJm5ic3A7IEl0IHNwZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGFuZCBy ZWZlcmVuY2UgYXJjaGl0ZWN0dXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyBmb3IgYSBtb2JpbGUgdGhyb3VnaHB1dCBn dWlkYW5jZSBleHBvc3VyZSBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDt0byBh c3Npc3QgVENQIGluIGNlbGx1bGFyIG5ldHdvcmtzLCBlbnN1cmluZyBiZXR0ZXIgbmV0d29yazxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz cDsmbmJzcDsgZWZmaWNpZW5jeSBhbmQgZW5oYW5jZWQgc2VydmljZSBkZWxpdmVyeSBwZXJmb3Jt YW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xh cyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u c29sYXMiPiZuYnNwOyZuYnNwOyBUaGUgcHJvcG9zZWQgbWVjaGFuaXNtIGNhbiBiZSBhcHBsaWVk IHRvIGFueSBjb250ZW50IG9yIFRDUC9JUCBiYXNlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb24gY29u dGVudCBkZWxpdmVyeS4mbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyAmbmJz cDthcHBsaWNhYmlsaXR5IG9mIHRoZSBtZWNoYW5pc20gZm9yIEludGVsbGlnZW50IFZpZGVvIEFj Y2VsZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzIj4mbmJzcDsmbmJzcDsgb3ZlciBjZWxsdWxhciBuZXR3b3Jrcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5UaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3ByZWNoZXItbW9iaWxlLXRnLWV4cG9z dXJlLXJlcS1hcmNoLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUtcmVxLWFyY2gvPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcHJlY2hlci1tb2JpbGUtdGctZXhwb3N1cmUt cmVxLWFyY2gtMDEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c3ByZWNoZXItbW9iaWxlLXRnLWV4cG9zdXJlLXJlcS1hcmNoLTAxPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3ByZWNoZXItbW9iaWxlLXRnLWV4cG9z dXJlLXJlcS1hcmNoLTAxIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LXNwcmVjaGVyLW1vYmlsZS10Zy1leHBvc3VyZS1yZXEtYXJjaC0wMTwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD b25zb2xhcyI+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRvb2xzLmlldGYu b3JnPC9zcGFuPjwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6Q29uc29sYXMiPjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29s YXMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpDb25zb2xhcyI+PGEgaHJlZj0ibWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPklu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPm9yJm5ic3A7PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRv dy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1z aXRlcy50eHQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_CE03DB3D7B45C245BCA0D24327794936399249MX104CL02corpemcc_-- From nobody Sun Feb 22 09:33:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3F91A1ADB for ; Sat, 21 Feb 2015 22:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RDBdpDqzMb33 for ; Sat, 21 Feb 2015 22:32:33 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 653271A1B0B for ; Sat, 21 Feb 2015 22:32:31 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id h15so11867685igd.3 for ; Sat, 21 Feb 2015 22:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3+3/lmlabUyL1EH4BUxHysJBQrJJMt5Ghc20xmw/RU=; b=Wm/vVRbfAfsYcfqzyvMPRlOH0twvL8xx3R2zcAMD0JYRkY4sTCqj3jH5yVBrEwBAUR zLuid+LyKXOG+3DtWWpO4P6lEp93zgwmHy65M3t1l2WHEOrwVMVoga5bLwb56C8rdy+L HlnGiERStDJr5gBL3veyoyHizfkGub/5jBoKsTwMYNx+sAx0k36Vw4t+1Nqomm/1N2wo t42Dmpqt1TdHMvEV94OEJVQr9lQ7X+OPIXJYuGBfXsj4f9nWmo/TQDrAJ1V+fUjpVI/U pLCcldSeS8uveaMsw666QpxoGCRR+bqUP2IsnTHfYUJZOv2tmtwjwkW4R3XpaqkSdv9A cb8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L3+3/lmlabUyL1EH4BUxHysJBQrJJMt5Ghc20xmw/RU=; b=DooJ6La60LcKG/MA46AASmS5lBOxk2ug4NNGoh24g9u3kv06DA8EsuAPpnTQmBs2u8 5C9YggRSZ3UpHo/v4L6Jnt3Cd9p67r+IATKYGx6LnZDHgzaZ1nul5ZwM/XwzrLSIeBpO hQ6ZWMYbk5laJwm9ndhou4g4avnkDLcQUI5Dr7V7MpSdCDe019eezmwm1gWZf6xIR2aS h4ItSjZsnqKjidTV/p2mvzYmnBQXPqaopVG/XrKnFMoVe00fCCehLnMzySsRhY2nsAhJ kAWVOKv7ctoSphcfirUoWMlvbk8BnWDLooSW58GxekKOycG8fV6RFdquK8FFMsclvQRv tJVQ== X-Gm-Message-State: ALoCoQnucunx1ZwTgnRIm6SYLrzKjIPNC2UEcfcVd+9ABCNtPl544yeGxiM717hX0kd/RTaLpk3h MIME-Version: 1.0 X-Received: by 10.107.18.22 with SMTP id a22mr7087788ioj.48.1424586750403; Sat, 21 Feb 2015 22:32:30 -0800 (PST) Received: by 10.64.34.228 with HTTP; Sat, 21 Feb 2015 22:32:30 -0800 (PST) In-Reply-To: References: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> Date: Sat, 21 Feb 2015 22:32:30 -0800 Message-ID: From: Andreas Terzis To: Ben Niven-Jenkins Content-Type: multipart/alternative; boundary=001a113ee19c35d17d050fa77347 Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:33:53 -0800 Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" , Helen Parsons , "Arunachalam, Swaminathan \(NSN - US/Irving\)" , Ankur Jain , "Cosimini, Peter, Vodafone Group" , "Flinck, Hannu \(NSN - FI/Espoo\)" , "ext Smith, Kevin, \(R&D\) Vodafone Group" , "Klas, Guenter, Vodafone Group" Subject: Re: [tcpm] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 06:32:35 -0000 --001a113ee19c35d17d050fa77347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben, Thank you for your interest in our draft. You raise a valid point, that the current draft doesn't explicitly mention discovery. We were implicitly thinking that establishing who gets throughput guidance from whom is established out of band through the same process that establishes the security associations. We should have made this clear and thank you for bringing this up. The mechanism document will include more details on the discovery mechanism. Our current plan is to ask for a slot at the TSVWG and hopefully get a chance to present this work and start a conversation in Dallas. Best regards, Andreas On Sat, Feb 21, 2015 at 1:39 PM, Ben Niven-Jenkins wrote: > Andreas, > > From a quick read of the draft it seems to me that the functional > architecture is only partially described as it is not clear to me how the > Throughput Guidance Provider discovers which TCP server(s) it should be > providing throughput guidance to or how a TCP server might discover & > register with a Throughput Guidance Provider. > > Will the other document you mention also cover discovery? > > Also, where is this document primarily being discussed (TSVWG?) as I am > interested in the work but not sure which WG to subscribe to in order to > follow/contribute towards it? > > Thanks > Ben > > On 21 Feb 2015, at 08:21, Andreas Terzis wrote: > > Lars, > > To be clear, the document that Nurit submitted talks about requirements > and doesn't propose any mechanism. > > We will soon submit another document that describe one possible mechanism > for providing throughput guidance > and a strawman for leveraging this information. That draft will include > preliminary results from lab tests. > > Best regards, > > Andreas > > > > On Fri, Feb 20, 2015 at 8:42 PM, Eggert, Lars wrote: > >> Also CC'ing TCPM and ICCRG. Is there any experimental evaluation and/or >> simulation results for the proposed mechanism? >> >> Lars >> >> On 2015-2-20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) < >> nurit.sprecher@nsn.com> wrote: >> >> >> Dear all, >> >> Please be aware of the new I-D we have submitted on =E2=80=9CRequirement= s and >> reference architecture for Mobile Throughput Guidance Exposure=E2=80=9D. >> >> The draft proposes principles for a mobile throughput guidance exposure >> mechanism that can be used to assist TCP in cellular networks, and help= to >> ensure better network efficiency and enhanced service delivery performa= nce. >> >> >> The draft presents the problems that the rapidly-varying conditions in a >> cellular network can cause to the TCP behavior and to the application >> performance. >> >> The draft specifies the requirements and reference architecture for the >> mechanism. >> >> While the proposed mechanism can be used to optimize any content deliver= y >> application, the draft describes its applicability to video delivery opt= imization >> in mobile networks. >> >> Your review and comments will be much appreciated. Comments can be sent >> on the tsvwg list or directly to the authors. >> >> Best regards, >> >> Nurit >> >> >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org >> ] On Behalf Of ext >> internet-drafts@ietf.org >> Sent: Friday, February 20, 2015 3:04 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Requirements and reference architecture for >> Mobile Throughput Guidance Exposure >> Authors : Ankur Jain >> Andreas Terzis >> Nurit Sprecher >> Swaminathan Arunachalam >> Kevin Smith >> Guenter Klas >> Filename : draft-sprecher-mobile-tg-exposure-req-arch-01.tx= t >> Pages : 12 >> Date : 2015-02-20 >> >> Abstract: >> Rapidly-varying conditions in a cellular network can cause problems >> for the Transmission Control Protocol (TCP), which in turn can >> degrade application performance. >> >> This document presents the problem statement and proposes solution >> principles. It specifies the requirements and reference architecture >> for a mobile throughput guidance exposure mechanism that can be used >> to assist TCP in cellular networks, ensuring better network >> efficiency and enhanced service delivery performance. >> >> The proposed mechanism can be applied to any content or TCP/IP based >> application content delivery. This document describes the >> applicability of the mechanism for Intelligent Video Acceleration >> over cellular networks. >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-a= rch/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-01 >> >> A diff from the previous version is available at: >> >> http://www.ietf.org/rfcdiff?url2=3Ddraft-sprecher-mobile-tg-exposure-req= -arch-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/ >> >> _______________________________________________ >> 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 >> >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a113ee19c35d17d050fa77347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben,

Thank you for your interest in our= draft.=C2=A0

You raise a valid point, that the cu= rrent draft doesn't explicitly mention discovery. We were implicitly th= inking that establishing who gets throughput guidance from whom is establis= hed out of band through the same process that establishes the security asso= ciations. We should have made this clear and thank you for bringing this up= .=C2=A0

The mechanism document will include more d= etails on the discovery mechanism.=C2=A0

Our curre= nt plan is to ask for a slot at the TSVWG and hopefully get a chance to pre= sent this work and start a conversation in Dallas.

Best regards,

Andreas

On Sat, Feb 21, 2015 at 1:39 PM, = Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:
=
Andreas,
From a quick read of the draft it seems to me that the functio= nal architecture is only partially described as it is not clear to me how t= he Throughput Guidance Provider discovers which TCP server(s) it should be = providing throughput guidance to or how a TCP server might discover & r= egister with a Throughput Guidance Provider.=C2=A0

Will the other document you mention also cover discovery?

Also, where is this document primarily being discussed (TSVWG?) as I am i= nterested in the work but not sure which WG to subscribe to in order to fol= low/contribute towards it?

Thanks
Ben

On 21 Feb 2015, at 08:21, Andreas Terzis= <aterzis@google= .com> wrote:

Lars,

To be clear, the document that Nurit submitt= ed talks about requirements and doesn't propose any mechanism.

We will soon submit another document that describe one pos= sible mechanism for providing throughput guidance
and a strawman = for leveraging this information. That draft will include preliminary result= s from lab tests.=C2=A0

Best regards,
Andreas=C2=A0



On Fri, Feb 20, 2015 at 8= :42 PM, Eggert, Lars <lars@netapp.com> wrote:
Also CC'ing = TCPM and ICCRG. Is there any experimental evaluation and/or simulation resu= lts for the proposed mechanism?

Lars
On 2015-2-20, at 14:46, Sprecher, Nurit (NSN - IL/Hod HaSharon) <= nurit.sprecher@= nsn.com> wrote:

Dear all,<= /u>

P= lease be aware of the new I-D we have submitted on =E2=80=9CRequirements an= d reference architecture for Mobile Throughput Guidance Exposure=E2=80=9D.<= u>

The draft proposes principles for a=C2=A0mobile throughput guidance exposure mechanism that can be used=C2= =A0 to assist TCP in cellular networks, and help to ensure better network = =C2=A0efficiency and enhanced service delivery performance.=C2=A0=C2=A0

The draft pr= esents the problems that the rapidly-varying conditions in a cellular netwo= rk can cause to the TCP behavior and to the application performance.=

The draft=C2=A0specifies the requ= irements and reference architecture for the mechanism.=C2=A0

While the proposed mechanism can be used to optimize any content delivery application, the draft=C2=A0describes its applicability to= =C2=A0video delivery=C2=A0optimization in mobile netwo= rks.

Your r= eview and comments will be much appreciated. Comments can be sent on the ts= vwg list or directly to the authors.

Best regards,

Nurit<= u>

=C2=A0
=C2=A0
-----Or= iginal Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext= =C2=A0internet-drafts@ietf.org
Sent: Friday, February 20, 2015 3:04 PM
To:=C2=A0i-d-announce@ietf.org
Subject: I-D Acti= on: draft-sprecher-mobile-tg-exposure-req-arch-01.txt
= =C2=A0
=C2=A0
A New Internet-Draf= t is available from the on-line Internet-Drafts directories.<= /div>
=C2=A0
=C2=A0
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : Requirements and reference architecture for Mobile = Throughput Guidance Exposure
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = : Ankur Jain
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Andreas Terzis
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Nurit Sprecher
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Swaminathan Arunachalam
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Kevin Smith
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Guenter Klas=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: draft-sprecher-mobile-tg-exposure-req-arch-01.txt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 12
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : 2015-02-20
=C2=A0
Abstract:
=C2=A0=C2=A0 Rapidly-varying conditions i= n a cellular network can cause problems
=C2=A0=C2=A0 f= or the Transmission Control Protocol (TCP), which in turn can=
=C2=A0=C2=A0 degrade application performance.
= =C2=A0
=C2=A0=C2=A0 This document presents the problem= statement and proposes solution
=C2=A0=C2=A0 principl= es.=C2=A0 It specifies the requirements and reference architecture
=C2=A0=C2=A0 for a mobile throughput guidance exposure mechani= sm that can be used
=C2=A0=C2=A0to assist TCP in cellu= lar networks, ensuring better network
=C2=A0=C2=A0 eff= iciency and enhanced service delivery performance.
= =C2=A0
=C2=A0=C2=A0 The proposed mechanism can be applied= to any content or TCP/IP based
=C2=A0=C2=A0 applicati= on content delivery.=C2=A0 This document describes the
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:10.5pt;font-family:Consolas"= >=C2=A0 =C2=A0applicability of the mechanism for Intelligent Video Accelera= tion
=C2=A0=C2=A0 over cellular networks.
=C2=A0
=C2=A0
The IETF= datatracker status page for this draft is:
=C2=A0
There's also a htmlized version= available at:
=C2=A0
= A diff from the previous version is available at:


_______= ________________________________________
tcpm mailing list<= /span>
tcpm@iet= f.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a113ee19c35d17d050fa77347-- From nobody Sun Feb 22 09:33:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB231A1B8A; Sun, 22 Feb 2015 02:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cc6Sp5l7WL7F; Sun, 22 Feb 2015 02:52:57 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84341A1B83; Sun, 22 Feb 2015 02:52:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,624,1418112000"; d="asc'?scan'208";a="25281767" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 22 Feb 2015 02:47:56 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 22 Feb 2015 02:47:55 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::90b4:b24a:2e3b:2056%21]) with mapi id 15.00.0995.031; Sun, 22 Feb 2015 02:47:55 -0800 From: "Eggert, Lars" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Thread-Topic: [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt Thread-Index: AQHQTZC/SIQvY3u84UqUDGG56FgNbZz74OkAgAEkFoA= Date: Sun, 22 Feb 2015 10:47:54 +0000 Message-ID: <4E03E1D6-56F2-4A71-8DE7-8E512629697D@netapp.com> References: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> <9B067372C2434A429FBD4CF7F0E869FD206763B1@DEMUMBX009.nsn-intra.net> In-Reply-To: <9B067372C2434A429FBD4CF7F0E869FD206763B1@DEMUMBX009.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_111F8098-4455-4B1D-9157-5D3674CD556D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:33:53 -0800 Cc: "ext Smith, Kevin, \(R&D\) Vodafone Group" , "tsvwg@ietf.org" , "Flinck, Hannu \(NSN - FI/Espoo\)" , Helen Parsons , "iccrg@irtf.org" , "tcpm@ietf.org" , Ankur Jain , "Arunachalam, Swaminathan \(NSN - US/Irving\)" , "Cosimini, Peter, Vodafone Group" , "Klas, Guenter, Vodafone Group" Subject: Re: [tcpm] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 10:53:04 -0000 --Apple-Mail=_111F8098-4455-4B1D-9157-5D3674CD556D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Nurit, On 2015-2-21, at 18:22, Sprecher, Nurit (NSN - IL/Hod HaSharon) = wrote: > Please note that the document does not specify a solution protocol, = but it proposes solution principles, requirements and a reference = architecture. It also present an applicability statement. > We will submit soon an I-D with a proposed solution protocol, which is = based on running code. We will share some preliminary test results. I'll look forward to the solution proposal. I have some general doubts = about the feasibility of approaches in this space, and so commenting on = the requirements and architecture feels a bit premature. I expect the = solution proposal will add enough context to understand what is = attempted. Thanks, Lars --Apple-Mail=_111F8098-4455-4B1D-9157-5D3674CD556D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVOmz2tZcnpRveo1xAQJXeQQAt7Pg8BAO7F2tPQG7L2p+njbAlax/sjqe TKZLLs1CGIWic4viLlyEwU0UAzKo+DZ2f37iTJ692F3spJygPIE2bqbtyvDuwt4b Zd2AiGOiXRGhBNA0WiLxGJ8dEtsh5ViwylgVezp2SCCIKaMylbc4AlXLREsz5bE0 iqRuPqZeG4Q= =l/MD -----END PGP SIGNATURE----- --Apple-Mail=_111F8098-4455-4B1D-9157-5D3674CD556D-- From nobody Sun Feb 22 09:33:59 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6FA1A1EF4; Sun, 22 Feb 2015 03:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uPyfSZ6Mxogd; Sun, 22 Feb 2015 03:50:45 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C661A1DBD; Sun, 22 Feb 2015 03:50:44 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-21-54e9c2938a35 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E9.90.08135.392C9E45; Sun, 22 Feb 2015 06:50:43 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t1MBofP2029062; Sun, 22 Feb 2015 06:50:41 -0500 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t1MBobw6007494; Sun, 22 Feb 2015 06:50:37 -0500 Received: from OC11EXHUB7.exchange.mit.edu (18.9.3.19) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Feb 2015 06:49:42 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.190]) by OC11EXHUB7.exchange.mit.edu ([18.9.3.19]) with mapi id 14.03.0158.001; Sun, 22 Feb 2015 06:50:36 -0500 From: Marie-Jose Montpetit To: "Eggert, Lars" Thread-Topic: [iccrg] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt Thread-Index: AQHQTZC/SIQvY3u84UqUDGG56FgNbZz74OkAgAEkFoD//986gA== Date: Sun, 22 Feb 2015 11:50:35 +0000 Message-ID: <28C06B71-02C9-458E-B509-4C98783B2874@mit.edu> References: <9B067372C2434A429FBD4CF7F0E869FD2066AFB6@DEMUMBX009.nsn-intra.net> <37ACFF3F-827D-424D-A51F-073057155AE5@netapp.com> <9B067372C2434A429FBD4CF7F0E869FD206763B1@DEMUMBX009.nsn-intra.net> <4E03E1D6-56F2-4A71-8DE7-8E512629697D@netapp.com> In-Reply-To: <4E03E1D6-56F2-4A71-8DE7-8E512629697D@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_AB1E5CF4-779D-4A7D-AECD-527C612301AE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02TWUwTURSGvdPpdFoZMlakl4okjFuCgEskTlzQkCD1xahBY4wGBzq2jV3I TEHwyYjGNbhApDQSdlRcWjERJC5QBQETlroFIggCCgXBDcHdaUeQt//c/zv/uSe5F5couzA1 bjBbWc7MGClMgSrlc+ZHZLkG45dlXJ9J9zU1ILQjM1dKDzTfktA1BXdkdMPNSwjd216E0AND p1G6/e4meuBHkYz25PUj9O3GfISuH+7ENvhpCipSNCUl3xBN1s2HmMb26Qum6exwI5pMmwNs wXYp1mpZoyGV5ZZG71Xof/15L0luDE17+aFWegg4Qk4COQ7JlfDUt5+YqANha5dD0ApcSRYj 8N2jw0AsagCsrm5GxeIxgJ7u+1KxuA1gZncvIhblAH6uK0W8YRgZDvuPFkm8OoBcAG/lP5F5 IQlZKoWDJzw+aDa5G15uOIOK0B44fNwlE3UMrLxh990KJRfCc211PoYgV8N77nGZOO0XgC9G P/gMORkN37WPSb0aCGuMN13zDZCQKtjRl4+I6wXAnrYnU6v+ru75pyl47pUbE2+XDWBOTrFU nDYLNub2oWcBtE/Lsk/n7NM4EVoCywqHJHaACzocZhUC8TgKDtV9/KfXQNv3WkzUoTD7VI+s AODlYJ7WdDDCxBiMPJsUwScxZjPLRayINBmskaw2pQL4nk4QUQVGaikXIHFA+RG0bTBeKWVS +XSTCwThCDWHaHcKR/6JFm26nuH1CVyKkeVdYIEw643zaitQo2aLmaUCCEuZwBFaJv0gy1km sbk4SqmIign/eCWpY6zsfpZNZrlJNxjHKUiU1AqNszhWx6btMxit/20El7sAxP2EcKeXIfhk xsQbdKLfBELVKuK81yC9hj7FPNU7+S08QCWsNZsYqREoP+HTTHV7hGBECK4Ze+sNtjL/LfUh ELVNHTO8JN8duz71Qc/TeXnZKlmobtGqzJA4LuvCKLa4smBGWOKaHYnWwZ3d+0w/FYFDb183 Yd1nG/IKn398Vl44UlKlWp2hKLM4g0N2F9dLDxt0QV0toy18XDBevnVz3oGEOqdtbLzNfTfW zDgT1h3ZvuzYxdjoKzFfL2ekT2yMp1BezywPk3A88xdK4rsZ8QMAAA== Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 09:33:53 -0800 Cc: "ext Smith, Kevin, \(R&D\) Vodafone Group" , "tsvwg@ietf.org" , "Flinck, Hannu \(NSN - FI/Espoo\)" , Helen Parsons , "iccrg@irtf.org" , "tcpm@ietf.org" , Ankur Jain , "Arunachalam, Swaminathan \(NSN - US/Irving\)" , "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "Klas, Guenter, Vodafone Group" , "Cosimini, Peter, Vodafone Group" Subject: Re: [tcpm] [iccrg] [tsvwg] I-D Action: draft-sprecher-mobile-tg-exposure-req-arch-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 11:50:47 -0000 --Apple-Mail=_AB1E5CF4-779D-4A7D-AECD-527C612301AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all: there has been a lot of work on how to "improve" TCP over all kinds of = wireless networks in the past. Proxy based solutions for example. Or = caching. Or network coding (on going work/research). Or combinations. = And then solutions looking at MAC layer improvements and even lower = layer which are outside the scope of the IETF.=20 I like the fact your requirements state that there should not be any = specific software on the end user device but that still leave a large = solution space. And I agree with Lars that details will be important and = real implementations even more. /mjm Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Feb 22, 2015, at 5:47 AM, Eggert, Lars wrote: >=20 > Hi Nurit, >=20 > On 2015-2-21, at 18:22, Sprecher, Nurit (NSN - IL/Hod HaSharon) = wrote: >> Please note that the document does not specify a solution protocol, = but it proposes solution principles, requirements and a reference = architecture. It also present an applicability statement. >> We will submit soon an I-D with a proposed solution protocol, which = is based on running code. We will share some preliminary test results. >=20 > I'll look forward to the solution proposal. I have some general doubts = about the feasibility of approaches in this space, and so commenting on = the requirements and architecture feels a bit premature. I expect the = solution proposal will add enough context to understand what is = attempted. >=20 > Thanks, > Lars >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg --Apple-Mail=_AB1E5CF4-779D-4A7D-AECD-527C612301AE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwMjIyMTE1MDM2WjAjBgkqhkiG9w0BCQQxFgQUstfin4udNNAnOYs8kmEFb0CBrYUw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYBBY3KH9RdBFe7YdGs0CMW7QZGjBxxOYNjW J2jtsD1xRfbthyKa5TXM0tMBieTxphfWeB+95xBLq/wBbmS6qr9EKoUsHniAqe9QSlDI94IIrwij 6FdVs07Enyav2qLraQUPowwxM923Oc2PL4L+t7KaQ3KkpN7NFmWssykoM+cw0AAAAAAAAA== --Apple-Mail=_AB1E5CF4-779D-4A7D-AECD-527C612301AE-- From nobody Mon Feb 23 01:49:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D515C1A01F0 for ; Mon, 23 Feb 2015 01:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 n7MVVed19FoL for ; Mon, 23 Feb 2015 01:49:55 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 743A11A0019 for ; Mon, 23 Feb 2015 01:49:55 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5AD025F78B15F; Mon, 23 Feb 2015 09:49:51 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t1N9njeR015854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Feb 2015 10:49:53 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 23 Feb 2015 10:49:50 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCPM agenda for IETF 92 Thread-Index: AdBPTg/WD5Q5w7esTTG4nqqaqeo/dg== Date: Mon, 23 Feb 2015 09:49:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C24E57@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] TCPM agenda for IETF 92 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 09:49:57 -0000 Folks, According to the preliminary agenda (https://datatracker.ietf.org/meeting/9= 2/agenda.html), TCPM will probably have the following slot during the Dalla= s meeting: Date: TUESDAY, March 24, 2015, 0900-1130 (Morning Session I) Room: Oak If you are interested in presenting a draft in TCPM, please provide to the = chairs the following information: * Title / draft name * Presenter's name * Planned duration Thanks Michael, Pasi, Yoshifumi From nobody Mon Feb 23 10:43:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E11A1BE4; Mon, 23 Feb 2015 10:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 gbRop51dbt2h; Mon, 23 Feb 2015 10:43:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B52071A1B3C; Mon, 23 Feb 2015 10:43:40 -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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223184340.28534.22810.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 10:43:40 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:43:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Authors : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-08.txt Pages : 23 Date : 2015-02-23 Abstract: This document updates RFC 5681 to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-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 Feb 23 11:53:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873601A6EE8 for ; Mon, 23 Feb 2015 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8ZDfq9UgRzJ4 for ; Mon, 23 Feb 2015 11:53:28 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CBC1A1DBC for ; Mon, 23 Feb 2015 11:53:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,632,1418112000"; d="asc'?scan'208";a="26169876" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx141-out.netapp.com with ESMTP; 23 Feb 2015 11:48:28 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 23 Feb 2015 11:48:27 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::fd84:3b4:c925:550f%21]) with mapi id 15.00.0995.031; Mon, 23 Feb 2015 11:48:27 -0800 From: "Zimmermann, Alexander" To: "Scharf, Michael (Michael)" , "Scheffenegger, Richard" Thread-Topic: [tcpm] TCPM agenda for IETF 92 Thread-Index: AdBPTg/WD5Q5w7esTTG4nqqaqeo/dgAlq6YA Date: Mon, 23 Feb 2015 19:48:26 +0000 Message-ID: <89A05E1C-52D1-42B8-8E65-D8586821F630@netapp.com> References: <655C07320163294895BBADA28372AF5D16C24E57@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C24E57@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_79D3369E-A2A0-4D0A-929E-434E1F773F45"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] TCPM agenda for IETF 92 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:53:29 -0000 --Apple-Mail=_79D3369E-A2A0-4D0A-929E-434E1F773F45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 23.02.2015 um 10:49 schrieb Scharf, Michael (Michael) = : >=20 > Folks, >=20 > According to the preliminary agenda = (https://datatracker.ietf.org/meeting/92/agenda.html), TCPM will = probably have the following slot during the Dallas meeting: >=20 > Date: TUESDAY, March 24, 2015, 0900-1130 (Morning Session I) > Room: Oak >=20 > If you are interested in presenting a draft in TCPM, please provide to = the chairs the following information: >=20 > * Title / draft name draft-ietf-tcpm-undeployed > * Presenter=E2=80=99s name Richard > * Planned duration 5mins >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_79D3369E-A2A0-4D0A-929E-434E1F773F45 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTrhAsACgkQdyiq39b9uS5ahgCgpV7uS+tNhs5oUAy7xdHpUPTe Z6kAni6QrwlQc6QWKKbGrcfbBIgrB+G2 =3Oyn -----END PGP SIGNATURE----- --Apple-Mail=_79D3369E-A2A0-4D0A-929E-434E1F773F45-- From nobody Mon Feb 23 11:53:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82EE1A6EF9 for ; Mon, 23 Feb 2015 11:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4BK_zdpRf0-z for ; Mon, 23 Feb 2015 11:53:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EFF1A1DBC for ; Mon, 23 Feb 2015 11:53:55 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t1NJqwlW002661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Feb 2015 11:52:58 -0800 (PST) Message-ID: <54EB8517.9030805@isi.edu> Date: Mon, 23 Feb 2015 11:52:55 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Wesley Eddy , "tcpm@ietf.org" References: <54D51FEF.9080607@mti-systems.com> In-Reply-To: <54D51FEF.9080607@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 793bis update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:53:56 -0000 Hi, Wes, Sorry for the delay in responding. I had a few thoughts, below. Joe On 2/6/2015 12:11 PM, Wesley Eddy wrote: > FYI - I posted an update to the proposed RFC793bis (still an individual, > not a working group draft): > http://tools.ietf.org/html/draft-eddy-rfc793bis-05 > > The main goals in this revision was to introduce a section on > segmentation of data and place into that section the normative > content from RFCs that updated 793 and cover the MSS & PMTU > topics. The section is useful, but I think also ignores a few key issues that would be useful to highlight: - there's a tension between sending "as large as possible" and a few other goals: - sending as few short segments as possible - avoiding delays to the stream, esp. when the user data is NOT always available (i.e., when TCP has to wait) - "as large as possible" is nearly never a useful goal; it's a consequence of some other goal The goal is often either performance or fate-sharing. Performance argues for larger packets, but the benefit decreases as the size increases. Further, there are some sizes that, while bigger, are not always better (e.g., 1025 bytes can be worse than 1024, even when both fit in a segment, due to data alignment on copy). Fate sharing argues for smaller packets because TCP is not always aware of fragmentation/reassembly at lower layers (the degenerate case being AAL5 over ATM, but there are other examples). So just because the next-layer down has a given MTU, does NOT automatically make that MTU a goal. - TCP's default MSS has other rules I thought there was a rule about being on the same subnet and using the interface as the starting MSS. - I thought TCP SHOULD also support PLMTUD, not just PMTUD. The difference should be discussed in more detail than given in sec 3.7.2. - Regarding: o TCPhdrsize is the size of the fixed TCP header; this is normally 20, but may be larger if TCP options are to be sent. If TCPhdrsize is the size of the fixed TCP header then it is ALWAYS 20. And TCP headers almost always have options. I think you may have intended: TCPhdrsize is the size of the TCP header and any options; this is 20 in the (rare) case that no options are present. - Regarding: o IPoptionsize is the size of any IP options that TCP will pass to the IP layer with the current message. TCP doesn't pass options. That happens as a result of settings to the socket. - it would be useful, IMO, to highlight the relationship between TCP segment boundaries and user data I.e., that TCP guarantees NO such boundary coherence. Joe From nobody Tue Feb 24 08:22:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457A21A1A48 for ; Tue, 24 Feb 2015 08:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 gwXQ8JknW7Tv for ; Tue, 24 Feb 2015 08:22:54 -0800 (PST) Received: from atl4mhob19.myregisteredsite.com (atl4mhob19.myregisteredsite.com [209.17.115.112]) by ietfa.amsl.com (Postfix) with ESMTP id DC5241A1A25 for ; Tue, 24 Feb 2015 08:22:53 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob19.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t1OGMnCM003344 for ; Tue, 24 Feb 2015 11:22:49 -0500 Received: (qmail 20909 invoked by uid 0); 24 Feb 2015 16:22:49 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.2?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 24 Feb 2015 16:22:48 -0000 Message-ID: <54ECA555.40501@mti-systems.com> Date: Tue, 24 Feb 2015 11:22:45 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Joe Touch , "tcpm@ietf.org" References: <54D51FEF.9080607@mti-systems.com> <54EB8517.9030805@isi.edu> In-Reply-To: <54EB8517.9030805@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] 793bis update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:22:56 -0000 On 2/23/2015 2:52 PM, Joe Touch wrote: > Hi, Wes, > > Sorry for the delay in responding. I had a few thoughts, below. Hi Joe, many thanks for the feedback. Since getting this right is more important than doing it fast, there's no need to apologize about delay in responding! This was a trickier update among the ones that I'd worked so far, mostly because the rules and advice on MSS and related topics is spread out over several RFCs, and although 6691 helped quite a bit, it didn't quite go so far as to say what the prescriptive text should have looked like in 793 or 1122 :). So, careful review of this is much appreciated. I essentially agree with your points, and intend to work them all to some extent into the next update, but some responses are inline below with some explanations and follow-up questions. > > On 2/6/2015 12:11 PM, Wesley Eddy wrote: >> FYI - I posted an update to the proposed RFC793bis (still an individual, >> not a working group draft): >> http://tools.ietf.org/html/draft-eddy-rfc793bis-05 >> >> The main goals in this revision was to introduce a section on >> segmentation of data and place into that section the normative >> content from RFCs that updated 793 and cover the MSS & PMTU >> topics. > > The section is useful, but I think also ignores a few key issues that > would be useful to highlight: > > - there's a tension between sending "as large as possible" and a few > other goals: > > - sending as few short segments as possible > > - avoiding delays to the stream, esp. when the user data > is NOT always available (i.e., when TCP has to wait) Thanks for mentioning these; they definitely should be reflected in the text in the next update. > - "as large as possible" is nearly never a useful goal; it's a > consequence of some other goal > > The goal is often either performance or fate-sharing. > > Performance argues for larger packets, but the benefit > decreases as the size increases. Further, there are some > sizes that, while bigger, are not always better (e.g., > 1025 bytes can be worse than 1024, even when both fit > in a segment, due to data alignment on copy). > > Fate sharing argues for smaller packets because TCP > is not always aware of fragmentation/reassembly at lower > layers (the degenerate case being AAL5 over ATM, but there > are other examples). So just because the next-layer down > has a given MTU, does NOT automatically make that MTU a goal. You're obviously correct, and this should be fixed and clarified in the text in the next update. > - TCP's default MSS has other rules > > I thought there was a rule about being on the same subnet > and using the interface as the starting MSS. There seems to be at least a little bit of discussion on this in RFC 879, though I haven't yet bumped into a very clear statement of it. Do you know of anyplace that this lives in the literature / RFC series? > - I thought TCP SHOULD also support PLMTUD, not just PMTUD. > > The difference should be discussed in more detail than given in > sec 3.7.2. > This seems fair to discuss at least a bit further in the document. I'm not positive whether there is or is not an RFC existing already that says "SHOULD support PLPMTUD, not just PMTUD" ... I would guess that most folks would agree with it, but I'm just not sure if there's a place that says it in 2119-speak. Maybe I'm being too pedantic about trying to keep the scope to specific recommendations and changes to 793 that have already been approved in other RFCs and errata ... We can certainly say that RFC 4821 describes the algorithm and specific probing mechanism for use with TCP, and that it's on the Standards Track as an improvement to PMTUD. > - Regarding: > o TCPhdrsize is the size of the fixed TCP header; this is normally > 20, but may be larger if TCP options are to be sent. > > If TCPhdrsize is the size of the fixed TCP header then it is > ALWAYS 20. And TCP headers almost always have options. > > I think you may have intended: > > TCPhdrsize is the size of the TCP header and any options; > this is 20 in the (rare) case that no options are present. Actually, this text is stolen directly from RFC 1122. I have actually been working to avoid writing or changing text, to the greatest extent possible :). I think you're right in clarifying this though, and it's in the spirit of part of what went into RFC 6691 to make this clear, so I like it. We actually may want to be stronger and say that if TCP options are used on a segment, then the sender should adjust the data length accordingly, just like section 4 of RFC 6691 says. > - Regarding: > o IPoptionsize is the size of any IP options that TCP will pass to > the IP layer with the current message. > > TCP doesn't pass options. That happens as a result of settings > to the socket. This is also directly from 1122. We could probably add some clarity here with slight text modification to remain implementation-neutral (e.g. not assuming a socket programming model), but still say that IP options need to be accounted for. > - it would be useful, IMO, to highlight the relationship between TCP > segment boundaries and user data > > I.e., that TCP guarantees NO such boundary coherence. I could use some help with this. Are you referring to something along the lines of discussion that has been had around Bob Briscoe's "inner space" work? -- Wes Eddy MTI Systems From nobody Tue Feb 24 08:41:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1581A8833 for ; Tue, 24 Feb 2015 08:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 6UtzufDDMsS0 for ; Tue, 24 Feb 2015 08:41:34 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0E11A884E for ; Tue, 24 Feb 2015 08:41:06 -0800 (PST) Received: from [192.168.1.10] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t1OGe4wh013093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Feb 2015 08:40:28 -0800 (PST) Message-ID: <54ECA964.8020008@isi.edu> Date: Tue, 24 Feb 2015 08:40:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Wesley Eddy , "tcpm@ietf.org" References: <54D51FEF.9080607@mti-systems.com> <54EB8517.9030805@isi.edu> <54ECA555.40501@mti-systems.com> In-Reply-To: <54ECA555.40501@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 793bis update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:41:35 -0000 Followup below... On 2/24/2015 8:22 AM, Wesley Eddy wrote: ... >> - TCP's default MSS has other rules >> >> I thought there was a rule about being on the same subnet >> and using the interface as the starting MSS. > > There seems to be at least a little bit of discussion on this in RFC > 879, though I haven't yet bumped into a very clear statement of it. > Do you know of anyplace that this lives in the literature / RFC series? Found it: RFC1122, Sec 3.3.3: ...In the absence of actual knowledge of the minimum MTU along the path, the IP layer SHOULD use EMTU_S <= 576 whenever the destination address is not on a connected network, and otherwise use the connected network's MTU. "connected network's MTU" is 1990s slang for "NIC interface when on the same subnet". >> - I thought TCP SHOULD also support PLMTUD, not just PMTUD. >> >> The difference should be discussed in more detail than given in >> sec 3.7.2. > > This seems fair to discuss at least a bit further in the document. I'm > not positive whether there is or is not an RFC existing already that > says "SHOULD support PLPMTUD, not just PMTUD" I don't know either. It's not in the PLPMTUD RFC, which is written more as "if you implement this, here's what you MUST/SHOULD/MAY do". > ... I would guess that > most folks would agree with it, but I'm just not sure if there's a place > that says it in 2119-speak. Maybe I'm being too pedantic about trying > to keep the scope to specific recommendations and changes to 793 that > have already been approved in other RFCs and errata ... Oh, agreed - I think it's worth digging to find out, but unfortunately I don't have cycles (I'm writing a midterm in the other window)... > We can certainly say that RFC 4821 describes the algorithm and specific > probing mechanism for use with TCP, and that it's on the Standards Track > as an improvement to PMTUD. It is, but you're right that we've never made a statement that says that it should be used to replace PMTUD wherever PMTUD is required, AFAICT. >> - Regarding: >> o TCPhdrsize is the size of the fixed TCP header; this is normally >> 20, but may be larger if TCP options are to be sent. >> >> If TCPhdrsize is the size of the fixed TCP header then it is >> ALWAYS 20. And TCP headers almost always have options. >> >> I think you may have intended: >> >> TCPhdrsize is the size of the TCP header and any options; >> this is 20 in the (rare) case that no options are present. > > Actually, this text is stolen directly from RFC 1122. I have actually > been working to avoid writing or changing text, to the greatest extent > possible :). > > I think you're right in clarifying this though, and it's in the spirit > of part of what went into RFC 6691 to make this clear, so I like it. > We actually may want to be stronger and say that if TCP options are > used on a segment, then the sender should adjust the data length > accordingly, just like section 4 of RFC 6691 says. Agreed. >> - Regarding: >> o IPoptionsize is the size of any IP options that TCP will pass to >> the IP layer with the current message. >> >> TCP doesn't pass options. That happens as a result of settings >> to the socket. > > This is also directly from 1122. We could probably add some clarity > here with slight text modification to remain implementation-neutral > (e.g. not assuming a socket programming model), but still say that IP > options need to be accounted for. Agreed to avoid the socket model per se; a different way of saying it is that the "IP options associated with a TCP connection", rather than to make it sound like TCP has an interface where it tells IP which options to use (RFC793 certainly does not). >> - it would be useful, IMO, to highlight the relationship between TCP >> segment boundaries and user data >> >> I.e., that TCP guarantees NO such boundary coherence. > > I could use some help with this. Are you referring to something along > the lines of discussion that has been had around Bob Briscoe's "inner > space" work? This goes back to RDMA and its precursors a long time ago. I.e., the point is that send/receive calls (per RFC793) pass data in chunks to TCP, and TCP senders pass chunks from senders to receivers, but those two chunks have no correlation. RDMA gets around this by assuming they do on the sender side, and detecting that they're sustained through to the receiver side - i.e., it says "detect when it happens and take advantage of it", but it doesn't assume it either (I pushed back hard on that). Joe From nobody Tue Feb 24 13:54:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9D1A903B for ; Tue, 24 Feb 2015 13:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sO1FdpRrxBQE for ; Tue, 24 Feb 2015 13:54:35 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 1033F1A9036 for ; Tue, 24 Feb 2015 13:54:35 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YQNR3-0006ke-MJ for tcpm@ietf.org; Tue, 24 Feb 2015 22:54:33 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YQNR2-0006HH-M6 for tcpm@ietf.org; Tue, 24 Feb 2015 22:54:33 +0100 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_04BCF53C-BE01-438C-8434-0E190D92703A" Message-Id: Date: Tue, 24 Feb 2015 22:54:31 +0100 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 2 sum msgs/h 2 total rcpts 25949 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 84B4F2B9174829FAD8F2E773131E956DA0398609 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 348 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] Review of draft-zimmermann-tcpm-reordering-detection-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:54:39 -0000 --Apple-Mail=_04BCF53C-BE01-438C-8434-0E190D92703A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I just read = https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 = Since I don=E2=80=99t fiddle with the TCP recovery code on a daily = basis, I am a member of a large group of people who, in my opinion, can = never make solid claims about the correctness of a mechanism like this = one. All people like me can do is read and comment and hope for the best = :-) because fully understanding this from simply reading, not = looking at code, is REALLY hard. I don=E2=80=99t blame it on the = authors: I appreciate that making this document easier to read must be = very, very difficult. Anyway. Here it goes - enjoy :-) Overall, this looks like a good mechanism to me, and I support the = document. Details below: *** A TCP connection that does not employ the Nagle algorithm SHOULD NOT use = this methodology. *** isn=E2=80=99t Nagle something that can be dynamically turned on or off? = If so, I guess this statement should elaborate - do you want the whole = mechanism to be disabled if Nagle is disabled once during the lifetime = of a connection? *** 4.1 c.2 "If the TCP Timestamps option [RFC1122] has been negotiated, then the variable Timestamps MUST be activated and=E2=80=A6.=E2=80= =9D *** I don=E2=80=99t think one can =E2=80=9Cactivate=E2=80=9D a variable. = Since this is a boolean, this should probably read =E2=80=9CMUST be set = to true=E2=80=9D ? (below in c.2, =E2=80=9Cdeactivated=E2=80=9D is fine because it talks = about a mechanism, not a variable) 4.3 S.1: skip to step A.4 is really weird here=E2=80=A6 so S.1 to S.5 is = supposed to be a function call from within the sequence A.1 to A.4; = I=E2=80=99d expect to see something equivalent to a =E2=80=9Creturn=E2=80=9D= here, which would take us to A.3, not A.4 Also, when reaching S.4 and reading "Samples[SEG.SEQ].ReorExtR=E2=80=9D = I wondered where =E2=80=9CReorExtR=E2=80=9D came from? Oh right, a = sentence above in S.2 says it, they are the results of steps E.1 to E.4. = But this code comes later - I think the fact that this =E2=80=9Cfunction = call=E2=80=9D returns ReorExtR and ReorExtA should be presented more = prominently rather than just mentioning the variables in passing. Maybe extra information could be added below all the =E2=80=9Cfunction = calls=E2=80=9D, i.e. the statements of the style: "The TCP sender MUST execute steps (E.1) to (E.4)=E2=80=9D For this particular statement, the extra information could read: =E2=80=9CThis is the reordering extent computation, yielding the = relative reordering extent in variable ReorExtR and the absolute = reordering extent in variable ReorExtA.=E2=80=9D This could (hopefully?) make the algorithm easier to understand. 4.4 D.2 and D.3: I think that the phrase "If a) the previous step (D.1) = was not executed=E2=80=9D isn=E2=80=99t as easy to parse as =E2=80=9CIf = Dsack =3D=3D false=E2=80=9D of =E2=80=9CIf NOT DSACK=E2=80=9D would be. = If possible, you could replace it. However note that this is maybe not = equivalent? My condition also fires if Dsack was set to true before, not = only if D.1 was not executed in the same sequence. Clearly, only replace = if that doesn=E2=80=99t matter :) Up to section 5, unless I overread it, there is no single statement that = explains the underlying idea of the algorithm in simple terms. To me, = this is all captured well by the following sentence in section 5: "Whenever a received acceptable ACK or SACK closes a hole in the sequence number space of the SACK scoreboard either partially or completely, this is an indication of packet reordering in the network (step (A.2)).=E2=80=9D I think section 5 is fine where it is, and it=E2=80=99s good that it = elaborates further after this sentence - but the message conveyed by = this particular sentence should be brought very early, in the = introduction, probably even in the abstract. =46rom the abstract, it=E2=80= =99s not exactly clear *how* the mechanism here achieves it=E2=80=99s = magic - it only says: "The algorithm for the detection and = quantification of reordering in this document uses information gathered = from the TCP Timestamps Option, the TCP SACK Option and its DSACK = extension.=E2=80=9D - I would strongly suggest to say already here that = the underlying idea is that filling a hole can indicate reordering. !!!! continue reading in sec 5 after this statement. Just a style thing: I would replace "The important fact is that...=E2=80=9D= with =E2=80=9CWhat matters is that =E2=80=A6=E2=80=9D IIUC the discussion in sections 6.1 / 6.2 assumes that reordering = typically occurs as a function of time rather than as a fixed number of = packets. While that seems like a reasonable assumption to me, is there = any basis to it - anything that can be cited? (sorry if I missed it!) section 6.2: =E2=80=9CThe scheme proposed in this document is to = calculate the relative reordering by =E2=80=9C should be: =E2=80=9CThe = scheme =E2=80=A6. calculates the relative=E2=80=A6=E2=80=9D Last paragraph of section 6.2: Hmmm=E2=80=A6 I don=E2=80=99t get why = this is so hard. Maybe this is just me being naive and stupid here, but = then maybe the explanation should be improved: flightsize is the = currently used window, which is transmitted per RTT. So the current rate = is flightsize/RTT, no? Wouldn=E2=80=99t that suffice (say, using the = latest RTT sample) as a rate, rather than a value that depends on the = BDP? If you don=E2=80=99t want to go down this path for some reason but if = I=E2=80=99m right with this simple idea, then the statement "But since = the calculation would be far from trivial and introducing more = complexity, this is considered to be future research.=E2=80=9D should = perhaps be updated. 6.3 par 1: remove =E2=80=9Ca=E2=80=9D in "even with a minor packet = reordering=E2=80=9D, and missing =E2=80=9Cthe=E2=80=9D in "=46rom TCP = sender's perspective=E2=80=9D. Also, =E2=80=9Cpersistent receiving=E2=80=9D= =3D> =E2=80=9Cpersistent reception=E2=80=9D. par2: I have trouble parsing the middle ("amount of data a = reordered=E2=80=A6") of the sentence: "If the transmission rate of the TCP sender, and therefore also the maximum amount of data a reordered segment can be received too late, changes significantly during its stay in the 'disorder' state, the actual amount of reordering is not accurately determined by the relative reordering extent.=E2=80=9D below: double =E2=80=9Center=E2=80=9D in "if the amount of outstanding = data is low when entering the 'disorder' state is entered=E2=80=9D section 7 par 1: missing =E2=80=9Cthe=E2=80=9D in "Because of = retransmission ambiguity problem=E2=80=A6=E2=80=9D same par: "the detection is usually conducted by detecting a closed hole in sequence number space of the SACK scoreboard.=E2=80=9D - what do you mean, =E2=80=9Cusually=E2= =80=9D? This is what the algorithm described in this draft does, right? = Or is it also elsewhere? (if so, I suggest to add a reference) section 10: broken sentence ("performance measurement tool, which give = us a powerful tool=E2=80=9D) Cheers, Michael --Apple-Mail=_04BCF53C-BE01-438C-8434-0E190D92703A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = just read https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-de= tection-02

Since I don=E2=80=99t fiddle with the TCP recovery code on a = daily basis, I am a member of a large group of people who, in my = opinion, can never make solid claims about the correctness of a = mechanism like this one. All people like me can do is read and comment = and hope for the best  :-)    because fully understanding = this from simply reading, not looking at code, is REALLY hard. I don=E2=80= =99t blame it on the authors: I appreciate that making this document = easier to read must be very, very difficult.


Anyway. Here it goes - enjoy  :-)

Overall, this looks like a good mechanism to me, and I = support the document. Details below:

***
A TCP connection that = does not employ the Nagle algorithm SHOULD NOT use this methodology.
***
isn=E2=80=99t Nagle something that can be = dynamically turned on or off? If so, I guess this statement should = elaborate - do you want the whole mechanism to be disabled if Nagle is = disabled once during the lifetime of a connection?


***
4.1 c.2 "If the TCP = Timestamps option [RFC1122] has been negotiated,
         then = the variable Timestamps MUST be activated and=E2=80=A6.=E2=80=9D
***
I don=E2=80=99t think one can = =E2=80=9Cactivate=E2=80=9D a variable. Since this is a boolean, this = should probably read =E2=80=9CMUST be set to true=E2=80=9D ?

(below in c.2, =E2=80=9Cdeactivated=E2=80=9D = is fine because it talks about a mechanism, not a variable)


4.3 S.1: skip to step A.4 is = really weird here=E2=80=A6 so S.1 to S.5 is supposed to be a function = call from within the sequence A.1 to A.4; I=E2=80=99d expect to see = something equivalent to a =E2=80=9Creturn=E2=80=9D here, which would = take us to A.3, not A.4


Also, = when reaching S.4 and reading "Samples[SEG.SEQ].ReorExtR=E2=80=9D I = wondered where =E2=80=9CReorExtR=E2=80=9D came from? Oh right, a = sentence above in S.2 says it, they are the results of steps E.1 to E.4. = But this code comes later - I think the fact that this =E2=80=9Cfunction = call=E2=80=9D returns ReorExtR and ReorExtA should be presented more = prominently rather than just mentioning the variables in passing.

Maybe extra information could be added below = all the =E2=80=9Cfunction calls=E2=80=9D, i.e. the statements of the = style:

"The TCP sender MUST execute steps = (E.1) to (E.4)=E2=80=9D

For this particular = statement, the extra information could read:

=E2=80=9CThis is the reordering extent computation, yielding = the relative reordering extent in variable ReorExtR and the absolute = reordering extent in variable ReorExtA.=E2=80=9D

This could (hopefully?) make the algorithm easier to = understand.


4.4 D.2 and D.3: = I think that the phrase "If a) the previous step (D.1) was not = executed=E2=80=9D isn=E2=80=99t as easy to parse as =E2=80=9CIf Dsack =3D=3D= false=E2=80=9D of =E2=80=9CIf NOT DSACK=E2=80=9D would be. If possible, = you could replace it. However note that this is maybe not equivalent? My = condition also fires if Dsack was set to true before, not only if D.1 = was not executed in the same sequence. Clearly, only replace if that = doesn=E2=80=99t matter  :)


Up to section 5, unless I overread it, there is no single = statement that explains the underlying idea of the algorithm in simple = terms. To me, this is all captured well by the following sentence in = section 5:
"Whenever a received acceptable ACK or SACK = closes a hole in the
  sequence number space of = the SACK scoreboard either partially or
  completely, this is an indication of packet = reordering in the network
  (step (A.2)).=E2=80=9D=

I think section 5 is fine where it is, and = it=E2=80=99s good that it elaborates further after this sentence - but = the message conveyed by this particular sentence should be brought very = early, in the introduction, probably even in the abstract. =46rom the = abstract, it=E2=80=99s not exactly clear *how* the mechanism here = achieves it=E2=80=99s magic - it only says: "The algorithm for the = detection and quantification of reordering in this document uses = information gathered from the TCP Timestamps Option, the TCP SACK Option = and its DSACK extension.=E2=80=9D  - I would strongly suggest to = say already here that the underlying idea is that filling a hole can = indicate reordering.

!!!! continue reading = in sec 5 after this statement.

Just a style thing: I would replace "The important fact is = that...=E2=80=9D  with =E2=80=9CWhat matters is that = =E2=80=A6=E2=80=9D

IIUC the discussion in sections 6.1 / 6.2 assumes that = reordering typically occurs as a function of time rather than as a fixed = number of packets. While that seems like a reasonable assumption to me, = is there any basis to it - anything that can be cited? (sorry if I = missed it!)

section 6.2: =E2=80=9CThe scheme proposed in this document is = to calculate the relative reordering by =E2=80=9C  should be: = =E2=80=9CThe scheme =E2=80=A6. calculates the relative=E2=80=A6=E2=80=9D

Last paragraph = of section 6.2:  Hmmm=E2=80=A6 I don=E2=80=99t get why this is so = hard. Maybe this is just me being naive and stupid here, but then maybe = the explanation should be improved: flightsize is the currently used = window, which is transmitted per RTT. So the current rate is = flightsize/RTT, no? Wouldn=E2=80=99t that suffice (say, using the latest = RTT sample) as a rate, rather than a value that depends on the = BDP?

If you = don=E2=80=99t want to go down this path for some reason but if I=E2=80=99m= right with this simple idea, then the statement "But since the = calculation would be far from trivial and introducing more complexity, = this is considered to be future research.=E2=80=9D should perhaps be = updated.

6.3 = par 1: remove =E2=80=9Ca=E2=80=9D in "even with a minor packet = reordering=E2=80=9D, and missing =E2=80=9Cthe=E2=80=9D in "=46rom TCP = sender's perspective=E2=80=9D. Also, =E2=80=9Cpersistent receiving=E2=80=9D= =3D> =E2=80=9Cpersistent reception=E2=80=9D.

par2: I have trouble parsing the middle = ("amount of data a reordered=E2=80=A6") of the sentence:
 "If the transmission
  =  rate of the TCP sender, and therefore also the maximum amount of = data
   a reordered segment can be = received too late, changes significantly
  =  during its stay in the 'disorder' state, the actual amount = of
   reordering is not accurately = determined by the relative reordering
  =  extent.=E2=80=9D

below: double =E2=80=9Center=E2=80=9D in "if the amount of = outstanding data is low when entering the 'disorder' state is = entered=E2=80=9D

section 7 par 1: missing =E2=80=9Cthe=E2=80=9D in "Because of = retransmission ambiguity problem=E2=80=A6=E2=80=9D

same par: "the detection = is
   usually conducted by detecting a = closed hole in sequence number space
  =  of the SACK scoreboard.=E2=80=9D  - what do you mean, = =E2=80=9Cusually=E2=80=9D? This is what the algorithm described in this = draft does, right? Or is it also elsewhere? (if so, I suggest to add a = reference)

section 10: broken sentence ("performance measurement tool, = which give us a powerful tool=E2=80=9D)


Cheers,
Michael

= --Apple-Mail=_04BCF53C-BE01-438C-8434-0E190D92703A-- From nobody Wed Feb 25 03:38:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8431A8741 for ; Wed, 25 Feb 2015 03:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 SRt-rnZS_yRR for ; Wed, 25 Feb 2015 03:38:18 -0800 (PST) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id B4B3A1A0451 for ; Wed, 25 Feb 2015 03:38:17 -0800 (PST) Received: from t40700-la020.org.aalto.fi (130.233.145.129) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 54E3C71100EFAC3A; Wed, 25 Feb 2015 13:38:15 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F6E95AD-05DC-4B0D-AAC5-B614E953C6D0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <5969_1424814894_54ECF32E_5969_791_1_EBB91F58-AF7A-4C67-9545-DDA67B919374@ifi.uio.no> Date: Wed, 25 Feb 2015 13:38:13 +0200 Message-Id: <45CACDEC-0CF3-4F7C-80B6-A163144A86C4@iki.fi> References: <5969_1424814894_54ECF32E_5969_791_1_EBB91F58-AF7A-4C67-9545-DDA67B919374@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-zimmermann-tcpm-reordering-detection-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 11:38:20 -0000 --Apple-Mail=_7F6E95AD-05DC-4B0D-AAC5-B614E953C6D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Michael, On 24 Feb 2015, at 23:54, Michael Welzl wrote: > I just read = https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02 >=20 > Since I don=92t fiddle with the TCP recovery code on a daily basis, I = am a member of a large group of people who, in my opinion, can never = make solid claims about the correctness of a mechanism like this one. = All people like me can do is read and comment and hope for the best :-) = because fully understanding this from simply reading, not looking at = code, is REALLY hard. I don=92t blame it on the authors: I appreciate = that making this document easier to read must be very, very difficult. Thanks for the comments! I have had bit similar thoughts than what you = say above. TCP recovery engine with all its performance optimizations = starts to be quite complex already, so it is hard to review various = corner cases or interactions with other algorithms. I=92m sure the = authors have done thorough work in implementing and analysing the = algorithm, but can the rest of us understand it sufficiently well? There = are quite a few steps in the algorithm to be digested. - Pasi --Apple-Mail=_7F6E95AD-05DC-4B0D-AAC5-B614E953C6D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Michael,

On 24 Feb 2015, at 23:54, Michael Welzl = <michawe@ifi.uio.no> = wrote:

I just read https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-de= tection-02

Since I don=92t fiddle with the TCP recovery code on a daily = basis, I am a member of a large group of people who, in my opinion, can = never make solid claims about the correctness of a mechanism like this = one. All people like me can do is read and comment and hope for the best =  :-)    because fully understanding this from simply = reading, not looking at code, is REALLY hard. I don=92t blame it on the = authors: I appreciate that making this document easier to read must be = very, very difficult.

Thanks = for the comments! I have had bit similar thoughts than what you say = above. TCP recovery engine with all its performance optimizations starts = to be quite complex already, so it is hard to review various corner = cases or interactions with other algorithms. I=92m sure the authors have = done thorough work in implementing and analysing the algorithm, but can = the rest of us understand it sufficiently well? There are quite a few = steps in the algorithm to be digested.

- = Pasi

= --Apple-Mail=_7F6E95AD-05DC-4B0D-AAC5-B614E953C6D0--