From carlberg@g11.org.uk Mon May 16 10:59:41 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E746E0799 for ; Mon, 16 May 2011 10:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv+4dLnS-Ztl for ; Mon, 16 May 2011 10:59:40 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id B4751E0798 for ; Mon, 16 May 2011 10:59:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:To:Mime-Version:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=pLZgGbe+7LMCCJamG/jKCiqNYpiF++mhHJvYad67AC5cLCu/50thMhjJSJWxo4BKu6gC6Nwf9u20S5Qr2C3Yp1l7PPtyt0CbT4szjEfi3ZF6AC6GswV/a3pPeGd3S3A3; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51459 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1QM24a-0005YJ-FI for tsvwg@ietf.org; Mon, 16 May 2011 17:59:16 +0000 From: ken carlberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: draft-polk-tsvwg-intserv-multiple-tspec-06 Date: Mon, 16 May 2011 13:59:23 -0400 Message-Id: To: tsvwg Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 17:59:41 -0000 James and Subha, here is a more detailed review of the draft. The following are a = combination of nits, general comments, and questions. You can decide as = to their importance.=20 page 3, 4'th paragraph. In the previous paragraph, you denote the = direction of the ADSPEC as being "downstream". for the sake of = completeness, you should probably denote the direction of the RESV. page 4, 1'st paragraph. Break up the first sentence. it runs waaaaaay = to long with too many thoughts entwined in it. page 4, 5'th paragraph. You should qualify the last sentence to say = that dynamically adapting data streams during reservation set up. page 5. Figure 1. This figure (along with Figure 4 and Figure 6) = repeat information in existing RFCs. I have a preference to have this = information removed and simply refer the reader to the appropriate RFCs. = While it may be helpful when first writing the first multi-tspec draft = for the initial reading (and people reading it at its first presentation = :-), I don't think anything is gained by repeating the information in = future versions of the draft. Shame on the reader for being too lazy to = look up the info. page 5, 1'st paragraph. For the sake of completeness, you may want to = point out that Section 5 deals with security considerations. Section 3. There is no mention of a maximum number of Multi-tspec = entries (you do make mention of this in 4.10, but as an open issue). I = know this has been brought up in previous meetings, and I'd like to = re-advocate the idea of putting a cap on the number of entries. Poorly = developed code, or malicious behavior, could conceivably send tspec in = the hundreds (thousands?), which would seem at the very least to = represent an attack vector for RSVP capable nodes. How about something = like a recommendation of at most 4 entries of the multi_tspec object, = and a max of 10? The thing to note is that if you decide to add a = maximum amount, you'll probably need/want to slightly change the format = of your multi_tspec object. page 14, 3'rd paragraph. You state that "At any router that a = reservation cannot honor a TSPEC, this TSPEC MUST be removed from the = RESV...". Exactly how do you consider removing the TSPEC? Does that = router need to construct a new message without the TSPEC? If so, would = it be simpler to just add a flag indicating that the TSPEC can/cannot be = supported? Section 5. I think that if you allow an unbounded number of tspec = entries, then its difficult (incorrect?) to say that the security = considerations do not exceed what has been written in rfc-2205 and = rfc-2210. General question. Given the recent work on RSVP proxies, do you feel = that a comment needs to be made about the relationship of your = multi-tspec draft and that work? -ken ps, comment to the ADs and co-chair. I'll reiterate again that I feel = this draft, as is (and without responding to the above comments), is = baked enough for it to be added as a working group document.= From gorry@erg.abdn.ac.uk Mon May 16 11:11:06 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B064E0796 for ; Mon, 16 May 2011 11:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbR5AhT-ddle for ; Mon, 16 May 2011 11:11:05 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id BFDAFE06D3 for ; Mon, 16 May 2011 11:11:01 -0700 (PDT) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p4GIAo85009290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 May 2011 19:10:51 +0100 (BST) Message-ID: <4DD168AB.8020109@erg.abdn.ac.uk> Date: Mon, 16 May 2011 19:10:51 +0100 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: draft-polk-tsvwg-intserv-multiple-tspec-06 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: "tsvwg-ads@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:11:06 -0000 Thanks Ken - good to see more comments on this draft. You may be pleased to know that I put the case to our ADs some weeks ago to consider a charter update that would enable the WG to consider such work. I'm expecting them soon to conclude and we can then move forward. Best wishes, Gorry On 16/05/2011 18:59, ken carlberg wrote: > James and Subha, > > here is a more detailed review of the draft. The following are a combination of nits, general comments, and questions. You can decide as to their importance. > > > page 3, 4'th paragraph. In the previous paragraph, you denote the direction of the ADSPEC as being "downstream". for the sake of completeness, you should probably denote the direction of the RESV. > > page 4, 1'st paragraph. Break up the first sentence. it runs waaaaaay to long with too many thoughts entwined in it. > > page 4, 5'th paragraph. You should qualify the last sentence to say that dynamically adapting data streams during reservation set up. > > page 5. Figure 1. This figure (along with Figure 4 and Figure 6) repeat information in existing RFCs. I have a preference to have this information removed and simply refer the reader to the appropriate RFCs. While it may be helpful when first writing the first multi-tspec draft for the initial reading (and people reading it at its first presentation :-), I don't think anything is gained by repeating the information in future versions of the draft. Shame on the reader for being too lazy to look up the info. > > page 5, 1'st paragraph. For the sake of completeness, you may want to point out that Section 5 deals with security considerations. > > Section 3. There is no mention of a maximum number of Multi-tspec entries (you do make mention of this in 4.10, but as an open issue). I know this has been brought up in previous meetings, and I'd like to re-advocate the idea of putting a cap on the number of entries. Poorly developed code, or malicious behavior, could conceivably send tspec in the hundreds (thousands?), which would seem at the very least to represent an attack vector for RSVP capable nodes. How about something like a recommendation of at most 4 entries of the multi_tspec object, and a max of 10? The thing to note is that if you decide to add a maximum amount, you'll probably need/want to slightly change the format of your multi_tspec object. > > page 14, 3'rd paragraph. You state that "At any router that a reservation cannot honor a TSPEC, this TSPEC MUST be removed from the RESV...". Exactly how do you consider removing the TSPEC? Does that router need to construct a new message without the TSPEC? If so, would it be simpler to just add a flag indicating that the TSPEC can/cannot be supported? > > Section 5. I think that if you allow an unbounded number of tspec entries, then its difficult (incorrect?) to say that the security considerations do not exceed what has been written in rfc-2205 and rfc-2210. > > General question. Given the recent work on RSVP proxies, do you feel that a comment needs to be made about the relationship of your multi-tspec draft and that work? > > -ken > > ps, comment to the ADs and co-chair. I'll reiterate again that I feel this draft, as is (and without responding to the above comments), is baked enough for it to be added as a working group document. > > From padman.m@gmail.com Mon May 23 03:47:10 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549F1E076D for ; Mon, 23 May 2011 03:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_IMAGE_SPAM_TEXT=0.001, DC_PNG_UNO_LARGO=0.558, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4Y3poPVQrqA for ; Mon, 23 May 2011 03:47:09 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 80AD2E06E0 for ; Mon, 23 May 2011 03:47:09 -0700 (PDT) Received: by qyk7 with SMTP id 7so3699817qyk.10 for ; Mon, 23 May 2011 03:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=jUxRn8ycRHumRuTrKtfovpg21aAUVTSIB752R5vyQU0=; b=MusD0SCfw7vVkh6yuzybr2o0VsUPWtlRsMa9AZ3x8XqRZdddY/X7Z4QyBNnmxPybLk nwjI6BXRlF0nFkU1mnwrl1WBBXf2ivu3dvodjASxuZJ/ACDiGeZNcNZmPF0jwQli+vMZ H/SNxChYBjD9fzbMdytSuF5hEhqH5SaSpIcXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DB5YTUm7inKtvISqJlrYgpkg3YYPzdIl54RQswgxyehszI82/ih9PRIMTLZPZR/pxW o/E2u77By4+PaI5AricGOgUV1khftVL4DttFU1gp291vE9V2TqiQzPP7vmjSIPkkuAsv 0ZBOeXQR/ZRFH0INA9ajgzUvU6YDbadJu6JQc= MIME-Version: 1.0 Received: by 10.229.88.198 with SMTP id b6mr1544464qcm.208.1306147628038; Mon, 23 May 2011 03:47:08 -0700 (PDT) Received: by 10.229.191.140 with HTTP; Mon, 23 May 2011 03:47:07 -0700 (PDT) Date: Mon, 23 May 2011 16:17:07 +0530 Message-ID: Subject: Regarding Cumulative TSN Ack in the SACK after peer re-start From: Padmalochan Moharana To: lksctp-developers , Vlad Yasevich , tsvwg Content-Type: multipart/mixed; boundary=001636284dea64bad504a3ef3183 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 10:47:10 -0000 --001636284dea64bad504a3ef3183 Content-Type: multipart/alternative; boundary=001636284dea64bacd04a3ef3181 --001636284dea64bacd04a3ef3181 Content-Type: text/plain; charset=ISO-8859-1 Hi , I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer. what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before peer re-started. Please find the call flow for the scenario for more information. Thanks, Padmalochan --001636284dea64bacd04a3ef3181 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi ,

I have a doubt regarding the value of the "Cumulative TSN = Ack" in the SACK message after restart of the peer.

what should= be the value of the "Cumulative TSN Ack" in SACK message for the= DATA message received before

peer re-started.

Please find the call flow for the scenario for = more information.


Thanks,
Padmalochan
--001636284dea64bacd04a3ef3181-- --001636284dea64bad504a3ef3183 Content-Type: image/png; name="Screenshot-1.png" Content-Disposition: attachment; filename="Screenshot-1.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_go1ak3r30 iVBORw0KGgoAAAANSUhEUgAAAsIAAAGYCAIAAADHjROCAAAAA3NCSVQICAjb4U/gAAAAGXRFWHRT b2Z0d2FyZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAIABJREFUeJzs3WdcFEcfB/D/Hkc5EKSJeEtR REUBpUvTAJaILXZEwSRG0SixJHaxP0YxVjDGHgsRsCFqVIxiL7GBXSzBgkhRlHbAccc+L0AEhQNO FJDf98MLndnZnVu4vd/Nzu4yHMcRAAAAQNXxa7oDnxzDMDXdhboBgRKg/sCBsZJwYKzQlx8jiGjd FfwdVGCUHY4pAPULDowVwoGxMng13QEAAACoqxAjAAAAQE6IEQAAACAnxAgAAACQE2IEAAAAyAkx AgAAAOSEGAEAAAByQowAAAAAOdWL20+VT/QsuP3mf9I+rNDoc+Sn4ZZV2TvSjCM9Vm4x/fbP1caC nIQ1TpuOpJasVtRr33bggi5dzJVlJLecs7u+83r9/eUR3YQy85047eSamxJP586tFMvtTsKVKe3/ fkDqvf4eN9Kqnv+aAaDSvrijYsGLq5PsDj4sWaSg2szTaeSvzhY6+Cb98fD5QsSzdBzho1tqTygI mht87J8Xr43jD9/qKhIRFYgex/+z/urv/bJUzwzqoFfumhU0GrVxEmgrVXTjtLy0UytO5TR36NRK sZxFC15GXX1ARJR5dlfyMCtWWc4XAQD10Zd3VNTq5eHtqkpETEH+m7txf287PuuF0h97HfTxIfix sAeJVEzNOvkYC6p7tcomLTv7NHu7WrvO7feM+u72vn+yXIZqlPeOUWrrNmd3dWxb8uZiaBJj5TFc /dSmQ7HxAaxZtb88APhyfXlHRU1Hyy4+mgpvN+3QcM344JiYZDtPFgMSHwkxQqa8mEN+fZK+O+D4 aO6Rg/9mFihpWo3qPnFSCy0+ERW8OXdu7ezz5+/lkrqe89gOJlIZa2LUrVoa0u3UuEwJqXOPbofM jD565nUO8XUd2g2a36WrpTKPKOfC3u8Hvvzu0ohuQl55m9Z4dm6867GnRDR6yTd/9PrzgI2Owvsb kz69+89dnvkqq68ET7f53Tt+u4uZndIn20kAUI/U0aNiaTzVxspEfEU+npnx8ZDDiLg8Ucar7PSS P6/zpMUPrZGk7PKLTu7YZVbooB96MbHBe9adzuWI8u+dmzMo+qLEdOjSfhN/MU77fU/IHVkPupGk pLwmUtZSotR7q3rviXzYqFfggKnLO7Z5dW1Nn53HEgrKbPPhpnmGtnOierbhkcncEWs3mWuW8W6R vjgY+1Sxqadbg4ZONm2Vsy6GJ+V+/G4CgHrjizsqkjQrp+gVpaY/PXVxw/Ikzb6udrqIER8PoxFE OYd2jjxUukjQen7sIKsGhf/Jk/T9bvIEfSUiW2vl+0e3x9/KknowN1eci9doM2NPP0ddhsjC0UZh bO+LohLrkOaIXqdk5RIRVyB68l/ktPPJpD2oq0Zq+K6z6ezIQ169jHlE5OTWMNMpImxzsvvsJh90 rcxN6zYybijgMaSv3aSJchlvgvxXZ3a+VHbrZKXDMGTcxYV/9Ujsw7lGFmrVtcMA4Av3pR0ViZ4u Wv/tohL/12o9YVLzMgMHVBFiBJGiY+dJ/o1LDvozyuqm784Kqjt00y2qVVRuqMpwRJT3+kZMnlpn +3ZFYZYRWLR1ZS8eLbES8fHdo61LbqdB+4VeA1tLL89+SZY9nN9OVuLpmX5tx1t87vkbaZMG73et rE1XJP/RrRPxiu2mC/kicQ4pNO9jxI++d+zG1xZOmGcJAJXyhR0ViUjPt8/or9UYIiJOmvHqyu/H VnYNzz/m/bURxuQ/EmIEkWITAyt3GZOJlNQFH6RbaV66iNQNVd/tPwVBY81SiyjYuE8ar1/4584o KOtZGhjqKjDSN+mZnIKehqA4BTN8jSZK9DxLJKUP3jBlbboCkoS9N5MoP8lvhVeJ0kthiTlOzTDP EgAq48s6KhIRqZkZW7sXjz60sLNTfNz+YPiWZI/ZTcq9bh4qBTGiMj78o+WraKtT5lORhKjoT1Ca k/Km1CJKQkObzh98cvOUNNQZ6auMHCmpFv5Fc9KMZDGpqaqUmYmr+n7JTYmOeMOz9pgx01C1qEh8 Z2F4yNGY+5nN2qlXcW0AAGWqQ0fFsvB0mjTXo0fx2fnFvQU5YThHPkqabW2Us49din1ZOKLG5dy4 fvp5JRoyKibuunTz2vm3s4cKku5HXSrQcTbQqo5IJ753/Uwiz2KEtZ1TU4uinxZdhhspZNw/GpNX DRsAAChTbT0qlkn64umdZNJprYEM8dEwGkGU+/De8ZCXpfcET8O6taO5SvmNlNv85GISGR3Yb4+X X0u97GdHVlwTKVMl5uvwmni5u6zZuaF/ePp4S2P+qwurT8XwTH4aoa9ElFP5TjPcywuPbps0bWXe oMTbQPxf2J00vtH3zmol8iHT0MXajPf46o5n2R1NMc8SACr0BR0Vi7y5ePMfftEQLZeddnXz+Xi+ 0WgvXcSIj4YYQVRw8+L6qe8XNvmZtZf1hiFFM5e54bR21vnQqbdJoOM40bvP9T2/V2JzvEZm4yP7 as04sW/aHjEp6NjbjF3fpVOVbg8n0PPoofnb1j2z7vfdvLOtVnFTUdKxQ1k8+y5tS1/FxNNt1smG CTpx7V5Gc1sNXOAEABX4co6Kb70+EL3mwLv/qrZsPSysZzdjDMh/PIbjKjnPta5iGGbdlS/8NX68 UXZf/l8CABTDgbEycGCsDIxGkJ9d0ffz9aXfVHWlHACgetW2oxyOirVZfY8RfnZM8d9fXf83AMDH qw1HMxwV65Avf8RGxtjdh39ttS1Tf7YMjrE7gHqlvAMjjool4cBYGV/+PsIpwMrAuwWgXsGBsTJw YKwMTFMFAAAAOSFGAAAAgJwQIwAAAEBOiBE1bNTbaUEAAFAmHCdrM8QIAAAAkNOXPw2VYRBjK+WL /0sAgGI4MFYSDowV+vJjRC3HMPgVAADIguNkbYaTGlBPiC6Ob8OW0qJ9nwnrzqdI3ltQkrCtB8uy rO3s2Nyiosx/vAzZcjj/dk9cdqvycZkXZnX1DkmQkDh+78rlYXFVeIphVXDZ93YFDHQyZVmWbdXB d3FUgrgSteL7Qb16/HbzE/UJAL4s9f1m2FC/8K1GzfE2USIiSVbi7eidO+YPPHl97ZGgXvrF7wRJ YtRfsURESQd23Z1uZS0gIoH5mOVLeuVxRCRNPLRo1SmdYfN+LHzUIV/Lqgm/7FblEsdtnH3cesFU Az5lxkesWJ7V/HuvVoJqH2OWPAsd0XPyGf2eEwOnNpPe2RccPLx/9t5j89urMzJrlUx9/IXdZocN 2vW9MQ4QAFABDmoUfgWfS/aFca2FbcZfzH5XVJB1Y5WnodBs9PHXBW/L8uPXdRKy3Vet82oqtJp2 RfT+avLuLHYUGgw6mlGqtKJWJRW8Pj6qneviO3kcx3EZx32M2D770wpktZBPTsxsG2Fzn4hkSVEf n4X0MzbqtytJUnFt1r+Tbe2nXc4ue80AnxmOk7UZTmpA/cWoWY6YP1Qv49CGs2lF510lTw+F3eU7 fj+or6+LUsrhnbdFlVlRVVoVvDy1/mSD3t80V5LEr3E3842WcJdGWxh035EkJZK+vrTe39PamGVZ 1sShf0BEfC4RUU7MDGvjPrtv/D23n40Ry7LNHL0XR39wNqY0LvPhtSRq8XV7HYXCAr7+V71aSmIO 3BJVWEtqFgM9JAc3XcqszKsHgPoMMQLqNVUzT3s1yZ0zhR/XlP/4YHicovMwNz1dpyGuyqmHw29V IkdUpRWXfnnXNYGLu7ES8Q19QqICHXhkMffg2U29dBUKUv4eN2TeYQXPgOD1a5f4md7703/k5kf5 hQ0l94L9Fj/tOGtr6Ma5vXing38MOJ0ua84Zo6ypqUQvH6bkvy0Rv7iXSnnP49MkFdUSqZp1s84/ s+dmVsWvHgDqNcQIqN8UdZtp0+snryVERPn/7d/5UOD2bQcdHqPl6O2i/OpI+I3silZRpVa5D0/c FJu4NFMhIr4GayxswGNU9Zs2baLOp9zHJ2NyhN8umjOyX49eQyevDB4/yIafKy1qmZnfd+2aCX3d O3qOXLi4t3pW3K1UmeMRDWx8u6onbvp5YeStpDevnlzYMnns9hSivKw8rsJaIoGpi2Hm1TPPxLI2 AQCAGAHwlvjRvt3xAteBbRVF2dkiRcs+DoppUWE3KvhGXqVWBRmP7rzWNGVVy5pQqcTateQnbpky 84/IC3GpEl2PKSuW+BXO5CQi/S7dmhf9W1FDV5XhiIhyY2fZlXX9iM2Ma3nanQO3TnZO3Tzma1vz ts4DApO7j2pDpKDIZ4iIJ7OWiK9lYqiYGPsU12sAgEyYiA31W/7L+DTS7KjFJ8p7sDfiCeU88bNv VWKBo2HXs5xcGpS7gqq1kqa/SCe1RmoKZa2Kz3ptipAuXbY5eEzo/4hUm7n5TF4wpbdJ4WUfqlqC D1spm/0UfnyI+P2zG4yitrEK8QTtJ4RfG/703v0kiaZJm6Y5f3XfQBr66oWr4WnKqiW+eiM1aWxy lpQaltlZAAAixAio50T3jlzO5rfp2EyFcm/ujnimYD1100z7tx//2ZcXDg88GhqT6dJBvZwV5MZV qRXHFci6i46Clo3vwr98/ydJfxJ75uDG/y0a46NkemK6SWFtGSMYjIpeczO9MtfF5STExjwXmNu1 srAzIiLKPHH+Mel7m6ozhbXXy68FAKgknNSA+ovLvrVxdkiKuucIF20m996uyES+4wjvTk7FPAYP b8/POBYaU+4VC1VtxW8o1GSyUrOlH1aRNGnX4LZWvpGpBQy/YVO7nqNnjGxNCdefy5qeIOOkRk7O jd+G9Pt+bVweERFJXhxZfzy7sec3LQvPjMiuJZJkpmYraDdugKEIAJAFoxFQn2Q9iAoLeaBERNKc 5DvR4SGnn+v2/mOumxYjuhp2MJnvMMtZp0S05um6eNnyzkfvuJrR0U2jjPWJblexFU/DtLVm+sME EWf79n5TDJd44dRFE2dbc21LO83UFVNGBCT5OAkp8fy2pXf59oFtZN3KSsZJDYFWi7FeegODho1R mOjZJOX4H8tOK3X73b9d4eoYrQ4yaokkr/97li/sbCTzPloAAIgRUJ9IYtfNin37H+UmNv1nLpvp 16Exn0TXwg6lKNgHuOiWGqDj6boOsmF+ObHjSsZXHhofDPeLblW5lcDUw1Jp5vn43G90BEQkaD2g h8GYrWMH3191eeeAVv5bgt9MWRI2f8JWIsXGVr3n7JzrbcCn8uc5yjipQUROc3eu5CYsWDHlCKkY uY74fevUb/Tfji4w6rJqKefhuWfqth0MlcrdNAAA4dFcNQ6PnKlvClL3eXf4zXbfiSlmtfgjWnR5 quvw9OXn1pY5CAPweeE4WZthbgTAZ8XTdRvZMetA5KN3Ux4YpujnPVUtrz7Zt3ZH83v8YI8MAQAV QIwA+LwYzQ4TfZUit1wrvLMEwxDHFf2UTAZVLa9G3OtzG08IR/9orfZJVg8AXxLECIDPTdnMb4Hb tZX7EooyQbHCZFD4U8nyT0D8IGT18wELvPF4TwCoGE441TCc8wMAkA3HydoMoxEAAAAgJ8QIAAAA kBNiBAAAAMgJMQIAAADkhBgBAAAAckKMAAAAADnhynAAAKhJzNsbqeGqzroIMQIAAGoF5Im6CDEC AABqF+SJOgQxouYxn/IZSwAAdRcOj7UfYkTNQ9wGgPpMRlYoPDwiTNRmiBEAAFC74MtVHYIYAQAA tQLSQ12EGAEAADUJ6aFOw+2nAAAAQE6IEQAAACAnxAgAAACQE2IEAAAAyAkxAgAAAOSEGAEAAABy QowAAAAAOSFGAAAAgJwQIwAAAEBOiBEAAAAgJ8QIAAAAkBNiBNRdeQnRQf69Hc0MWJZljcw7DJy8 8UKq5P2lJAnberAsy9rOjs19v+rlv39O83azNGZZlmVb2PccGxT9XPy2VvoixJNlu25JKLFKSUrU ZEeWtRgR/lhMH+IyL8zq6h2S8EEnyiOO37tyeVhcTmWX/yhc9r1dAQOdTFmWZVt18F0clSCuqEp8 P6hXj99ufp7+AUAdhBgBdZQ09fBET9/AfyTtRyxYuTp4acCQNq92zxnQa+6FjFKP+ZEkRv0VS0SU dGDX3ZIfh5LnEWM79Qv46zHbY9ychQsCxvU1fbk/0LfbuIPJ0nI2+erU/AHDd6R7LI5c7dVU6cMF xHEbZx+3Ht/HoNKPvMuLj1ixPPx+7md4MpHkWeiInhO2vGj7Y+Dvwb9+2+xu8PD+C/7N5GRWKZn6 +At3zQ57UulgBAD1DAc1Cr8COeU/2dRFKHRdeif3XVl27K9OQoM+u5KlJZaLX9dJyHZftc6rqdBq 2hVRcfnzsEFNhS2GbHuQ825h0Z2grkKh1fQr2RzHcZLE7d2Ewi5/PsvnOI6Tvrn4a2cDYYvBG++K CsrsUsHr46PauS6+k1eFl5Fx3MeI7bM/rew1VqecmNk2wuY+EcmSwv/nPwvpZ2zUb1eSRFYVx3FZ /062tZ92OfuT9xCgPDhO1mYYjYC6SfrmaRrxWTP9EoMCqm28f/bzbi/ILygukjw9FHaX7/j9oL6+ Lkoph3feFhWWix+FBp0VW81c7G2q8m4FAjPfaT42jZNvJuWX3hqXGRvs47X6P4eAvRuHmwmYsnpU 8PLU+pMNen/TvLhHXHbc7pn9HZqxLGtg0ckv6ExKqe/0kvg17ma+0RLu0mgLg+47kqRE0teX1vt7 WhuzLMuaOPQPiIjPJSLKiZlhbdxn942/5/azMWJZtpmj9+LolCoNEHCZD68lUYuv2+soFBbw9b/q 1VISc+CWSEYVEZGaxUAPycFNlzKrsjkAqC8QI6BuUjJytVWXnJk2dknE1efZRblBsemAOUum9WCL zynkPz4YHqfoPMxNT9dpiKty6uHwwo9GacqFqMdkMaiTsPTpB0bTPfDAkU3fmSiWKCzIubth+IAl N8wn79ky2kKtzAxBxKVf3nVN4OJu/DZFSJP3j/tmfMgblymr1v8+v5/GqUDvYRselsgnfEOfkKhA Bx5ZzD14dlMvXYWClL/HDZl3WMEzIHj92iV+pvf+9B+5+VFRC8m9YL/FTzvO2hq6cW4v3ungHwNO p1fhVAijrKmpRC8fphR3QPziXirlPY9Pk5ZfJSEiUjXrZp1/Zs/NrMpvDQDqjUqfwwWoVRhN98Dt s7gpy4L8eweRYpO2Hd3c3D2+7t65XWOl4g/6/P/273wocJveQYfHkKO3i3L0kfAbcx0c1cSp91NJ 1d5EU6HCDeU+DBkV+Pv5HCJRvgK/nAxBRLkPT9wUmwxq9nZwQ3x/y+Ij0s5rQ5f10uMRde+o/8Rh 5M6jz0aamrx91/E1WGNhAx5D+k2bNlFnSPT4ZEyO8NtFc0ZaKhN1a9+Et+gIP/ftRI3M/L571kww VyFyt1a7dtT7zq1UiUdDxTK6UqYGNr5d1b/f9PNC61Vjv2qSd/fAkvHbU4gaZOVxMqqIiEhg6mKY ufHMM7Fz6zImhABAvYbRCKirFDTtR68/EffgypHtyyf1aCb6d3PAyB427YdvLb7uQfxo3+54gevA toqi7GyRomUfB8W0qLAbWURUUMARV1Aga/1FHv35e2z7wAN/euvdX/lT0A1ROYsVZDy681rTlFUt ChrSlEvRT/l2gzs0KnyPMdpfr716M+I7IxnJXYm1a8lP3DJl5h+RF+JSJboeU1Ys8TN/m0v0u3Rr XvRvRQ1dVaasoYjc2Fl2bBlsZlzL0+4cuHWyc+rmMV/bmrd1HhCY3H1UGyIFRT7DK7+KiIj4WiaG iomxT3G9BgB8AKMRUDdJxaJcqaJAoKjaxNLDy9LDy3+eJO3K+h+9F874eadH5LeGfMp7sDfiCeU8 8bNvVaLh0bDrWU7tdZvrUM6TR2mSrxqUeg8UvPl33bIDkq4TxnTQLSwRuC7Yt9anpVLPVUOOewf5 B319ZKqV6oeDEtL0F+mk1kjt7fCGNDMpkzQsdN4NjSgIGmoLZL4mPuu1KUK6dNnm4DGh/yNSbebm M3nBlN4mha1UtQQVjp0om/0UfnyI+P2EwShqG6sQT9B+Qvi14U/v3U+SaJq0aZrzV/cNpKGvrkDE aJZbRUTEV2+kJo1NzpJSw4qHbwCgXsFoBNRJuTcXuLZ0mH6l5OAAX9vuu4ndG9Kjywl5RJQbtzvi mYL11C27i22daq2QfjQ0JpOv7+RhQHfCjjwrPU+Ry7y2ccXm0KtipeKPSxPPriYqRDxN15mrhug9 CvZfeT27jIEAjivgShbzVLUFlJWSXrx+Lu9FzJnzd9+UczFpIQUtG9+Ff524/eTOuch14y0erR/j s/JO3tva8s+oFC+hotfcrPUHzEwbCygnIfb8v3HZakYWdg5WprpKOQ/PPyZ9a1N1hiu/qsItAkA9 hxgBdZKykZO5ctrBPw4/L5EDONH9E5fTybCdUJko996uyES+4wjvTk7FPAYPb8/POBYak6ls5jvW nn970cT1N7O4d+1vb1l8KLtBp6E26h9ukqfpGhA0VC/+97ErYrI+CBL8hkJNJis1+21K4De2d2os vrzz3MvCMydc+tm53oN/2f+i/BghTdo1uK2Vb2RqAcNv2NSu5+gZI1tTwvXnZd3nqhwyTmrk5Nz4 bUi/79fGFaYSyYsj649nN/b8pqUKkYyqwpLM1GwF7cYNMBQBAO/DSQ2okxjtTrOnO3WbO87dM2pI T3sTHaW81AfnIrb/80TfO2SAIZ9E18MOJvMdZjnrlIjKPF0XL1ve+egdVzM6unkH/Xa6+8SF3Vz/ GejVpW0TxTdxp3ZtP/FUvdPyWe5aZX4N5zV0mRk09J/Bf/gv63Z0tl2DkgvxNExba6Y/TBBxtoXX g6pY+P3ssmPq6MG/TPZzZ7Ovblt8MNtqzkDTDyYpMlzihVMXTZxtzbUt7TRTV0wZEZDk4ySkxPPb lt7l2we2kX0mpBQZJzUEWi3GeukNDBo2RmGiZ5OU438sO63U7Xf/dgIi0upQbhURkeT1f8/yhZ2N qtARAKg3avrGFfUdfgXyK8h5HLViTK/2LYVCoVAoNLL8ymvKhvPJ+RzHcdn/TrIUGvbfXfJOVBzH cZIXob1ZYcuRx9MLOI7LTzrzx4S+Tq0KV2Bq32PMymPPiu9nVfr2U0Wkb05PthIKHedcyih9y6iC tL+HtLCacllUYtmM2C0TurczFAqFQjO3H1aeScnn3pOfuG+Mg1AoNOq/K1nKFeQ82jOzf/vmQqFQ KDS27v7TuouvJBzHia5NtxK6rrgvLmqVExNgzXZY9UD8/uoq2GGi+zsnd7cUCoVCE8dBcyIevruP lowqjss4PryVuf+5zKptDaDa4DhZmzEc9xluwwvlYhj8Cr4QBan7vDv8ZrvvxBSzL+uySNHlqa7D 05efW+umUdNdgXoKx8naDHMjAKoHT9dtZMesA5GPqjCXoRDDFP18ZPmnkX1rdzS/xw/2yBAAUAbE CIBqwmh2mOirFLnlWpVu98gwxHFFPyWTQVXLPxHu9bmNJ4Sjf7RW++SbAoC6CDECoNoom/ktcLu2 cl+lHxRemAmKFSaDwp9Kln9i4gchq58PWOBtjMnYAFAmnHCqYTjnBwAgG46TtRlGIwAAAEBOiBEA AAAgJ8QIAAAAkBNiRO3FMAzzuS7qAwAAkAPmX9c6iA4AAFBXIEbUFkgPAABQ5yBG1DzZAQLxAgAA ai3EiJpXeD10eXEBV0sDQD2Hb1O1GWJEbVEcF/CGAQCAugJXatQ6xU9fremOAAB8SUSXJ1myZbGf fzOvaJm8hOgg/96OZgYsy7JG5h0GTt54IVVClPmPl2GZbVmWdf7tXtED+SQJ23qwLMvazo7NLbll 6YsQz/caGVl2GbX6witp4QIFKeE9WLbThidl3Ehfmri9G8t6rH0skdnDQhmHB7Csy7K40k8IzL0x 145t9u2JzMrtB9HF8W1K17Ro32fCuvMpZd7mH6MRtReSBABANVOwHDnXx1SpVJGmhQGfiEiaenii 54hIcbsBIxf80ryhJPXuybCNcwacebz76BzzMcuX9MrjiEiaeGjRqlM6w+b9aK5CRMTXsmpS+FEq SYz6K5aIKOnArrvTrawFpTet12vaz65aDBEV5Ly8e/TPbYsGv1A9vXd4FR5ZI6OHC5w0qjKSLWs/ EBER32rUHG8TJSKSZCXejt65Y/7Ak9fXHgnqpf9edxEjAACg3lA1/drLx6nMJ9ZKnh9YEZlm8vOx iF9aKxcWefv0XNS5+5olR8ftGTBwaGGZ+O7ztavOGHh4+XRRL90+4UjoLcZq6mz1FfMO7bwTYG1b Okc0cuzr7VP8QT2sS0O3rsHhp5K/HcYqVLLzFfRQrwrnF2Tsh0INWnw92Ke9atH/Ro0dFjywR+CU eQM6rPHQLJVXcFIDAACASPrmaRrxWTP9Et/RVdt4/+zn3V6QX1Bhc8nTQ2F3+Y7fD+rr66KUcnjn bZHMxRU0GqsTKSnzqzCG8JE9/AiMmuWI+UP1Mg5tOJv23jg5RiMAAKDe4PLepL16VWrmAk+5oWYD PkNKRq626hsOThu7RPyLT1drVo1HRIpNB8xZUpkV5z8+GB6n6PyHm54ub4ir8sjD4bfm2DmollhC kvU67ZVAgYgKcl/eObBo+W3dvps9dKvwbb6SPZRmv0l79UrxXUHemxxp5fdDOVTNPO3Vtv17Jj63 p07JYRbECAAAqDeyDo1wPFS6SOAZGruxYwNiNN0Dt8/ipiwL8u8dRIpN2nZ0c3P3+Lp753aNlSoc Msj/b//OhwK36R10eAw5ersoRx8JvzHXwbHEaYO4Rd2sF5VootV95SS3RpU9oUFEle3hs3X9bNd9 0LjUPAhZ+6E8irrNtOnIk9fvTbREjAAAgHpDyXHGGv82KiVKGGX9tkXfrhU07UevP+EnenH74ulT p06djN4cEBoUoNf117A137YSlLm+IuJH+3bHC1ynt1UUZWeTomUfB8XoqLAb8xyd3n0sG/iu/PXr wsEHTpLx37Hf/zeh63Dxsa1DjSpa0F3TAAAgAElEQVT/SVypHmr3/HXZYKMSoxH5/20bP/tk5fdD lSBGAABAvaHcxKaje9lTC6ViUa5UUSBQVG1i6eFl6eHlP0+SdmX9j94LZ/y80yPyW8PyPzDzHuyN eEI5T/zsW5UoPRp2PcvJpThHNDRz+sq9eIqlh4ed4G77KSu33B0w21KRKqWSPWxg4uDm3rrE6EOu zqn3X7GM/VCe/JfxaaTZUeu93YAplgAAAJR7c4FrS4fpV0rOjORr2303sXtDenQ5Ia/chkS5cbsj nilYT92yu9jWqdYK6UdDYzLLbaSgY95Wj17FvxKXu0j19bAaiO4duZzNb9OxmUrpcsQIAAAAUjZy MldOO/jH4eclTv5zovsnLqeTYTuhcvktc+/tikzkO47w7uRUzGPw8Pb8jGMycoTkxaVLyaTfWl/G mqurhx+Ny761cXZIirrnCBft9+aJ4KQGAADUG6KHUeEhj0pPN+RrW3fvZq6h3Wn2dKduc8e5e0YN 6WlvoqOUl/rgXMT2f57oe4cMkHFGQ3Q77GAy32GWs06JL+Y8XRcvW9756B1XMzq6FZ47SL0YEcrX KvwQLsh+fGLzH7f5Dr96mSoRFV6s+fJy5A6B9ruVKDS0+Lq7VcPi/zPy9rBq+6GwA1kPosJCHigR kTQn+U50eMjp57q9/5jrpvX+bFPECAAAqDekNzfMmvp+YdOfrTubaygptxgREm28dsnqsNAlf2cR EV+nhdPgeYG/fOekVf7QvehW2KEUBfsAl9KXbvJ0XQfZML+c2HEl46uviIgo5cDiaQfeLaDesvv0 sECfEvewfPl34PS/S66j8fDWXawsSxTI18OyyNoPREQkiV03K7Z4u01s+s9cNtOvQ+MPQwODOy7X LIbBrwAAQBYcJ2szzI0AAAAAOSFGAAAAgJwQIwAAAEBOiBEAAAAgJ8QIAAAAkBNiBAAAAMgJMQIA AADkhBgBAAAAckKMAAAAADkhRgAAAICcECMAAABATogRAAAAICfECAAAAJATYgQAAADICTECAAAA 5IQYAQAAAHJCjAAAAAA5IUYAAACAnBAjAAAAQE6IEQAAACAnxAgAAACQE2IEAAAAyAkxAgAAAOSE GAEAAAByQowAAAAAOSFGQD0huji+DVtKi/Z9Jqw7nyJ5b0FJwrYeLMuytrNjc4uKMv/xMmTL4fzb PXHZrcrHZV6Y1dU7JEFC4vi9K5eHxeVU96stLff6XCeHaddKbaUg8+a2iT3aGbIs28LVd0l0kqSi KvH9oF49frv5ifsKAHULv6Y7APAZ8a1GzfE2USIiSVbi7eidO+YPPHl97ZGgXvrF7wRJYtRfsURE SQd23Z1uZS0gIoH5mOVLeuVxRCRNPLRo1SmdYfN+NFchIuJrWTXhl92qXOK4jbOPWy+YasCnzPiI Fcuzmn/v1UrAfKoXnfc4clnoU3HfkmXS5Ej//tNPsAOmLHVRjQv/bZWvN3P08GRzFRlVSqY+/sJu s8MG7freGAcOACjCQY3Cr+Bzyb4wrrWwzfiL2e+KCrJurPI0FJqNPv664G1Zfvy6TkK2+6p1Xk2F VtOuiN5fTd6dxY5Cg0FHM0qVVtSqpILXx0e1c118J4/jOC7juI8R22d/WoGsFvIqyPg38FvP9s2F QqFQ2G7q1Xfdyrv7m7PQqN+O55LC5c7+0lbY4odjbwpkVnFc1r+Tbe2nXc4uc3MAnwqOk7UZTmpA /cWoWY6YP1Qv49CGs2lcYZHk6aGwu3zH7wf19XVRSjm887aoMiuqSquCl6fWn2zQ+5vmSpL4Ne5m vtES7tJoC4PuO5KkRNLXl9b7e1obsyzLmjj0D4iIzyUiyomZYW3cZ/eNv+f2szFiWbaZo/fi6A/O xnz4+hQ0Wzh2GzLuZx8r5dL9TT4f9ZixGdpZX4GIiFG3HtRFO/vSkfu5sqqISM1ioIfk4KZLmZXZ KwBQHyBGQL2mauZprya5c6bw45ryHx8Mj1N0Huamp+s0xFU59XD4rUrkiKq04tIv77omcHE3ViK+ oU9IVKADjyzmHjy7qZeuQkHK3+OGzDus4BkQvH7tEj/Te3/6j9z8KL+woeResN/ipx1nbQ3dOLcX 73TwjwGn07mKXl3LvqPHjRs3doidVqlyceLNF9TI3ET97ftf2cDKgF7FPcvmZFQV7q9u1vln9tzM qnivAEC9gBgB9ZuibjNtev3ktYSIKP+//TsfCty+7aDDY7QcvV2UXx0Jv5Fd0Sqq1Cr34YmbYhOX ZipExNdgjYUNeIyqftOmTdT5lPv4ZEyO8NtFc0b269Fr6OSVweMH2fBzpUUtM/P7rl0zoa97R8+R Cxf3Vs+Ku5Va4XhEOaTZr7Koga6qwtsCBTVtNSLRq2ypjCoiIhKYuhhmXj3zTCznpgHgC4MYAfCW +NG+3fEC14FtFUXZ2SJFyz4OimlRYTcq+OZdpVYFGY/uvNY0ZVXLmlCpxNq15CdumTLzj8gLcakS XY8pK5b4Fc7kJCL9Lt2aF/1bUUNXleGIiHJjZ9mVdf2IzYxrFV9R8X4fuEpU8bVMDBUTY5/ieg0A ICJcqQH1Xf7L+DTS7KjFJ8p7sDfiCeU88bNvVWKBo2HXs5xcGpS7gqq1kqa/SCe1RmoKH9QQEZ/1 2hQhXbpsc/CY0P8RqTZz85m8YEpvk8LLPlS1BB+2Ujb7Kfz4EPH7ZzcYRW1jlQ8WLqagpqNGt9Oy pUSKhd0SpWUTqWmrKsioKuqkeiM1aWxylpQalvkiAKB+QYyAek1078jlbH6bjs1UKPfm7ohnCtZT N820f/vxn3154fDAo6ExmS4d1MtZQW5clVpxXAEnY0aDgpaN78K/fP8nSX8Se+bgxv8tGuOjZHpi uklhbRkjGIyKXnMzvUq/3CJKTSyFtPvO02zOSoUhKposoft10waMjKqqbgUA6gOc1ID6i8u+tXF2 SIq65wgXbSb33q7IRL7jCO9OTsU8Bg9vz884FhpT7pUJVW3FbyjUZLJSs6UfVpE0adfgtla+kakF DL9hU7ueo2eMbE0J15/LmoYg30kNvr5zV+OCmJ3nUguIiEh0b//xVHUnzxYCWVWFJJmp2QrajRtg KAIAiDAaAfVL1oOosJAHSkQkzUm+Ex0ecvq5bu8/5rppMaKrYQeT+Q6znHVKRGuerouXLe989I6r GR3dNMpYn+h2FVvxNExba6Y/TBBxtm/vN8VwiRdOXTRxtjXXtrTTTF0xZURAko+TkBLPb1t6l28f 2EbWrazkO6lBSi18J3Xe8NOkHwPzf3JVubt9zsak1pMnOGnIriIikrz+71m+sLORzPtrAUD9gRgB 9Ykkdt2s2Lf/UW5i03/mspl+HRrzSXQt7FCKgn2Ai26pATqerusgG+aXEzuuZHzlofHBsL7oVpVb CUw9LJVmno/P/UZHQESC1gN6GIzZOnbw/VWXdw5o5b8l+M2UJWHzJ2wlUmxs1XvOzrneBnwqf2BB vpMaRAr6fYJ3vp4xefm4oatJxdhj/Lal/mbKFVURUc7Dc8/UbTsYKlV9mwDwJWI4WWdq4ZNjGPwK 6peC1H3eHX6z3Xdiilkd/CgWXZ7qOjx9+bm1ZQ7OAHwaOE7WZpgbAfBZ8XTdRnbMOhD56N2UB4Yp +nlPVcs/vexbu6P5PX6wR4YAgCKIEQCfF6PZYaKvUuSWa4V3lmAY4riin5LJoKrlnwH3+tzGE8LR P1qrfdbNAkBthhgB8Lkpm/ktcLu2cl9CUSYoVpgMCn8qWf4ZiR+ErH4+YIE3Hu8JAO/ghFMNwzk/ AADZcJyszTAaAQAAAHJCjAAAAAA5IUYAAACAnBAjAAAAQE6IEQAAACAnxAgAAACQE2IEAAAAyAkx AgAAAOSE+9EBAEBNYt7e1h33mKqLECMAAKBWQJ6oixAjAACgdkGeqEMQI2oeUxNPfAYAqP1weKz9 ECNqHuI2ANRnMrJC4eERYaI2Q4wAAIDaBV+u6hDECAAAqBWQHuoixAgAAKhJSA91Gm4/BQAAAHJC jAAAAAA5IUYAAACAnBAjAAAAQE6IEQAAACAnxAgAAACQE2IEAAAAyAkxAgAAAOSEGAEAAAByQowA AAAAOSFGAAAAgJwQIwAAAEBOiBEAAAAgJ8QIAAAAkBNiBAAAAMgJMQIAAADkhBgBAAAAckKMAAAA ADkhRgAAAICcECMAAABATogRAAAAICfECAAAAJATYgQAAADICTECAAAA5IQYAQAAAHJCjAAAAAA5 IUYAAACAnBAjAAAAQE6IEQAAACAnxAgAAACQE2IEAAAAyAkxAgAAAOSEGAEAAAByQowAAAAAOSFG AAAAgJwQIwAAAEBOiBEAAAAgJ8QIAAAAkBNiBAAAAMgJMQIAAADkhBgBAAAAckKMgDpKmri9G8t6 rH0sISKSxK9xZ1nWfdmd3FILPd/2Ncv2/zu99PKZ/3gZsuVw/u2euLAxl3lhVlfvkATJe9uSIevs qJZst+2JUiIicfzelcvD4nLeLy+f6N8J5myn9U9Kb6Yyvc1LiA7y7+1oZsCyLGtk3mHg5I0XUiu5 Zz5O/vNjvw3vZGHIsixr9tWwwKMJ4rdVBZk3t03s0c6QZdkWrr5LopPevS4ZVQBQp/BrugMA1ej+ iklb+0SOaq4oezGB+ZjlS3rlcUQkTTy0aNUpnWHzfjRXISLia1k1KXxXiOM2zj5uvWCqAZ8q+PR/ h6/R0sGpYWMlhogoLz5ixfKs5t97tRKUKq+qCnsrTT080XNEpLjdgJELfmneUJJ692TYxjkDzjze fXSBk2rhSiq5Z6qIy7q8oP+3m17b+gasdNJ+dX7r8qDv+77ZffxXJw1Gmhzp33/6CXbAlKUuqnHh v63y9WaOHp5srkIkowoA6hjECPiCaBmrXl80NdwzzMdI5l82X/jVwKGF/xTffb521RkDDy+fLuol F+HenF25NfebUJsGVemASttfQnZXobxSKuqt5OmBFZFpJj8fi/iltXJhkbdPz0Wdu69ZcnTcnj5E VPk9UzXcm7NB25/pDdu749f2DRii3p52ym7fbFl2/OedfRs+2L70WJ7j0r+WewsViPM0y3IdtGHF Ob8NnRrml18lV84CgBqEkxrw5VC2+SWwr9qFeQH7kyo9flCOgpen1p9s0Pub5kof1uXEzLA27rP7 xt9z+9kYsSzbzNF7cXSKhIgo+4K/mUG37YlSSfwadzPfaAl3abSFQfcdj84WlRMRkeTl+TVju9s0 Y1mWZVs5D5wVEZ/3EX2VvnmaRnzWTL9EX1XbeP/s591ekF9ARNW6Z0rKT7r+UKzm0N28QeHHP9PA rFM7Fenz+y8lkuTzUY8Zm6Gd9RWIiBh160FdtLMvHbmfSzKqAKDOQYyAL4iCjseshV2Y4wHzjr0s +JgVcemXd10TuLgbl5EiiIhIci/Yb/HTjrO2hm6c24t3OvjHgNPpXIl6vqFPSFSgA48s5h48u6lX I4V3VdKkiDFDFh5mus4IWr9h9fzB+jc2+/uHP5N/coCSkautuuTMtLFLIq4+zy563YpNB8xZMq0H WzT2UG17phRFk+Ghp47+z0HtbUHes0t3c3n6zXX44sSbL6iRuYn620OMsoGVAb2Ke5bNyaiqtp4B wOeCGAFfFF7jngvmOOfsn7r4XPpHfCjlPjxxU2zi0qz8k/WZ+X3XrpnQ172j58iFi3urZ8XdSi0V BPgarLGwAY9R1W/atIl6iRRB+S8TlW36LV77v5H9e3Tv+0PA4tEm9PxOar7cnWU03QO3z+qheznI v7dDSxM7z2GTAv88FJssLrUDqmnPlN6ycqOmpk0bKTNERFzukwOzR658otN/XCddnjT7VRY10FUt fuUKatpqRKJX2VIZVdXULwD4fBAj4AvDNxy0eLrVq9BJy69myftxWZDx6M5rTVNWtfxT9fpdujUv ChmKGrqqTOU3pWIxfvve4EGGvNzXCXExJ/fuiHoqZzeLKWjaj15/Iu7BlSPbl0/q0Uz07+aAkT1s 2g/fGpdTYqnK7pnc2Fl2ZV0VYjPjWk7ZLbi8hOgV37o6jw7J6rIgbKGbVvFx5f0dWGK7MqoAoO7A FEv44ig2H/bbxLAuy37+fcDfQ+VagzT9RTqpNVJTKH8RVS2BjFqZ8p4cXDzt15DTT0Sk1rhFaxOF j3wXSsWiXKmiQKCo2sTSw8vSw8t/niTtyvofvRfO+Hmnx56O75as3J5RNvsp/PgQ8fsf64yitnEZ ozOcKC5s2g+T98TruIxe89fEXq0a8IiIFNR01Oh2WraUqPDiEKkoLZtITVtVQUbVx+0IAKgBGI2A L5BK61HLRhk/Cp7053255i5yXAFX4ZdjOS8qyH+06YdR6593DIyKjU+4f+3kniX9jT7q+oTcmwtc WzpMvyIqUcbXtvtuYveG9OhyQukdUJk9w6joNTdr/QEz08aCDzqa/zjkh56TIlW/W3v2Yvisb4oy BBEpNbEUUsqdp8XzHcSJN1+QbuumDRgZVR+xGwCgZnxkjMi7Od/+g7HPZtbdRgedSZFrylj5d9Eh KnU/n6qRuyHUTYya1YSlPnq3lkwLk+eMAb+hUJPJSv0k5+pzH597QG2+G9PbopESQ8SJEh+8+qjx fGUjJ3PltIN/HH5e4i3Hie6fuJxOhu2E700SrcSeqfxJDS7t+Lz5p7VG7NyzoFez0hmDr+/c1bgg Zue51MIZnaJ7+4+nqjt5thDIqgKAOqdaTmqYfjdvZOui4U5pTtKN/RvDAr2fCc5GjmxapfXLvIuO BlPqfj5V+94id0OoqxgNx6lL+v79bcRrORrzNExba6Y/TBBxth/3B8NwiRdOXTRxNntXpGJgZ0xL N64MMx1mqZJ8ZfeqZXtfEXP/yq3nrW215NqGdqfZ0526zR3n7hk1pKe9iY5SXuqDcxHb/3mi7x0y wFDxzfvLV7RnKn9SI/vm3rMilVZ5Z/8M/vddKb+Ju29/S/UWvpM6b/hp0o+B+T+5qtzdPmdjUuvJ E5w0iEip/CoAqGuqI0YoGnXy8vF4dzccbrBDnoN3xL6Lr35o2rgKwx2S57LuojNADydgoCp42u6z F3b9Z8zRrKq3FZh6WCrNPB+f+42O/F+RBa0H9DAYs3Xs4PurTk4sLlVs6bc+8PG4RVO9w0mRdfKd Eh6ZPGvgr/N+2uBwcop8G1JuMSIk2njtktVhoUv+ziIivk4Lp8HzAn/5zkmLJ3k/RlS4ZxgVveZm epXYruT1f49FlBuzfXlMqfLWqj37Wqrz9fsE73w9Y/LycUNXk4qxx/htS/3NCt/YCuVXAUBdw32U 3Bvz7ITGPsczSpden2snZPvuTS0o/H9+6vnff/y6raFQKDSy7vXz1th0aZkruz7HVmjkdTCtoESh OH7X3MmLDibk5//3u5vwLc+/Xkg4jstPPff7GE/rpkKhUChs6TQgYO9/uRzHcZzo8mRLo34RNyMn e5gIWVPh+w1rj4/+FcAnIU2JGNTKOfBuXk13BABwnKzVquMbPifOSHtV5GXK01tRv/9vR6Je/zEd tRkiIlHs0gEDFkYLes0JXrdycofs3dN7+256VMZV8rLvovPe/Xx0FSq6jY/kwQa/Kad1e4+etfrw oVINASrC03Ub2THrQOQjccXLAgDUX9VxUkNydqxz21Ilau5L/lnaWYdHRAUpUYv+eGA89tBfM9qp ElH3zm0KOviuDLoyZJWTWun1FN5Fh5uyLMi/dxApNmnb0c3N3ePr7p3bNVZi3t3Ph/SbNm2izhDl Ft7GZ9X/BhnyiaiLeUa0+9Y7qflkWPiqXiV2CD+52LUhQ5QZXbIhQIUYzQ4TfZV+2HJtbKBjlR6r AQBQn1TLFEvLSRumWhWdQpZmPzm1dsHmmRNDXXcOM+aTKO5IjKTZ6P5tih40yNNy8HJtsPf61SSJ kwkjkRbN42J4Cgo8pvAuOn6iF7cvnj516tTJ6M0BoUEBel1/DVvzbasPzlGrWIzfvpeICnJfJzx5 /DA2Muopkcu7er3ug+3wqB+Ql7KZ3wK3/iv3JYT4GOD+KgAAZaqWKZaN2nVwd383xdKtrfSi0+zw cy99jPV5+emp2RS/zKPpslJt9FOzJNnnJ9oM2l84y6uR74ELCy04GXfRifzW8P3OVnAbHw19DRz9 QX6MhvOv/zjXdC8AAGqzT/E5y9du2UyVbr9Il5I+j99AU4Va+u/6o4duiXkYjJKWkbJAMiPyyI9i joh4yo2a080Frj32eUT8u9RB9d2q7L6b2H312ajLCXnvx4jC2/iIfYOjfulp3kiJkfy3pkvH9SUW YHgYigAAAPiEPs1FlBwRSXIlBUSk2rJTG/6zK4kNm7cs1JR3LnBCwK7EAoanZmhm2bZt27Zt21q0 aiJQkX0XnQ8uB6v22/gAAABAlXySUX9GUYVP6Qmv84mUFZr0mj5k5cDxfUY8GNvbUv3NtV2r1p1S HeVv+sFUhwruolPU07f387E115JxGx/tMjpV3FCvvIc/AwAAQFV8ktEIZbadAWVGrT6QICFiNJzn 7ftznNl/W6f7j/KfFZ5s+8v2vdOt1cpq12JESPSfk7sIboQumTt96oy5K/c/Fg6et/vwYvfCRwYK Wg/oYZCwdezgOaffFCi29FsfOKBB1FTvHt0HzTqsPDw8coa94r/zftoQ98FFeqUafoqXDAAAUA8x XMWPIIJPiGHwKwAAkAXHydoMN5gGAAAAOSFGAAAAgJwQIwAAAEBOiBEAAAAgJ9zmEQAAahLDvLtV IKZS1jmIEQAAUFsgUtQ5iBE1r+TbBgAACuHYWCdUU4yQJGz7pv30WNL/4e9z861UqmellZN1dpSN 15NZl//2FSrIWk4cv3dNhNjzx8GtBFVo9TkgcQNAfSYjLhQeHpEnarPqmWIpSYz6K5aIKOnArrs5 1bLKSuNrtHRwattYqaK/srz4iBXLw+/nclVqBQAAnxv3Vk13BCpWLaMRkoQjobcYq6mz1VfMO7Tz ToC17QcPzPh0VNr+ErL7M7UCAIBPBrmhLqqO0QjJ00Nhd/mO3w/q6+uilHJ4523Ruzrp60vr/T2t jVmWZU0c+gdExOfKLCcu59G+uYOdW7Isy5rY950ScjPz7UMwuOy43TP7OzRjWdbAopNf0JkUCRFl X/A3M+i2PVFa2JeX59eM7W7TjGVZlm3lPHBWRHwekSR+jbuZb7SEuzTawqD7jiRpyVblbjEnZoa1 cZ/dN/6e28/GiGXZZo7ei6NTSjx+FAAAPhrGHuq0aogR+Y8PhscpOg9z09N1GuKqnHo4/NbbHFGQ 8ve4IfMOK3gGBK9fu8TP9N6f/iM3P8ovt5ykqUcm9h674WHLHwLXrls+3uFV6NQ+I8MSJEQkTd4/ 7pvxIW9cpqxa//v8fhqnAr2HbXiYX6or0qSIMUMWHma6zghav2H1/MH6Nzb7+4c/k/ANfUKiAh14 ZDH34NlNvXRLTIeQsUUiIsm9YL/FTzvO2hq6cW4v3ungHwNOp+NPHQAAgIiq46RG/n/7dz4UuE3v oMNjyNHbRTn6SPiNuQ6OakSU+/hkTI7w20VzRloqE3Vr34S36Ag/V1puueRp+JID6VbzD238wZhP RJ5uBq+dxq3YfLf/7Fb/bVl8RNp5beiyXno8ou4d9Z84jNx59NnIb0v25WWisk2/xav+N8iQT0Rd zDOi3bfeSc0nQw3WWNiAx5B+06ZN1BmivKIWksflbtGSiIgy8/vuWTPBXIXI3Vrt2lHvO7dSJR4N FT96twEAANR9Hz0aIX60b3e8wHVgW0VRdrZI0bKPg2JaVNiNLCIiUmLtWvITt0yZ+UfkhbhUia7H lBVL/MxVyivnMu6ceECW3t0NitKNgp77UDuFxHMxL/NTLkU/5dsN7tCosMeM9tdrr96M+M6oVA5S sRi/fW/wIENe7uuEuJiTe3dEPZXdexlbLDxJQvpdujUvuvJEUUNXlcFQBAAAwFsfGyPyHuyNeEI5 //jZt2rZsmVLM8dxZ/Lp9dGw61lERHzWa1PEYm/tq8FjBnhYmbRyHTov8r8crrzyAtGrTI6v06RB 8UkHRkWnSQPKSsnMzUzKJA2hzrtLKxQEDbU1Vd8bTcl7cnCet3MLw+YW7Xv9MHfHrfwKRltkbLEo RqhqCWr8ilAAAIDa6SNjRG7c7ohnCtZTt+wutnWqtUL60dCYTCIiUtCy8V3414nbT+6ci1w33uLR +jE+K+/klVOer6qtzkhevciSvl0/l/cqOZvUdNSUVLUFlJWSLnlX8yLmzPm7b6QlepP/aNMPo9Y/ 7xgYFRufcP/ayT1L+hvJvqKTV/4Wi/cMrgkFAAAo28fFiNx7uyIT+Y4jvDs5FfMYPLw9P+NYaEwm SZN2DW5r5RuZWsDwGza16zl6xsjWlHD9eU455fka5u4t6GboobczHKVJx/+6JGnibNNIubG9U2Px 5Z3nXhZeRcGln53rPfiX/S9Kxojcx+ceUJvvxvS2aKTEEHGixAevZJ+EYMrfIu7vCQAAUIGP+rAU 3Q47mMx3mOWsUyKN8HRdvGx556N3XM3o6Gxpp5m6YsqIgCQfJyElnt+29C7fPrBNA+2sMssF/CZe k3uuGTm7/4iX4/uY8eMPr152itdx6QhzFeJb+P3ssmPq6MG/TPZzZ7Ovblt8MNtqzkBTJbpSvGkV AztjWrpxZZjpMEuV5Cu7Vy3b+4qY+1duPW9tyxIRwyVeOHXRxNnWXK/49Tctd4v0me+jBQAAUOdw 8sv+d5Kl0LD/7mRp6XLJi9DerLDlyOPpBQU5j/bM7N++uVAoFAqNrbv/tO7iKwnHceWVc1xB9v3d AQPamwiFQqGxzTeTQ25lvF29NCN2y4Tu7QyFQqHQzO2HlWdS8jmOyzo/thX79bbnEo7jCrLubh/X pY1QKBQa2/cP2HUjZvU3pkJh+zkxOVx+4r4xDkKh0Kj/rmRpyVblblF0bbqV0HXFfXHR9nNiAqzZ DqseiLlq9HG/AgCALx+Ok83VSfIAABK3SURBVLUZw+GOHzWKYfArAACQBcfJ2qx6nqkBAAAA9RBi BAAAAMgJMQIAAADkhBgBAAAAckKMAAAAADkhRgAAAICcECMAAABATogRUEdJE7d3Y1mPtY8lRESS +DXuLMu6L7uTW2qh59u+Ztn+f6eXXj7zHy9DthzOv90Tl7lBScK2HizLsrazY3PLqH3575/TvN0s jVmWZdkW9j3HBkU/L16R9EWIJ8t23ZIgKdEiJWqyI8tajAh/XPYGAQBqPzw5Ar4k91dM2tonclRz RdmLCczHLF/SK48jImnioUWrTukMm/ejuQoREV/LqkmZ7wpJYtRfsURESQd23Z1uZS0oWfc8Ymx3 /4NpRm5Dxw0x05Im3zsdERroe/rOumO/92xc1iNipa9OzR8wfEe6x+KDq72aKsn1YgEAah5iBHxB tIxVry+aGu4Z5mMk8y+bL/xq4NDCf4rvPl+76oyBh5dPF3VZTSQJR0JvMVZTZ6uvmHdo550Aa9vi HCFJ3PPzzwdz3Baf2ORrqlJY9uO474P7dF48a9VIj19tVd9bV0H6v0sG+2xK6jh//3qf5ipyvFAA gFoCJzXgy6Fs80tgX7UL8wL2J0krXrpKJE8Phd3lO34/qK+vi1LK4Z23RcVV4kehQWfFVjMXe5uW SAQCM99pPjaNk28m5ZdeE5cZG+zjtfo/h4C9G4ebCfAcegCo0xAj4AuioOMxa2EX5njAvGNFT5Sv JvmPD4bHKToPc9PTdRriqpx6OPzW2xwhTbkQ9ZgsBnUSlh4AYTTdAw8c2fSdSckTLAU5dzcMH7Dk hvnkPVtGW6ghQwBAXYcYAV8UXuOeC+Y45+yfuvhcevU9ySf/v/07Hwrcvu2gw2O0HL1dlF8dCb+R XVgnTr2fSqrGJpplTYEoLfdhyKh+887nkESUr8BHhgCALwBiBHxh+IaDFk+3ehU6afnVrGoKEuJH +3bHC1wHtlUUZWeLFC37OCimRYXdyCqsLSjgiCuozODHoz9/j20feOBPb737K38KuiGquAUAQC2H GAFfHMXmw36b2Cph48+/3xJVR5DIe7A34gnl/ONn36ply5YtzRzHncmn10fDrmcRESnqNtehnCeP 0iTvNSt48+8fswKCz7wsnqchcF2wb62PTeeAVUP0HgT5B8VWS/cAAGoQYgR8gVRaj1o2yvhR8KQ/ 7+d99Mpy43ZHPFOwnrpld7GtU60V0o+GxmQSEV/fycOA7oQdeVY6R3CZ1zau2Bx6VaxUfLbDxLOr iQoRT9N15qoheo+C/Vdez0aQAIA6DTECvkSMmtWEpT56t5ZMC3v6kavKvbcrMpHvOMK7k1Mxj8HD 2/MzjhXmCGUz37H2/NuLJq6/+e4sCie6vWXxoewGnYbalHEdKU/TNSBoqF7872NXxFTXmRcAgJqA GAFfJkbDceqSvprP72V83HpEt8MOJvMdvJ11SrxXeLouXra8zOgdVzOIiG/kHfSbp9rlhd1c+01Y tGbzlg3Lp/t26rbktnqn+bPctcqcSslr6DIzaKje4z/8l1XbFA4AgM8PMQK+VDxt99kLuzb4uJWI boUdSlGwH+yiW+qtwtN1HWTDZJ7YcSWDIyJFo0Frj4fPGmSSfGT1wlkz5y7bfV/nmynbjm3wMiz3 NlhFQeLJ+p+WXslEkACAOorhOBzBahLD4FcAACALjpO1GUYjAAAAQE6IEQAAACAnxAgAAACQE2IE AAAAyAkxAgAAAOSEGFF7MQzDMHh+EwAA1F7lXtUONQXRAQAA6grEiNoC6QEAAOocxIiaJztAIF4A AECthRhR8wrvzlZeXMC92wCgnsO3qdoMMaK2KI4LeMMAAEBdgRhR6yBPAABAXYEYUXvhdAYAANRy uG8EAAAAyAkxAgAAAOSEGAEAAAByQowAAAAAOSFGAAAAgJwQIwAAAEBOiBEAAAAgJ8QIAAAAkBNi BAAAAMgJMQIAAADkhBgBAAAAckKMAAAAADkhRgAAAICcECOg7spLiA7y7+1oZsCyLGtk3mHg5I0X UiXvLyVJ2NaDZVnWdnZs7vtVL//9c5q3m6Uxy7Is28K+59ig6Ofit7XSFyGeLNt1S0KJVUpSoiY7 sqzFiPDHYvoQl3lhVlfvkIQPOlEecfzelcvD4nIqu3y14kT3d88Y4GjKsixrbN39p/WX0qREJL4f 1KvHbzdrpk8AUMcgRkAdJU09PNHTN/AfSfsRC1auDl4aMKTNq91zBvSaeyGj1APWJYlRf8USESUd 2HW35Eej5HnE2E79Av56zPYYN2fhgoBxfU1f7g/07TbuYLK0nE2+OjV/wPAd6R6LI1d7NVX6cAFx 3MbZx63H9zHgV/ZV5MVHrFgefj+3Bp4Jz2Wenz1o/LakdqMXr1r16xi7N3vnDRy546mElEx9/IW7 Zoc9qXQYAoB6jIMahV+BnPKfbOoiFLouvZP7riw79lcnoUGfXcnSEsvFr+skZLuvWufVVGg17Yqo uPx52KCmwhZDtj3Iebew6E5QV6HQavqVbI7jOEni9m5CYZc/n+VzHMdJ31z89f/t3XlclHUewPFn YBDBC/HCZxQSCDFFRQUk0QBNDcu1NYNR3IqCzHTXIzGvdF9uK2YGUl6sFambpqSiWKahmWl54pGa BxriTaHcMNezfwwgKGD+1GXIz/vFH/o4F/Kah898n+c306+N/HjYspOFpiofkulG6utdAmJOlNzD t5GbGu6sGbIxu+pbfKhyUyPc5KDF5/Tmv+rPLw2W5f6JmQZFUfL3Turu8/b+gv//owKqwH7SkjGN QN1kvHkhW1JrPJ0qDAXsn9BOiNL62elN5ZsMF75afVLd85UXnx/Zq971r9ccLzRv16Wviv9B13Va jNa9/q0bsPMc+XZ4t1bXjl3VV743Je/wh+GhH53znb5uWYSnnaqqR2T6bWfCdw0H/8Wt/BEpBaeS pg31bafRaNp06hsVv+t6pdf3hvOLgjxHbjco+0Z1ahPy+VWjJBlv7EsY84y3i0aj0bj6Dp2+/nyx JElSUdpUb5chSUc3z/prN2eNRtOupzZm+/X7GxYYiwrsHvft29OpdHJi3cjJQSUZSoyKJEkNOg0L NqR8vC/vvu4CwKOgtjvmUcePQJDpxrao9rLcSRuz7sDFfGM1l9KdWdBHdglLzjKaft8c3k72emuv edCQ+enT5S+9q1M2jcjIPbH0BTfZOSQ2Lbf6qYEpe/OIx7tG7y+fdxiubohoLzsHj1u0NmX9xzOG eMiaAYvO6CpcRZ9z8diKIW3k/gmHzl3O1SvGa8nhbrLroCkJX6ZsXDlH+4Qs9114VqcohYemdJXb 9/ELeCV23fadXyWM9Zdlj8jUmw9uhmHKT3svWJaD4n4pnaXkpka07zhmd94DuwdAHPtJS/aHj+EC FkXlEDR3xQwlen78mMHxkk3rzn0CA4OCB4T069KqXvmwQH9u45qzdoFTejezUkk9tb1st2/54ugs 354NdFmnsyR7H1cH67veUfHZla/PXbinSJIK9dbqKucQpZfbcUzn+mK7suGG7nRizBZjvyWr5j/X 0kqSQvo4ZfhGrtmaGenuWvasUzfWuMgNrVSS02OPtW6kkgp//S6tSH5pzsxIL1tJGujX2mrOFnVx 2Ykaefrnv1w0rmN9SQrybnBoq/bEz1mG4CY2gv9/FZlyD8T/LTTuUtC/U15vXzpLsXPv1TZv2a5M 3ZMdqjgJBABKcVADdZW1g8+ohB2nzhzYsuKDtwa1K9z7yfTIQd38Ij4rX/egS9+QdN4uYFhnm8KC gkIbryG+NtnfrD6aL0mSyaRIislU0+2XSv904WG/uZs+1bY8HTc2/mhhNRcz5aafuOHgrrEvDQ3j 9X3bL6h7hPVuYX6OqRwHLDl4bP3LzjWUez1NDw/15cToaYuTfzyVZWgeHB37XlTHsi5xenqgW+mf bRo3t1dVdVZm8eEZPTRV6Db1ULULLwwZyyOGzTsVMDdl2Uu3jvCom7q2tbl8+ALrNQDUiGkE6iaj rrDYaGNnZ2Pf2is41Cs4dMw/DdkHEt7Qvjt1wprg5JfaqqWSM+vWZ0hFGVE+7StccevqI/n+fs3d mklFGenZhqcaVnoOmG7uXTp/k6H/uNG9m5u32AXM3rAk3KPeswuGp2rjx8QP2DK5q/2dQwljzpUc qUGLBmXjDWPe1Typcadmt0Yj1nZNHO1q/J7UmtCP1xvfn//Jh6NX/UuS7NsFhk+aHT3Y1Xwt+6Z2 d52d2HqO/SJ1uO72wlDZOLrUr/IKkmTI2JT4o953wbzh7pUuom7UooHx8LV8o9Tk7iMbAI8sphGo k4qPzQ7w8J1yoOJwQO3Y4+XxIU2k9P0XSyRJKj6VtD7T2ntyYlK5zyZ7W+dsXZWWp3byD24jnVi9 JbPyeYpK3qFlsZ+sOqirV/6r0/WZ/q71JcnKIWDaguEt0z8cE3ekoIpBgKKYlIqbrewd7aT86znl t6+UXEnbtefkzWoWk5pZN+028t3/7jiecWJ38tJ/dEpPGB0ed6Kk7F+rP6JSfon6Ld08O9zB071V 1aeFSpIkqVt09g8O8GjMvgCAAHYdqJNsnf072manLP76UoUOUApP79ifI7XtIttKUvEva5Mvq3u+ pu3rXy44LMJPnfvtqrQ8W8+Rb/qoj88Zn3AsX7l1/eOJMV8VNOw7olujO+/SyiFgevyIlucXvhmb ln9HSKibyA6q/KyCskpQt/Lxb6Xbv2b3b+YjJ0rOD7O0YRM3Xqk+I4xX14Z17joyOcukUjd5rMez o6ZGdpAuHrlU1ftcVUPgoIbaJTQ+afnEzrdPKwx5WQXWjq0aMooAUBMOaqBOUjn2fWeK/8BZfw96 5pvhz/q4NqtXknVm9/oV2zKctCtfaKuWCo+sTrmm9p3xZLMKqWzVvFdod6s92z8/mNsnUBs/7/uQ 8e8ODNg2LPTpzq1tbp7auXbFjguN+n4wI6hpla/drZr0mhY/YlvY4jHzB259p0fDiheyauzewSHn 7MVCpbv5hX/9TlETen0+eVTYxElRQZqCg8tjUgq6zhzmfscJiyrl8o87f3J9sntHR68eDlmx0a9N vxruL0uX9yx//6TaZ+4TNR8JqUTooMYXEyZudnknoXJJGG6cy9TL/Zzv4c4BPJJqe6nIo44fgThT 0a/fxI5+zs9DlmVZlp29ngqN/s+ea3pFUZSCvW95yW2HJl27bSmo4cqqwRrZIzI1x6Qoiv7qrsXj nvdvb74Bd59Bo+O+zSx/P6vKbz9Vynjz+0ldZbnnzH23Lf40ZW8eXmnBp6IYcw8njgvp0laWZdkz 8NW4Xdf1ym30lzeM9pVl2Xno2mtGxVSU/uW0oX5usizLsot3yNilP/1uUEoXfAbEni5bLVqUNt1b 03tBpdWjokpOxvjLbq/uvG1pJws+YUHYT1oylaLUwtvwopxKxY/gT8KUtUHbe173DTuiPev+EsnC /ZMDInI+2L0ksHFtPxSA/aRF49wI4MGwah4Y2Sd/U3L6PZzLYKZSlX7d5/YHp+DnpO3qQa/60BAA 7oKMAB4QlUPv8SPrJSceyr+na6kkRSn9qlgG97r9AVJu7F62Qx71hneDh3LzAP5MyAjggbH1jJod eChuwx/+oHBzE5Qzl4H56w9ufwh0Z1Z+dOmF2VoXTsAGcFcccKplHPMDgJqxn7RkTCMAAIAgMgIA AAgiIwAAgCAyAgAACCIjAACAIDICAAAIIiMAAIAgMgIAAAgiIyyXSqVSPczPTQAA4D7xdrcWh3QA ANQVZISloB4AAHUOGVH7ag4I8gIAYLHIiNpn/siZ6nKBD6QB8Ijj1ZQlIyMsRXku8IQBANQVZITF oScAAHUFGWG5OJwBALBwvG8EAAAQREYAAABBZAQAABBERgAAAEFkBAAAEERGAAAAQWQEAAAQREYA AABBZAQAABBERgAAAEFkBAAAEERGAAAAQWQEAAAQREYAAABBZAQAABBERgAAAEFkBAAAEERGAAAA QWQEAAAQREYAAABBZAQAABBERgAAAEFkBAAAEERGAAAAQWQEAAAQREYAAABBZAQAABBERgAAAEFk BAAAEERGAAAAQWQEAAAQREYAAABBZAQAABBERgAAAEFkBAAAEERGAAAAQWQEAAAQREYAAABBZAQA ABBERgAAAEFkBAAAEERGAAAAQWQEAAAQREYAAABBZAQAABBERgAAAEFkBAAAEERGAAAAQWQEAAAQ REYAAABBZAQAABBERgAAAEFkBAAAEERGAAAAQWQEAAAQREbUMkVRavshAAAgiIwAAACCyAgAACCI jAAAAILICAAAIIiMAAAAgsgIAAAgiIwAAACCyAgAACCIjAAAAILICAAAIIiMAAAAgsgIAAAgiIwA AACCyAgAACCIjAAAAIJUiqLU9mMAAAB10v8A/okNRyujb3oAAAAASUVORK5CYII= --001636284dea64bad504a3ef3183-- From sandeepkandula30@gmail.com Mon May 23 06:17:26 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBE2E079E for ; Mon, 23 May 2011 06:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXWtIaCD9m7s for ; Mon, 23 May 2011 06:17:26 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB339E079D for ; Mon, 23 May 2011 06:17:25 -0700 (PDT) Received: by yic13 with SMTP id 13so2601663yic.31 for ; Mon, 23 May 2011 06:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uPN1qfsDrez++nMFn8Or+je/nsSJz0k5//zUIevIo+k=; b=kD0a+0/ZJm7swfKjSkhOat5jcZKV33qASsaNZecgTP5tAwX18r15T1dwQfMsoV0+pt wWsFQSYzgn6tnC0W2h2vnOrT/Tic95a9Gbf21yvA6Jr99oiqImnVdy3mpk4b5tTlyn5i vjNZRCxlqcH4VCOI89pwW4Ypnnt7sfaSo4MqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=KzwYeOs2ZDWhmpd6nz34SqW7LyUJyt8mlPrLThgO+wBbrtvCwuhm56TD8iVJZfmx3z DmyzVg1eRv4Z+huaXlnSVCUVtEbutSAaJTSbHeimnSlSl9sRVFGyaCE8ngAGspoEWLLk R6KfdkTi+SoT7YpeVxJ3doIMFDf5vQGpXiUkg= Received: by 10.236.154.35 with SMTP id g23mr1749633yhk.515.1306156645264; Mon, 23 May 2011 06:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.108.9 with HTTP; Mon, 23 May 2011 06:17:05 -0700 (PDT) In-Reply-To: References: From: sandeep kandula Date: Mon, 23 May 2011 18:47:05 +0530 Message-ID: Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start To: Padmalochan Moharana Content-Type: multipart/alternative; boundary=20cf303b427ddcadb404a3f14a01 Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:17:27 -0000 --20cf303b427ddcadb404a3f14a01 Content-Type: text/plain; charset=ISO-8859-1 Hi, When peer restart happens and same identified at SCTP EndPoint B, all the queued data will be deleted at SCTP EndPoint B. This is as good as tearing down the association and re-establishing association again. So, SCTP EndPoint B will not send any SACK for old data that received before peer restart. Thanks, V Sandeep Kandula. On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana wrote: > Hi , > > I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK > message after restart of the peer. > > what should be the value of the "Cumulative TSN Ack" in SACK message for > the DATA message received before > > peer re-started. > > Please find the call flow for the scenario for more information. > > > Thanks, > Padmalochan > -- *Regards, V Sandeep Kandula.* --20cf303b427ddcadb404a3f14a01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,


When peer restart happens and same identified at SCTP EndPoint B, all the queued data will be deleted at SCTP EndPoint B. This is= as good as tearing down the association and re-establishing association again. So, = SCTP EndPoint B will not send any SACK for old data that received before peer restart.


Thanks,

V Sandeep Kandula. =A0=A0



On Mon, May 23, 2011 at 4:17 PM, Padmalo= chan Moharana <p= adman.m@gmail.com> wrote:
Hi ,

I have a doubt regarding the value of the "Cumulative TSN = Ack" in the SACK message after restart of the peer.

what should= be the value of the "Cumulative TSN Ack" in SACK message for the= DATA message received before

peer re-started.

Please find the call flow for the scenario for = more information.


Thanks,
Padmalochan=



--

Regards,
V Sandeep Kandula.
--20cf303b427ddcadb404a3f14a01-- From padman.m@gmail.com Mon May 23 06:36:17 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1866E07AD for ; Mon, 23 May 2011 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17eRyXHQCwLE for ; Mon, 23 May 2011 06:36:16 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A80B3E0782 for ; Mon, 23 May 2011 06:36:16 -0700 (PDT) Received: by qwc23 with SMTP id 23so4511023qwc.31 for ; Mon, 23 May 2011 06:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OxtvyZJQBCcqh+VywRh+uIba8GEgjfSVIV76Z9BOkcU=; b=wS9P4t62pkEOsqw4+vEQUjk4KFEN5ht208EPBwBC4X16TiKISIv55W7FVa189imad4 7pj7lzzT96HcvhSkmyaKEy+gWoSHn1WVFliGOcnkFYAeTfceaDidf6pwktlCVphEUKxP p9wRr6ccbsjt1De9YL3OkuI86U/CeZURzVc+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fBlc6BOX50MdnHdTAd2D0GC1yHS1oz+94/j6ml/OfZopMoqVlQHAzn/ux5B3KyPkOQ DA2IxABMNtecQy0fyv5kHLAMDj8qb9YtxiUzgwYgJ+R24KGKydeOxwr6vNb6EXwrhzL4 WAZbwSYMC3URd79E/WEuzfDW8L5e9/oSTFWLk= MIME-Version: 1.0 Received: by 10.224.112.195 with SMTP id x3mr1791134qap.114.1306157775554; Mon, 23 May 2011 06:36:15 -0700 (PDT) Received: by 10.229.191.140 with HTTP; Mon, 23 May 2011 06:36:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2011 19:06:15 +0530 Message-ID: Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start From: Padmalochan Moharana To: sandeep kandula Content-Type: multipart/alternative; boundary=bcaec53f938d3b8a5b04a3f18e47 Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:36:17 -0000 --bcaec53f938d3b8a5b04a3f18e47 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the response. On Mon, May 23, 2011 at 6:47 PM, sandeep kandula wrote: > Hi, > > > When peer restart happens and same identified at SCTP EndPoint B, all the > queued data will be deleted at SCTP EndPoint B. This is as good as tearing > down the association and re-establishing association again. So, SCTP > EndPoint B will not send any SACK for old data that received before peer > restart. > > > Thanks, > > V Sandeep Kandula. > > > On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana wrote: > >> Hi , >> >> I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK >> message after restart of the peer. >> >> what should be the value of the "Cumulative TSN Ack" in SACK message for >> the DATA message received before >> >> peer re-started. >> >> Please find the call flow for the scenario for more information. >> >> >> Thanks, >> Padmalochan >> > > > > -- > > *Regards, > V Sandeep Kandula.* > --bcaec53f938d3b8a5b04a3f18e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the response.

On Mon, May 23, = 2011 at 6:47 PM, sandeep kandula <sandeepkandula30@gmail.com> wrote:<= br>

Hi,


When peer restart happens and same identified at SCTP EndPoint B, all the queued data will be deleted at SCTP EndPoint B. This is= as good as tearing down the association and re-establishing association again. So, = SCTP EndPoint B will not send any SACK for old data that received before peer restart.


Thanks,

V Sandeep Kandula. =A0=A0



On Mon, May 23, 2011 at 4:17 PM, Padmalo= chan Moharana <padman.m@gmail.com> wrote:
Hi ,

I have a doubt regarding the value of the "Cumulative TSN = Ack" in the SACK message after restart of the peer.

what should= be the value of the "Cumulative TSN Ack" in SACK message for the= DATA message received before

peer re-started.

Please find the call flow for the scenario for = more information.


Thanks,
Padmalochan=



--

Regards,
V Sandeep Kandula.

--bcaec53f938d3b8a5b04a3f18e47-- From padman.m@gmail.com Mon May 23 06:40:20 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C452E0783 for ; Mon, 23 May 2011 06:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5BxhwdSqEiQ for ; Mon, 23 May 2011 06:40:19 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8956EE0686 for ; Mon, 23 May 2011 06:40:19 -0700 (PDT) Received: by qwc23 with SMTP id 23so4513956qwc.31 for ; Mon, 23 May 2011 06:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wIYwffXsFNoe8N/9QZ29i2+JH6sdCqM9ZIg5oTxTzRI=; b=Iz/OU584LMa0xhIWjr/WhaJ9UWMHrtvNSDa0D21QIXWpmJ9yI5W1vPLSRTT2Xztmx/ t3ilPb7leRVmKEAuCjbpwCqDVZ9lKoyt/3VhZqh6at0k6Qm5tFmtskMi0s+lmXhxhYG8 5+kYoep5k8b3yhHgerNAtvIf/+ruEHDmEwtb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iQLH1O0/qKT+DrxQuXCmrp6FEBHFam1getcL5mYrRcMgldPZkPrADAO5Je7XdRpkng S/4txCLM/AWJx0zZcEMC4y+/vymOpllTSYQwigUdTCml6U8a1PiMQ0ORA1IsHOjdkKvW Vnrt98yXkf6W0SsSCcuLWNqx4xzzrsMHYf1o4= MIME-Version: 1.0 Received: by 10.229.87.143 with SMTP id w15mr1705844qcl.170.1306157691703; Mon, 23 May 2011 06:34:51 -0700 (PDT) Received: by 10.229.191.140 with HTTP; Mon, 23 May 2011 06:34:51 -0700 (PDT) In-Reply-To: <1DE8F8E6-05A8-476B-822F-5B35A27C490E@lakerest.net> References: <1DE8F8E6-05A8-476B-822F-5B35A27C490E@lakerest.net> Date: Mon, 23 May 2011 19:04:51 +0530 Message-ID: Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start From: Padmalochan Moharana To: Randy Stewart Content-Type: multipart/alternative; boundary=0016364ef1923c109c04a3f18927 Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:40:20 -0000 --0016364ef1923c109c04a3f18927 Content-Type: text/plain; charset=ISO-8859-1 Hi Randy, Thanks for the response. In this case ENDPOINT A send INIT after sending one DATA with TSN 100 to peer. So should end point B send SACK for the received message after sending INIT ACK to endpoint A. Or Endpoint should not send any SACK for the DATA received before restart of endpoint A. Thanks, Padmalochan On Mon, May 23, 2011 at 6:30 PM, Randy Stewart wrote: > Padmalochan: > > I see the restart occur, but in your picture > I see no data sent... Until data is sent after > the restart you would not see a sack.. > > A restart is like a new association. After all the > other side most likely crashed and started back up again. > > So IF your restarted endpoint had sent: > > -----DATA:TSN=200-----> > > Which it would have since thats the initial TSN it declared in its INIT > > You would get back > > <--------SACK:200 > > But only after a data message had been sent. > > R > > > On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote: > > > Hi , > > > > I have a doubt regarding the value of the "Cumulative TSN Ack" in the > SACK message after restart of the peer. > > > > what should be the value of the "Cumulative TSN Ack" in SACK message for > the DATA message received before > > > > peer re-started. > > > > Please find the call flow for the scenario for more information. > > > > > > Thanks, > > Padmalochan > > > > ----- > Randall Stewart > randall@lakerest.net > > > > > --0016364ef1923c109c04a3f18927 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Randy,

Thanks for the response. In this case ENDPOINT A send INIT= after sending one DATA with TSN 100 to peer. So should end point B send SA= CK for the received message after sending INIT ACK to endpoint A. Or Endpoi= nt should not send any SACK for the DATA received before restart of endpoin= t A.

Thanks,
Padmalochan

On Mon, May 23= , 2011 at 6:30 PM, Randy Stewart <randall@lakerest.net> wrote:
Padmalochan:

I see the restart occur, but in your picture
I see no data sent... Until data is sent after
the restart you would not see a sack..

A restart is like a new association. After all the
other side most likely crashed and started back up again.

So IF your restarted endpoint had sent:

-----DATA:TSN=3D200----->

Which it would have since thats the initial TSN it declared in its INIT

You would get back

<--------SACK:200

But only after a data message had been sent.

R


On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote:

> Hi ,
>
> I have a doubt regarding the value of the "Cumulative TSN Ack&quo= t; in the SACK message after restart of the peer.
>
> what should be the value of the "Cumulative TSN Ack" in SACK= message for the DATA message received before
>
> peer re-started.
>
> Please find the call flow for the scenario for more information.
>
>
> Thanks,
> Padmalochan
> <Screenshot-1.png>

-----
Randall Stewart
randall@lakerest.net





--0016364ef1923c109c04a3f18927-- From randall@lakerest.net Mon May 23 09:23:36 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937AEE06CD for ; Mon, 23 May 2011 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrcqG-S8lz7A for ; Mon, 23 May 2011 09:23:35 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by ietfa.amsl.com (Postfix) with ESMTP id 588EFE0658 for ; Mon, 23 May 2011 09:23:33 -0700 (PDT) Received: from [10.1.1.122] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p4NEAKfA003461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 May 2011 10:10:20 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: Date: Mon, 23 May 2011 10:10:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DE8F8E6-05A8-476B-822F-5B35A27C490E@lakerest.net> To: Padmalochan Moharana X-Mailer: Apple Mail (2.1084) Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:23:36 -0000 On May 23, 2011, at 9:34 AM, Padmalochan Moharana wrote: > Hi Randy, >=20 > Thanks for the response. In this case ENDPOINT A send INIT after = sending one DATA with TSN 100 to peer. So should end point B send SACK = for the received message after sending INIT ACK to endpoint A. Or = Endpoint should not send any SACK for the DATA received before restart = of endpoint A. When the new INIT is sent it is the same as a brand new association. = Endpoint B will NOT SACK about 100.. its the same as Endpoint B receiving an ABORT = and then a new INIT. In fact it is very very difficult to get Endpoint B NOT to receive an = ABORT. In your scenario, what you would more likely see is -----DATA(TSN=3D100)----------------> <---------SACK(TSN=3D100)--------- ------ABORT(NO-TCB FLAG)----------> ------INIT----------------> In past interop's the only way to get the restart to occur is to unplug the endpoint that you restart so it won't get a Heartbeat or a SACK to cause it to generate an ABORT.. R >=20 > Thanks, > Padmalochan >=20 > On Mon, May 23, 2011 at 6:30 PM, Randy Stewart = wrote: > Padmalochan: >=20 > I see the restart occur, but in your picture > I see no data sent... Until data is sent after > the restart you would not see a sack.. >=20 > A restart is like a new association. After all the > other side most likely crashed and started back up again. >=20 > So IF your restarted endpoint had sent: >=20 > -----DATA:TSN=3D200-----> >=20 > Which it would have since thats the initial TSN it declared in its = INIT >=20 > You would get back >=20 > <--------SACK:200 >=20 > But only after a data message had been sent. >=20 > R >=20 >=20 > On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote: >=20 > > Hi , > > > > I have a doubt regarding the value of the "Cumulative TSN Ack" in = the SACK message after restart of the peer. > > > > what should be the value of the "Cumulative TSN Ack" in SACK message = for the DATA message received before > > > > peer re-started. > > > > Please find the call flow for the scenario for more information. > > > > > > Thanks, > > Padmalochan > > >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 >=20 >=20 ----- Randall Stewart randall@lakerest.net From randall@lakerest.net Mon May 23 09:23:39 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3269BE07B4 for ; Mon, 23 May 2011 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZjq9K9WQo0G for ; Mon, 23 May 2011 09:23:38 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by ietfa.amsl.com (Postfix) with ESMTP id 520B9E0658 for ; Mon, 23 May 2011 09:23:36 -0700 (PDT) Received: from [10.1.1.122] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p4ND0fbX002787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 May 2011 09:00:41 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: Date: Mon, 23 May 2011 09:00:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE8F8E6-05A8-476B-822F-5B35A27C490E@lakerest.net> References: To: Padmalochan Moharana X-Mailer: Apple Mail (2.1084) Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:23:39 -0000 Padmalochan: I see the restart occur, but in your picture I see no data sent... Until data is sent after the restart you would not see a sack.. A restart is like a new association. After all the other side most likely crashed and started back up again. So IF your restarted endpoint had sent: -----DATA:TSN=3D200-----> Which it would have since thats the initial TSN it declared in its INIT You would get back <--------SACK:200 But only after a data message had been sent. R On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote: > Hi , >=20 > I have a doubt regarding the value of the "Cumulative TSN Ack" in the = SACK message after restart of the peer. >=20 > what should be the value of the "Cumulative TSN Ack" in SACK message = for the DATA message received before=20 >=20 > peer re-started. >=20 > Please find the call flow for the scenario for more information. >=20 >=20 > Thanks, > Padmalochan > ----- Randall Stewart randall@lakerest.net From Michael.Tuexen@lurchi.franken.de Mon May 23 11:12:21 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68832E06B6 for ; Mon, 23 May 2011 11:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsPfyflUrg2H for ; Mon, 23 May 2011 11:12:21 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 86D67E0658 for ; Mon, 23 May 2011 11:12:20 -0700 (PDT) Received: from [192.168.1.195] (p508FA3FB.dip.t-dialin.net [80.143.163.251]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F0FF01C0C0BD6; Mon, 23 May 2011 20:12:15 +0200 (CEST) Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Mon, 23 May 2011 20:12:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EBAE8F1-D3E9-42A8-B093-700E71A92B22@lurchi.franken.de> References: To: Padmalochan Moharana X-Mailer: Apple Mail (2.1084) Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:12:21 -0000 On May 23, 2011, at 12:47 PM, Padmalochan Moharana wrote: > Hi , >=20 > I have a doubt regarding the value of the "Cumulative TSN Ack" in the = SACK message after restart of the peer. >=20 > what should be the value of the "Cumulative TSN Ack" in SACK message = for the DATA message received before=20 >=20 > peer re-started. When B processes the INIT, it does not change its state. I can only assume that the SACK is sent, for example, based on the SACK timeout or a window update. So cum_tsn would be 100. Please note that due to a vtag mismatch, endpoint A will silently discard the SACK. Best regards Michael >=20 > Please find the call flow for the scenario for more information. >=20 >=20 > Thanks, > Padmalochan > From Michael.Tuexen@lurchi.franken.de Mon May 23 11:16:41 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70974E07B8 for ; Mon, 23 May 2011 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHhYnvHsfZ4W for ; Mon, 23 May 2011 11:16:41 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7D931E07AC for ; Mon, 23 May 2011 11:16:40 -0700 (PDT) Received: from [192.168.1.195] (p508FA3FB.dip.t-dialin.net [80.143.163.251]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 080FA1C0B4606; Mon, 23 May 2011 20:16:38 +0200 (CEST) Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Mon, 23 May 2011 20:16:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1DE8F8E6-05A8-476B-822F-5B35A27C490E@lakerest.net> To: Randy Stewart X-Mailer: Apple Mail (2.1084) Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:16:41 -0000 On May 23, 2011, at 4:10 PM, Randy Stewart wrote: >=20 > On May 23, 2011, at 9:34 AM, Padmalochan Moharana wrote: >=20 >> Hi Randy, >>=20 >> Thanks for the response. In this case ENDPOINT A send INIT after = sending one DATA with TSN 100 to peer. So should end point B send SACK = for the received message after sending INIT ACK to endpoint A. Or = Endpoint should not send any SACK for the DATA received before restart = of endpoint A. >=20 > When the new INIT is sent it is the same as a brand new association. = Endpoint B > will NOT SACK about 100.. its the same as Endpoint B receiving an = ABORT and then > a new INIT. If B receives an INIT, it will not change its state. The SACK might be = sent, because due to the reception of the DATA chunk (TSN 100) a T2 timer was started. = So the SACK would have cum_tsn =3D 100. >=20 > In fact it is very very difficult to get Endpoint B NOT to receive an = ABORT. Really? If A is restarting (using the same port number as before), it would = receive a SACK with incorrect v-tag, but there is an association. So it would be silently discarded. Or am I missing something? >=20 > In your scenario, what you would more likely see is >=20 > -----DATA(TSN=3D100)----------------> > > <---------SACK(TSN=3D100)--------- > ------ABORT(NO-TCB FLAG)----------> > ------INIT----------------> Correct. But if the INIT was sent before the SACK was received, the SACK = is silently discarded. Best regards Michael >=20 >=20 > In past interop's the only way to get the restart to occur is to = unplug > the endpoint that you restart so it won't get a Heartbeat or a SACK to > cause it to generate an ABORT.. >=20 > R >=20 >=20 >>=20 >> Thanks, >> Padmalochan >>=20 >> On Mon, May 23, 2011 at 6:30 PM, Randy Stewart = wrote: >> Padmalochan: >>=20 >> I see the restart occur, but in your picture >> I see no data sent... Until data is sent after >> the restart you would not see a sack.. >>=20 >> A restart is like a new association. After all the >> other side most likely crashed and started back up again. >>=20 >> So IF your restarted endpoint had sent: >>=20 >> -----DATA:TSN=3D200-----> >>=20 >> Which it would have since thats the initial TSN it declared in its = INIT >>=20 >> You would get back >>=20 >> <--------SACK:200 >>=20 >> But only after a data message had been sent. >>=20 >> R >>=20 >>=20 >> On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote: >>=20 >>> Hi , >>>=20 >>> I have a doubt regarding the value of the "Cumulative TSN Ack" in = the SACK message after restart of the peer. >>>=20 >>> what should be the value of the "Cumulative TSN Ack" in SACK message = for the DATA message received before >>>=20 >>> peer re-started. >>>=20 >>> Please find the call flow for the scenario for more information. >>>=20 >>>=20 >>> Thanks, >>> Padmalochan >>> >>=20 >> ----- >> Randall Stewart >> randall@lakerest.net >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 >=20 >=20 From randall@lakerest.net Mon May 23 12:45:03 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99220E06CD for ; Mon, 23 May 2011 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfZrlyGRl6UW for ; Mon, 23 May 2011 12:45:03 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by ietfa.amsl.com (Postfix) with ESMTP id 19EDDE0809 for ; Mon, 23 May 2011 12:45:01 -0700 (PDT) Received: from [10.1.1.122] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p4NJiuBu005719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 May 2011 15:44:56 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Randy Stewart In-Reply-To: Date: Mon, 23 May 2011 15:44:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C957CB0-7079-4BB5-AF9E-5A978159C39B@lakerest.net> References: <1DE8F8E6-05A8-476B-822F-5B35A27C490E@lakerest.net> To: =?iso-8859-1?Q?Michael_T=FCxen?= X-Mailer: Apple Mail (2.1084) Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 19:45:03 -0000 On May 23, 2011, at 2:16 PM, Michael T=FCxen wrote: > On May 23, 2011, at 4:10 PM, Randy Stewart wrote: >=20 >>=20 >> On May 23, 2011, at 9:34 AM, Padmalochan Moharana wrote: >>=20 >>> Hi Randy, >>>=20 >>> Thanks for the response. In this case ENDPOINT A send INIT after = sending one DATA with TSN 100 to peer. So should end point B send SACK = for the received message after sending INIT ACK to endpoint A. Or = Endpoint should not send any SACK for the DATA received before restart = of endpoint A. >>=20 >> When the new INIT is sent it is the same as a brand new association. = Endpoint B >> will NOT SACK about 100.. its the same as Endpoint B receiving an = ABORT and then >> a new INIT. > If B receives an INIT, it will not change its state. The SACK might be = sent, because > due to the reception of the DATA chunk (TSN 100) a T2 timer was = started. So > the SACK would have cum_tsn =3D 100. Ahhh.. you are right here.. I was thinking of after the cookie... my bad ;-) >>=20 >> In fact it is very very difficult to get Endpoint B NOT to receive an = ABORT. > Really? > If A is restarting (using the same port number as before), it would = receive > a SACK with incorrect v-tag, but there is an association. So it would = be > silently discarded. Or am I missing something? I was thinking of when we tried to get restart to occur in the=20 interops.. we always had to pull the cable in order to get a HB or some other fun not coming in and causing an abort.. >>=20 >> In your scenario, what you would more likely see is >>=20 >> -----DATA(TSN=3D100)----------------> >> >> <---------SACK(TSN=3D100)--------- >> ------ABORT(NO-TCB FLAG)----------> >> ------INIT----------------> > Correct. But if the INIT was sent before the SACK was received, the = SACK is > silently discarded. Sure.. But the above scenario... actually more like: <-----Heartbeat() ----ABORT(no tcb)----> Is what we commonly saw at interops .. sometimes planned (sometimes not = :-D) R >=20 > Best regards > Michael >>=20 >>=20 >> In past interop's the only way to get the restart to occur is to = unplug >> the endpoint that you restart so it won't get a Heartbeat or a SACK = to >> cause it to generate an ABORT.. >>=20 >> R >>=20 >>=20 >>>=20 >>> Thanks, >>> Padmalochan >>>=20 >>> On Mon, May 23, 2011 at 6:30 PM, Randy Stewart = wrote: >>> Padmalochan: >>>=20 >>> I see the restart occur, but in your picture >>> I see no data sent... Until data is sent after >>> the restart you would not see a sack.. >>>=20 >>> A restart is like a new association. After all the >>> other side most likely crashed and started back up again. >>>=20 >>> So IF your restarted endpoint had sent: >>>=20 >>> -----DATA:TSN=3D200-----> >>>=20 >>> Which it would have since thats the initial TSN it declared in its = INIT >>>=20 >>> You would get back >>>=20 >>> <--------SACK:200 >>>=20 >>> But only after a data message had been sent. >>>=20 >>> R >>>=20 >>>=20 >>> On May 23, 2011, at 6:47 AM, Padmalochan Moharana wrote: >>>=20 >>>> Hi , >>>>=20 >>>> I have a doubt regarding the value of the "Cumulative TSN Ack" in = the SACK message after restart of the peer. >>>>=20 >>>> what should be the value of the "Cumulative TSN Ack" in SACK = message for the DATA message received before >>>>=20 >>>> peer re-started. >>>>=20 >>>> Please find the call flow for the scenario for more information. >>>>=20 >>>>=20 >>>> Thanks, >>>> Padmalochan >>>> >>>=20 >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> ----- >> Randall Stewart >> randall@lakerest.net >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 ----- Randall Stewart randall@lakerest.net From yjwei@cn.fujitsu.com Tue May 24 23:32:32 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE86E075E for ; Tue, 24 May 2011 23:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.65 X-Spam-Level: X-Spam-Status: No, score=-96.65 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_222=2.179, SARE_RECV_IP_222064=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAW-0VkmyO9B for ; Tue, 24 May 2011 23:32:31 -0700 (PDT) Received: from song.cn.fujitsu.com (unknown [222.73.24.84]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCD4E065B for ; Tue, 24 May 2011 23:32:31 -0700 (PDT) Received: from tang.cn.fujitsu.com (tang.cn.fujitsu.com [10.167.250.3]) by song.cn.fujitsu.com (Postfix) with ESMTP id 58532170145; Wed, 25 May 2011 14:32:26 +0800 (CST) Received: from mailserver.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1]) by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id p4P6WOfv026596; Wed, 25 May 2011 14:32:25 +0800 Received: from [10.167.226.141] ([10.167.226.141]) by mailserver.fnst.cn.fujitsu.com (Lotus Domino Release 8.5.1FP4) with ESMTP id 2011052514322658-386986 ; Wed, 25 May 2011 14:32:26 +0800 Message-ID: <4DDCA27A.6050209@cn.fujitsu.com> Date: Wed, 25 May 2011 14:32:26 +0800 From: Wei Yongjun User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: sandeep kandula Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2011-05-25 14:32:26, Serialize by Router on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2011-05-25 14:32:27, Serialize complete at 2011-05-25 14:32:27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 06:32:32 -0000 Hi, > Hi, > > > When peer restart happens and same identified at SCTP EndPoint B, all the queued data will be deleted at SCTP EndPoint B. > It also means we need to stop the SACK and T3-rtx timer when peer restart? If T3-rtx not been deleted, no data will be sent after the T3-rtx expire, but the cwnd will be set to PMTU. And also the T4-rto timer running for asconf, and all queued asconf check should be deleted? RFC does not describe about the timers when peer restart. > This is as good as tearing down the association and re-establishing association again. So, SCTP EndPoint B will not send any SACK for old data that received before peer restart. > > > Thanks, > > V Sandeep Kandula. > > > > On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana > wrote: > > Hi , > > I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer. > > what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before > > peer re-started. > > Please find the call flow for the scenario for more information. > > > Thanks, > Padmalochan > > > > From yjwei@cn.fujitsu.com Tue May 24 23:38:11 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C02E07B2 for ; Tue, 24 May 2011 23:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.65 X-Spam-Level: X-Spam-Status: No, score=-96.65 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_222=2.179, SARE_RECV_IP_222064=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LlgEh8+BLwN for ; Tue, 24 May 2011 23:38:10 -0700 (PDT) Received: from song.cn.fujitsu.com (unknown [222.73.24.84]) by ietfa.amsl.com (Postfix) with ESMTP id 837FCE075E for ; Tue, 24 May 2011 23:38:10 -0700 (PDT) Received: from tang.cn.fujitsu.com (tang.cn.fujitsu.com [10.167.250.3]) by song.cn.fujitsu.com (Postfix) with ESMTP id A8B8E170129; Wed, 25 May 2011 14:38:09 +0800 (CST) Received: from mailserver.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1]) by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id p4P6c86a026901; Wed, 25 May 2011 14:38:08 +0800 Received: from [10.167.226.141] ([10.167.226.141]) by mailserver.fnst.cn.fujitsu.com (Lotus Domino Release 8.5.1FP4) with ESMTP id 2011052514381076-387083 ; Wed, 25 May 2011 14:38:10 +0800 Message-ID: <4DDCA3D1.9050004@cn.fujitsu.com> Date: Wed, 25 May 2011 14:38:09 +0800 From: Wei Yongjun User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: sandeep kandula Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start References: <4DDCA27A.6050209@cn.fujitsu.com> In-Reply-To: <4DDCA27A.6050209@cn.fujitsu.com> X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2011-05-25 14:38:10, Serialize by Router on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2011-05-25 14:38:11, Serialize complete at 2011-05-25 14:38:11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 06:38:11 -0000 > Hi, > >> Hi, >> >> >> When peer restart happens and same identified at SCTP EndPoint B, all the queued data will be deleted at SCTP EndPoint B. >> > It also means we need to stop the SACK and T3-rtx timer when > peer restart? If T3-rtx not been deleted, no data will be sent > after the T3-rtx expire, but the cwnd will be set to PMTU. > And also the T4-rto timer running for asconf, and all queued ----------------------- > asconf check should be deleted? sorry, 'asconf check'- I want to say 'asconf chunks' ----------------------- > RFC does not describe about the timers when peer restart. > >> This is as good as tearing down the association and re-establishing association again. So, SCTP EndPoint B will not send any SACK for old data that received before peer restart. >> >> >> Thanks, >> >> V Sandeep Kandula. >> >> >> >> On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana > wrote: >> >> Hi , >> >> I have a doubt regarding the value of the "Cumulative TSN Ack" in the SACK message after restart of the peer. >> >> what should be the value of the "Cumulative TSN Ack" in SACK message for the DATA message received before >> >> peer re-started. >> >> Please find the call flow for the scenario for more information. >> >> >> Thanks, >> Padmalochan >> >> >> >> From Michael.Tuexen@lurchi.franken.de Wed May 25 04:51:51 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964E1E0657 for ; Wed, 25 May 2011 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMQy+QR4yUTj for ; Wed, 25 May 2011 04:51:51 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B0281E0618 for ; Wed, 25 May 2011 04:51:50 -0700 (PDT) Received: from [192.168.1.195] (p508FB19B.dip.t-dialin.net [80.143.177.155]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 569381C0C0BCF; Wed, 25 May 2011 13:51:47 +0200 (CEST) Subject: Re: Regarding Cumulative TSN Ack in the SACK after peer re-start Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4DDCA27A.6050209@cn.fujitsu.com> Date: Wed, 25 May 2011 13:51:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65C77E80-90BA-4815-90B1-B434B7D20356@lurchi.franken.de> References: <4DDCA27A.6050209@cn.fujitsu.com> To: Wei Yongjun X-Mailer: Apple Mail (2.1084) Cc: Vlad Yasevich , tsvwg , lksctp-developers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:51:51 -0000 On May 25, 2011, at 8:32 AM, Wei Yongjun wrote: > Hi, >=20 >> Hi, >>=20 >>=20 >> When peer restart happens and same identified at SCTP EndPoint B, all = the queued data will be deleted at SCTP EndPoint B. >>=20 >=20 > It also means we need to stop the SACK and T3-rtx timer when > peer restart? If T3-rtx not been deleted, no data will be sent > after the T3-rtx expire, but the cwnd will be set to PMTU. > And also the T4-rto timer running for asconf, and all queued > asconf check should be deleted? >=20 > RFC does not describe about the timers when peer restart. It is basically taking an assoc down and up... So all timers have to be = cleared. All retransmission counters also, and so on... Best regards Michael >=20 >> This is as good as tearing down the association and re-establishing = association again. So, SCTP EndPoint B will not send any SACK for old = data that received before peer restart. >>=20 >>=20 >> Thanks, >>=20 >> V Sandeep Kandula. =20 >>=20 >>=20 >>=20 >> On Mon, May 23, 2011 at 4:17 PM, Padmalochan Moharana = > wrote: >>=20 >> Hi , >>=20 >> I have a doubt regarding the value of the "Cumulative TSN Ack" in = the SACK message after restart of the peer. >>=20 >> what should be the value of the "Cumulative TSN Ack" in SACK = message for the DATA message received before >>=20 >> peer re-started. >>=20 >> Please find the call flow for the scenario for more information. >>=20 >>=20 >> Thanks, >> Padmalochan >>=20 >>=20 >>=20 >>=20 >=20 From fernando.gont.netbook.win@gmail.com Sat May 28 05:55:31 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B578E0693 for ; Sat, 28 May 2011 05:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlDxanCV-3hK for ; Sat, 28 May 2011 05:55:30 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 739F8E0662 for ; Sat, 28 May 2011 05:55:30 -0700 (PDT) Received: by wwa36 with SMTP id 36so1819469wwa.13 for ; Sat, 28 May 2011 05:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=k65vW8kOuUmwXb4e3gTUZuH/yeVWfY40vlik/us0V0s=; b=GaemGmhdLNc8rNjVWOyimsXL8EWx/dACft2OqpYPXU3gbx8YhhL1x2vxoRuJoJhyB6 80zSfs55U0od5J2Ts6AQ9nU31DSCHhY1ZqxD7FhW07ZZysxN9q4XUaJqc49YhwtDnhk/ pP1Ba3zDkKHL8yYhns772WsRdj0cOCY5ziUgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; b=skg7B3O2CfjGVGJYCMHdTK6/Pyg0nq3cQ2RVR2We7b/OK06eZsr3K7S2QYzURzZXJW GCnvYFMaapVUbwWNi2QeC5/jO+JMoNQmIvyGK2Hro46umAwGT7lJ9IrBloURMix1bcDO YoR8MP2GSTknG+LXs9xOBsxNWsun5rIuMkAz0= Received: by 10.216.235.133 with SMTP id u5mr672979weq.101.1306587329560; Sat, 28 May 2011 05:55:29 -0700 (PDT) Received: from [10.77.18.30] (94-116-18-30.dynamic.thecloud.net [94.116.18.30]) by mx.google.com with ESMTPS id e1sm1825747wbh.39.2011.05.28.05.55.28 (version=SSLv3 cipher=OTHER); Sat, 28 May 2011 05:55:29 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE0F0B1.40401@gont.com.ar> Date: Sat, 28 May 2011 09:55:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: tsvwg Subject: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source-quench) X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Anantha Ramaiah \(ananth\)" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 12:55:31 -0000 Folks, I'm planning to publish a revision of the aforementioned I-D, and the only remaining issue to address is the one that Anantha had raised. I've tried to get in touch with Anantha, but it seems he has been unreachable for the past few weeks. -- hence I'm sending this directly to the list. REgarding the rationale for deprecating ICMP SQs, I've thought about this one a little bit, and rather than getting into the reasons for which almost 20 years ago it was decided that ICMP SQ needed to be deprecated, I think a more sensible approach would be the following: * Note that ICMP SQ was deprecated almost 20 years ago, and include a reference for the documentation of the reasons (rather that including the reasons in this I-D) * Note that reaction to ICMP SQs should also be deprecated, because: - ICMP SQ has already been formally deprecated for routers - Virtually all popular host implementations have removed support for ICMP SQ at least since 2005 or so. - Widespread deployment of ICMP filtering would make it impossible to rely on ICMP for congestion control - the IETF has moved away from ICMP SQ for congestion-control -- e.g., development of ECN. -- as another data point, there's no ICMP SQ specified for IPv6. Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ananth@cisco.com Sat May 28 08:44:12 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F19E06CA for ; Sat, 28 May 2011 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDqWZ+FTUToN for ; Sat, 28 May 2011 08:44:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 82970E0664 for ; Sat, 28 May 2011 08:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2459; q=dns/txt; s=iport; t=1306597447; x=1307807047; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LkTys2Jo38aLYTfRS3GhhhiUSkJONCmcAmwLIoKw3Sc=; b=DtJF74tde/SAMv5lXy0an/wIX6oL+Nr3PlYA6ij8PCh4I2VG3X7BVGAW detfqOk8OqHrFpo+loAqrzfXAnRhwgtlSlgxS4GE7s94sacjtS8Z1hwN+ CJOrRHGOzWPIpB5kU9VLEweBSmlRk82Dl0Lb5kAiO/lWNTevzv71xvvjT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBADkX4U2rRDoI/2dsb2JhbABVl3GOTneoe5xshh4EhmSOMoQfhlQ X-IronPort-AV: E=Sophos;i="4.65,285,1304294400"; d="scan'208";a="325525437" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 28 May 2011 15:44:07 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4SFi7LQ015421; Sat, 28 May 2011 15:44:07 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 May 2011 08:44:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source-quench) Date: Sat, 28 May 2011 08:44:06 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CD7101C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4DE0F0B1.40401@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source-quench) Thread-Index: AcwdNofqzitlzmWgS7Czv+JbeHj+hgAFQ1+g References: <4DE0F0B1.40401@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , "tsvwg" X-OriginalArrivalTime: 28 May 2011 15:44:07.0213 (UTC) FILETIME=[144CBDD0:01CC1D4E] X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 15:44:12 -0000 Fernando, I just replied to your email which you sent directly to me. Your proposal below sounds good.=20 My point was that:- not all reasons pointed out by the reference makes sense and some of them sounds dubious to me, just my opinion. ( I had already mentioned why I think so) That said, I re-iterate :- I have no objections to the current document and the proposal below. I am done with the review. -Anantha PS:- my list problems ( I am unable to get emails sent to the tsvwg list) is still not been addressed! Anyways, I have re-subscribed to the list and I hope is is all fine now.. > -----Original Message----- > From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On > Behalf Of Fernando Gont > Sent: Saturday, May 28, 2011 5:55 AM > To: tsvwg > Cc: Anantha Ramaiah (ananth) > Subject: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source- > quench) >=20 > Folks, >=20 > I'm planning to publish a revision of the aforementioned I-D, and the > only remaining issue to address is the one that Anantha had raised. >=20 > I've tried to get in touch with Anantha, but it seems he has been > unreachable for the past few weeks. -- hence I'm sending this directly > to the list. >=20 > REgarding the rationale for deprecating ICMP SQs, I've thought about > this one a little bit, and rather than getting into the reasons for > which almost 20 years ago it was decided that ICMP SQ needed to be > deprecated, I think a more sensible approach would be the following: >=20 > * Note that ICMP SQ was deprecated almost 20 years ago, and include a > reference for the documentation of the reasons (rather that including > the reasons in this I-D) >=20 > * Note that reaction to ICMP SQs should also be deprecated, because: > - ICMP SQ has already been formally deprecated for routers > - Virtually all popular host implementations have removed support for > ICMP SQ at least since 2005 or so. > - Widespread deployment of ICMP filtering would make it impossible to > rely on ICMP for congestion control > - the IETF has moved away from ICMP SQ for congestion-control -- e.g., > development of ECN. -- as another data point, there's no ICMP SQ > specified for IPv6. >=20 > Thoughts? >=20 > Thanks! >=20 > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 From cpignata@cisco.com Sat May 28 17:04:19 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCA2E06BF for ; Sat, 28 May 2011 17:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.136 X-Spam-Level: X-Spam-Status: No, score=-107.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kl1+IBYg-GW for ; Sat, 28 May 2011 17:04:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id BEC00E0658 for ; Sat, 28 May 2011 17:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=1957; q=dns/txt; s=iport; t=1306627458; x=1307837058; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=UxvCIoam8I2jGgwVjJ22sZhb7twrBjbLQZTSzJttOF4=; b=btJc8fItu6rH7dM4IRvQUNGUMTL4ttzdFXs7IBP6tShbs2eA8LnGC3+K lpLTQ+iraJv2qzSMui8lIV9pGfqaFMvZB1Jze2zAxim0fUtZW9vl5aDjR KMHStDnGJbCOl3s3XVhMkyjKO0t6jR5Hzz4gdZzxHiEdt9WFk2nLVpT2C s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHAGSM4U2tJV2Z/2dsb2JhbABViRKcSWMCd4hxoEecToYeBJBPhEeGfYNy X-IronPort-AV: E=Sophos;i="4.65,287,1304294400"; d="scan'208";a="325637525" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 29 May 2011 00:04:18 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4T04HJf011116; Sun, 29 May 2011 00:04:17 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 May 2011 19:04:17 -0500 Received: from 144.254.231.94 ([144.254.231.94]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Sun, 29 May 2011 00:04:17 +0000 Subject: Re: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source-quench) References: <4DE0F0B1.40401@gont.com.ar> Content-Transfer-Encoding: quoted-printable From: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4DE0F0B1.40401@gont.com.ar> Thread-Topic: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source-quench) Thread-Index: Acwdk/Oxkdvakw2BQiqPJShP2QB1CQ== Message-ID: Date: Sat, 28 May 2011 20:04:07 -0400 To: "Fernando Gont" MIME-Version: 1.0 (iPhone Mail 8J2) X-OriginalArrivalTime: 29 May 2011 00:04:17.0747 (UTC) FILETIME=[F3F8D230:01CC1D93] Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 00:04:19 -0000 Fernando, Are you planning to add a "Deprecated" parenthetical qualifier to the IANA i= cmp-parameters entry an a pointer to this I-D? Perhaps you did it already in= a previous rev, in which case sorry, or perhaps it's overkill? I'd add it t= hough in IANA Considerations.=20 Thanks, Thumb typed by Carlos Pignataro. On May 28, 2011, at 8:55 AM, "Fernando Gont" wrote: > Folks, >=20 > I'm planning to publish a revision of the aforementioned I-D, and the > only remaining issue to address is the one that Anantha had raised. >=20 > I've tried to get in touch with Anantha, but it seems he has been > unreachable for the past few weeks. -- hence I'm sending this directly > to the list. >=20 > REgarding the rationale for deprecating ICMP SQs, I've thought about > this one a little bit, and rather than getting into the reasons for > which almost 20 years ago it was decided that ICMP SQ needed to be > deprecated, I think a more sensible approach would be the following: >=20 > * Note that ICMP SQ was deprecated almost 20 years ago, and include a > reference for the documentation of the reasons (rather that including > the reasons in this I-D) >=20 > * Note that reaction to ICMP SQs should also be deprecated, because: > - ICMP SQ has already been formally deprecated for routers > - Virtually all popular host implementations have removed support for > ICMP SQ at least since 2005 or so. > - Widespread deployment of ICMP filtering would make it impossible to > rely on ICMP for congestion control > - the IETF has moved away from ICMP SQ for congestion-control -- e.g., > development of ECN. -- as another data point, there's no ICMP SQ > specified for IPv6. >=20 > Thoughts? >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 From fernando.gont.netbook.win@gmail.com Sun May 29 12:17:45 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75A9E0655 for ; Sun, 29 May 2011 12:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IReQ1WbJ6C3o for ; Sun, 29 May 2011 12:17:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4174DE06B2 for ; Sun, 29 May 2011 12:17:39 -0700 (PDT) Received: by wyb29 with SMTP id 29so2612467wyb.31 for ; Sun, 29 May 2011 12:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=gImOZfBuWOC3Pp5QrpMV4C1XJ6A7C4UVg7lgVqK6Yvo=; b=LaDJS5dyxJwBssaeFTX7qnLjTZYWmD8i8FkZt5s8Rg7cx9CKuaRYOm2WnllByNASD3 YxmuW2+4AMxHPq5nCHqY9xswuaQhAO4OXGxNJrlqAY7WNz7qDVMq0B2G0oAjt7NnFgpx MTzI7+3pg5VjWpbdsqHU+jpV5zsAZCjElr0Cw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Mkf+ODHMkAgn6csE7dZi3+ccvCwsrkdlsFn6hfm99GtIk+vixo9Z7fzLj7Sh7Tihwp NLuEr7v3gxaz7PnoXm7F/ws623ZyBLekg2kdNIeCNX2A4wNLYIlgxO+ExvMk5mJS19xH XEww/HG9VcwIoQDe0IfSUhph8nrpe6cPGec2E= Received: by 10.227.57.143 with SMTP id c15mr4029608wbh.28.1306696658486; Sun, 29 May 2011 12:17:38 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id fw15sm2569205wbb.10.2011.05.29.12.17.37 (version=SSLv3 cipher=OTHER); Sun, 29 May 2011 12:17:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE29BCF.3080206@gont.com.ar> Date: Sun, 29 May 2011 16:17:35 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" Subject: Re: Upcoming rev of the ICMP SQ I-D (draft-ietf-tsvwg-source-quench) References: <4DE0F0B1.40401@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 19:17:45 -0000 Hi, Carlos, On 05/28/2011 09:04 PM, Carlos Pignataro (cpignata) wrote: > Are you planning to add a "Deprecated" parenthetical qualifier to the > IANA icmp-parameters entry an a pointer to this I-D? Yes. Sorry that I didn't mention this one (that you had already raised off-list). I think thought of this one as a no brainer (i.e., a nit), and was meaning to post a note about this one after addressing Anantha's comment. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From wwwrun@ietfa.amsl.com Tue May 31 11:20:45 2011 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 6B433E08CB; Tue, 31 May 2011 11:20:45 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Subject: WG Action: RECHARTER: Transport Area Working Group (tsvwg) Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110531182045.6B433E08CB@ietfa.amsl.com> Date: Tue, 31 May 2011 11:20:45 -0700 (PDT) Cc: gorry@erg.abdn.ac.uk, jmpolk@cisco.com, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:20:45 -0000 The Transport Area Working Group (tsvwg) working group in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Transport Area Working Group (tsvwg) ------------------------------ Current Status: Active Working Group Chairs: James Polk Gorry Fairhurst Transport Area Directors: Wesley Eddy David Harrington Transport Area Advisor: David Harrington Mailing Lists: General Discussion: tsvwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tsvwg Archive: http://www.ietf.org/mail-archive/web/tsvwg/ Description of Working Group: The Transport Area receives occasional proposals for the development and publication of RFCs dealing with transport topics that are not in scope of an existing working group or do not justify the formation of a new working group. TSVWG will serve as the forum for developing such work items in the IETF. The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. The currently active TSVWG work items mostly fall under the Following topics: (A) Maintenance of the Stream Control Transmission Protocol (SCTP), which involves bug fixes to the SCTP specifications and their progression along the standards track. This work item also includes a small number of modular extensions to SCTP. In order to maintain stable specifications, additional work on SCTP in TSVWG requires Area Director approval. (B) Maintenance of the Resource Reservation Protocol (RSVP) which involves bug fixes to RSVP specifications and their progression along the standards track. This work item may also include a small number of extensions to both RSVP and Integrated Services or advisory documents to address specific application scenarios. In order to maintain stable specifications, additional work on RSVP and/or Integrated Services in TSVWG requires Area Director approval. (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. (D) Selected other work items, which are mostly in TSVWG for historic reasons. Additional work that does not fall under one of the above topics in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: Done Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard Done Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard Done Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard Done Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard. Done Submit revised ID for ECN to IESG for consideration as a proposed standard Done Submit ID on UDP-lite to IESG for consideration as a proposed standard Done TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard Done Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard Done Submit 'Alternate Semantics for the ECN Field' to IESG for consideration as BCP Done Submit 'Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels' to IESG for consideration as PS Done Submit Submit 'QoS Signaling in a Nested Virtual Private Network' to IESG for consideration as Informational Done Submit 'Generic Aggregate RSVP Reservations' to IESG for consideration as PS Done Submit 'Quick-Start for TCP and IP' to IESG for consideration as Experimental Done Submit 'TCP Extended Statistics MIB' to IESG for consideration as PS Done Submit 'Authenticated Chunks for Stream Control Transmission Protocol' to IESG as consideration as PS Done Submit 'Padding Chunk and Parameter for SCTP' to IESG for consideration as PS Done Submit 'SCTP Dynamic Address Reconfiguration' to IESG for consideration as Proposed Standard Done Submit revision of 'Stream Control Transmission Protocol' to IESG for consideration as Proposed Standard Done Submit 'Security Attacks Found Against SCTP and Current Countermeasures' to IESG for consideration as Informational Done Submit 'Specifying New Congestion Control Algorithms' to IESG for consideration as Best Current Practice Done Submit 'Aggregation of DiffServ Service Classes' to IESG for consideration as Informational Done Submit 'Explicit Congestion Marking in MPLS' to IESG for consideration as Proposed Standard Done Submit 'User-Defined Errors for RSVP' to IESG for consideration as Proposed Standard Done Submit 'RSVP Extensions for Emergency Services' to IESG for consideration as Proposed Standard Done Submit 'DSCPs for Capacity-Admitted Traffic' to IESG for consideration as Proposed Standard Done Submit 'RSVP Proxy Approaches' to IESG for consideration as Informational Done Submit 'RSVP Extensions for Path-Triggered RSVP Receiver Proxy' to IESG for consideration as Proposed Standard Done Submit 'UDP Usage Guidelines for Application Designers' to IESG for consideration as Best Current Practice Done Request publication of 'Support for RSVP in Layer 3 VPNs' as Proposed Standard RFC Done Submit 'Port Randomization for Transport Protocols' to the IESG for consideration as a Best Current Practice Done Submit 'Applicability of Keying Methods for RSVP Security' to IESG for consideration as Informational Done Request publication of 'IANA Procedures for the Transport Protocol Port Number Space' as BCP RFC Done Request publication of 'Datagram Transport Layer Security for Stream Control Transmission' as Proposed Standard Done Request publication of 'Layered Encapsulation of Congestion Notification' as Proposed Standard Done Submit 'SCTP Chunk Flags Registration' to IESG for consideration as a Proposed Standard May 2011 Submit 'SCTP Stream Reconfiguration' to IESG for consideration as a Proposed Standard May 2011 Submit 'Sockets API Extensions for SCTP' to IESG for consideration as Informational Aug 2011 Submit 'Byte and Packet Congestion Notification' to IESG for consideration as Informational RFC Oct 2011 Submit 'Deprecation of ICMP Source Quench messages' to IESG for consideration as a Proposed Standard Dec 2011 Submit 'SCTP NAT Support' to IESG for consideration as a Proposed Standard