From ips-bounces@ietf.org Mon May 14 17:29:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hni7A-0007t7-2U; Mon, 14 May 2007 17:29:56 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hni79-0007sw-3w for ips-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 17:29:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hni78-0007so-Q7 for ips@ietf.org; Mon, 14 May 2007 17:29:54 -0400 Received: from mail0.lsil.com ([147.145.40.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hni77-00031c-4b for ips@ietf.org; Mon, 14 May 2007 17:29:54 -0400 Received: from milmhbs0.lsil.com (mhbs.lsil.com [147.145.1.30]) by mail0.lsil.com (8.12.11/8.12.11) with ESMTP id l4ELT3w8019671 for ; Mon, 14 May 2007 14:29:04 -0700 (PDT) Received: from namail.ad.lsil.com (namail.co.lsil.com [172.21.36.18]) by milmhbs0.lsil.com (8.12.11/8.12.11) with ESMTP id l4ELTl3F008554 for ; Mon, 14 May 2007 14:29:48 -0700 Received: from NAMAIL3.ad.lsil.com ([172.21.36.22]) by namail.ad.lsil.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 15:29:46 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7966E.FEBFC3DB" Date: Mon, 14 May 2007 15:29:43 -0600 Message-ID: <0F08E10B769EAF4EA2C43A573B8CC87FB5773D@NAMAIL3.ad.lsil.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Handling Expected-data-transfer-legnth and CDB transfer-len mismatch Thread-Index: AceWbvyiscMCg7HiQxqE/7MmDiDVww== From: "Qi, Yanling" To: X-OriginalArrivalTime: 14 May 2007 21:29:46.0934 (UTC) FILETIME=[FED5C560:01C7966E] X-Scanned-By: MIMEDefang 2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: c5b976cb26c967a52d72d6069c7fc54c Cc: "Qi, Yanling" Subject: [Ips] Handling Expected-data-transfer-legnth and CDB transfer-len mismatch X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7966E.FEBFC3DB Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7966E.FEBFC3DB" ------_=_NextPart_002_01C7966E.FEBFC3DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 We saw an initiator problem where the expected-data-transfer-length and transfer-len inside CDB got mismatched for a write-and-verify (10). The expected-data-transfer-length is 0x4000 but the transfer-len in the CDB is 0. The target completed the request with good status, turned Residual-underflow bit on and set residual-count=3D0x4000. See frames 16 and 38 in the attached ethereal trace file for details. Did the target handle this error condition correctly? =20 Thanks, =20 --yanling =20 Yanling Qi Engenio Storage Group - LSI Logic 512-794-3713 (Office) 512-794-3702 (Fax) yanling.qi@lsi.com =20 ------_=_NextPart_002_01C7966E.FEBFC3DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We saw an initiator problem where the expected-data-transfer-length and transfer-len inside CDB got mismatched = for a write-and-verify (10). The expected-data-transfer-length is 0x4000 but = the transfer-len in the CDB is 0. The target completed the request with good = status, turned Residual-underflow bit on and set residual-count=3D0x4000. See = frames 16 and 38 in the attached ethereal trace file for details. Did the target = handle this error condition correctly?

 

Thanks,

 

--yanling

 

Yanling Qi

Engenio Storage Group - LSI Logic

512-794-3713 (Office)

512-794-3702 (Fax)

yanling.qi@lsi.com

 

------_=_NextPart_002_01C7966E.FEBFC3DB-- ------_=_NextPart_001_01C7966E.FEBFC3DB Content-Type: application/octet-stream; name="expectedDataLength-transfer-len.pcap" Content-Transfer-Encoding: base64 Content-Description: expectedDataLength-transfer-len.pcap Content-Disposition: attachment; filename="expectedDataLength-transfer-len.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAA99lERiWmAQByAAAAcgAAAACguCAyfQAVxe1LLQgARQAA ZD9gQABABsCtCgoTYgoKExGJyQy8RDZefaRAZAGAGBhPOt0AAAEBCAoAuKLUAAAWVgGhAAAAACAA AAAAAAAAAAAAEYRjAABAAAAAtMoAALTMLggAALMAAAAAAAAAAAAAAPfZREYzpgEA6gUAAOoFAAAA oLggMn0AFcXtSy0IAEUABdw/YkAAQAa7MwoKE2IKChMRickMvEQ2Xq2kQGQBgBAYT0BVAAABAQgK ALii1AAAFlYAADvdAAAADQAAswD3+3uwRkTZUwAAAAAhbydeAADYNRAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswD3+3uwRkTZUwAAAAAh bydeAADYNQAAO90AAAANAACzAff7e7BGRNlTAAAAACFvJ14AAAMtEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzAff7e7BGRNlTAAAAACFv J14AAAMtAAA73QAAAA0AALMC9/t7sEZE2VMAAAAAIW8nXgAAZhQQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREY7pgEA6gUAAOoFAAAAoLggMn0AFcXt Sy0IAEUABdw/ZEAAQAa7MQoKE2IKChMRickMvEQ2ZFWkQGQBgBAYT0BVAAABAQgKALii1AAAFlYQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAA O90AAAANAACzAvf7e7BGRNlTAAAAACFvJ14AAGYUAAA73QAAAA0AALMD9/t7sEZE2VMAAAAAIW8n XgAAvQwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA7 3QAAAA0AALMD9/t7sEZE2VMAAAAAIW8nXgAAvQwAADvdAAAADQAAswT3+3uwRkTZUwAAAAAhbyde AACsZhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvd AAAADQAAswT3+3uwRkTZUwAAAAAhbydeAACsZgAAO90AAAANAACzBff7e7BGRNlTAAAAACFvJ14A AHd+EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREZCpgEA8gQAAPIEAAAAoLggMn0AFcXtSy0IAEUABOQ/ ZkAAQAa8JwoKE2IKChMRickMvEQ2af2kQGQBgBgYTz9dAAABAQgKALii1AAAFlYQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswX3+3uwRkTZUwAAAAAhbydeAAB3fgAAO90A AAANAACzBvf7e7BGRNlTAAAAACFvJ14AABJHEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzBvf7e7BGRNlTAAAAACFvJ14AABJHAAA73QAA AA0AALMH9/t7sEZE2VMAAAAAIW8nXgAAyV8QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMH9/t7sEZE2VMAAAAAIW8nXgAAyV/32URGTaYB AOoFAADqBQAAAKC4IDJ9ABXF7UstCABFAAXcP2hAAEAGuy0KChNiCgoTEYnJDLxENm6tpEBkAYAQ GE9AVQAAAQEICgC4otQAABZWAAA73QAAAA0AALMI9/t7sEZE2VMAAAAAIW8nXgAAMJMQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMI9/t7 sEZE2VMAAAAAIW8nXgAAMJMAADvdAAAADQAAswn3+3uwRkTZUwAAAAAhbydeAADrixAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswn3+3uw RkTZUwAAAAAhbydeAADriwAAO90AAAANAACzCvf7e7BGRNlTAAAAACFvJ14AAI6yEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGVKYBAOoFAADqBQAA AKC4IDJ9ABXF7UstCABFAAXcP2pAAEAGuysKChNiCgoTEYnJDLxENnRVpEBkAYAQGE9AVQAAAQEI CgC4otQAABZWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAAADvdAAAADQAAswr3+3uwRkTZUwAAAAAhbydeAACOsgAAO90AAAANAACzC/f7e7BG RNlTAAAAACFvJ14AAFWqEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEAAAO90AAAANAACzC/f7e7BGRNlTAAAAACFvJ14AAFWqAAA73QAAAA0AALMM9/t7sEZE 2VMAAAAAIW8nXgAARMAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQAAA73QAAAA0AALMM9/t7sEZE2VMAAAAAIW8nXgAARMAAADvdAAAADQAAsw33+3uwRkTZ UwAAAAAhbydeAACf2BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGWqYBAPIEAADyBAAAAKC4IDJ9ABXF 7UstCABFAATkP2xAAEAGvCEKChNiCgoTEYnJDLxENnn9pEBkAYAYGE8/XQAAAQEICgC4otQAABZW EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMN9/t7sEZE2VMAAAAAIW8n XgAAn9gAADvdAAAADQAAsw73+3uwRkTZUwAAAAAhbydeAAD64RAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAsw73+3uwRkTZUwAAAAAhbyde AAD64QAAO90AAAANAACzD/f7e7BGRNlTAAAAACFvJ14AACH5EBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzD/f7e7BGRNlTAAAAACFvJ14A ACH599lERpOmAQBCAAAAQgAAAAAVxe1LLQCguCAyfwgARQAANEVSAABABvrqCgoTEgoKE2IMvInK C14O+SYn3N+AEIAATm4AAAEBCAoAABZWALii1PfZREaepgEAQgAAAEIAAAAAFcXtSy0AoLggMn0I AEUAADRFUwAAQAb66goKExEKChNiDLyJyaRAZAFENl6tgBCAAMCoAAABAQgKAAAWVgC4otT32URG 5KYBAEIAAABCAAAAABXF7UstAKC4IDJ9CABFAAA0RVUAAEAG+ugKChMRCgoTYgy8icmkQGQBRDZp /YAQgAC1WAAAAQEICgAAFlYAuKLU99lERhenAQBCAAAAQgAAAAAVxe1LLQCguCAyfQgARQAANEVX AABABvrmCgoTEQoKE2IMvInJpEBkAUQ2dFWAEIAAqwAAAAEBCAoAABZWALii1PfZREYwpwEAQgAA AEIAAAAAFcXtSy0AoLggMn0IAEUAADRFWAAAQAb65QoKExEKChNiDLyJyaRAZAFENn6tgBCAAKCo AAABAQgKAAAWVgC4otT32URG1qcBAHIAAAByAAAAABXF7UstAKC4IDJ9CABFAABkRV8AAEAG+q4K ChMRCgoTYgy8icmkQGQBRDZ+rYAYgADamwAAAQEICgAAFlYAuKLUIYAAAAAAAAAAAAAAAAAAAAAR hGIAAAAAAAC0zAAAtMoAALZJAAAAAAAAAAAAAAAA99lERgSpAQByAAAAcgAAAACguCAyfwAVxe1L LQgARQAAZEN7QABABryRCgoTYgoKExKJygy8Jifc3wteDvmAGBgWOt4AAAEBCAoAuKLVAAAWVgHB AAAAAAAAAAIAAAAAAAAAEWJtAABAAAAAtMgAALTJKAAAALfAAAAgAAAAAAAAAPfZREY4qQEAFgEA ABYBAAAAFcXtSy0AoLggMn0IAEUAAQhFcQAAQAb5+AoKExEKChNiDLyJyaRAZDFENn6tgBiAABCu AAABAQgKAAAWVgC4otQhgAACAAAAogAAAAAAAAAAABGEYwAAAAAAALTNAAC0ywAAtkkAAAAAAAAA AAAAAAAAoHAABgAAAACYAAAAACkAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAIAQAALggAALMAAAAA AAAAAFNGNjQ1MDAwMDEgICAgICCWUBAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJhPMDUxMTA3LzE0NTYzMAAAAAAAAAAAAPfZ REZ9qQEAcgAAAHIAAAAAoLggMn0AFcXtSy0IAEUAAGQ/bkAAQAbAnwoKE2IKChMRickMvEQ2fq2k QGUFgBgYTzrdAAABAQgKALii1QAAFlYBoQAAAAAgAAAAAAAAAAAAABGEZAAAQAAAALTLAAC0zi4I AACzAAAAAAAAAAAAAAD32URGjKkBAOoFAADqBQAAAKC4IDJ9ABXF7UstCABFAAXcP3BAAEAGuyUK ChNiCgoTEYnJDLxENn7dpEBlBYAQGE9AVQAAAQEICgC4otUAABZWAAA73QAAAA0AALMA9/t7sEZE 2VMAAAAAIW8nXgAA2DUQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQAAA73QAAAA0AALMA9/t7sEZE2VMAAAAAIW8nXgAA2DUAADvdAAAADQAAswH3+3uwRkTZ UwAAAAAhbydeAAADLRAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAAADvdAAAADQAAswH3+3uwRkTZUwAAAAAhbydeAAADLQAAO90AAAANAACzAvf7e7BGRNlT AAAAACFvJ14AAGYUEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBD32URGlKkBAOoFAADqBQAAAKC4IDJ9ABXF7UstCABFAAXcP3JAAEAGuyMKChNiCgoTEYnJ DLxENoSFpEBlBYAQGE9AVQAAAQEICgC4otUAABZWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswL3+3uwRkTZUwAAAAAhbyde AABmFAAAO90AAAANAACzA/f7e7BGRNlTAAAAACFvJ14AAL0MEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzA/f7e7BGRNlTAAAAACFvJ14A AL0MAAA73QAAAA0AALME9/t7sEZE2VMAAAAAIW8nXgAArGYQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALME9/t7sEZE2VMAAAAAIW8nXgAA rGYAADvdAAAADQAAswX3+3uwRkTZUwAAAAAhbydeAAB3fhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URG nKkBAPIEAADyBAAAAKC4IDJ9ABXF7UstCABFAATkP3RAAEAGvBkKChNiCgoTEYnJDLxENootpEBl BYAYGE8/XQAAAQEICgC4otUAABZWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAA AA0AALMF9/t7sEZE2VMAAAAAIW8nXgAAd34AADvdAAAADQAAswb3+3uwRkTZUwAAAAAhbydeAAAS RxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAA DQAAswb3+3uwRkTZUwAAAAAhbydeAAASRwAAO90AAAANAACzB/f7e7BGRNlTAAAAACFvJ14AAMlf EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAAN AACzB/f7e7BGRNlTAAAAACFvJ14AAMlf99lERqapAQDqBQAA6gUAAACguCAyfQAVxe1LLQgARQAF 3D92QABABrsfCgoTYgoKExGJyQy8RDaO3aRAZQWAEBhPQFUAAAEBCAoAuKLVAAAWVgAAO90AAAAN AACzCPf7e7BGRNlTAAAAACFvJ14AADCTEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzCPf7e7BGRNlTAAAAACFvJ14AADCTAAA73QAAAA0A ALMJ9/t7sEZE2VMAAAAAIW8nXgAA64sQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMJ9/t7sEZE2VMAAAAAIW8nXgAA64sAADvdAAAADQAA swr3+3uwRkTZUwAAAAAhbydeAACOshAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQ99lERqypAQDqBQAA6gUAAACguCAyfQAVxe1LLQgARQAF3D94QABABrsd CgoTYgoKExGJyQy8RDaUhaRAZQWAEBhPQFUAAAEBCAoAuKLVAAAWVhAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMK9/t7sEZE 2VMAAAAAIW8nXgAAjrIAADvdAAAADQAAswv3+3uwRkTZUwAAAAAhbydeAABVqhAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswv3+3uwRkTZ UwAAAAAhbydeAABVqgAAO90AAAANAACzDPf7e7BGRNlTAAAAACFvJ14AAETAEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzDPf7e7BGRNlT AAAAACFvJ14AAETAAAA73QAAAA0AALMN9/t7sEZE2VMAAAAAIW8nXgAAn9gQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQ99lERrGpAQDyBAAA8gQAAACguCAyfQAVxe1LLQgARQAE5D96QABABrwTCgoTYgoKExGJ yQy8RDaaLaRAZQWAGBhPP10AAAEBCAoAuKLVAAAWVhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEAAAO90AAAANAACzDff7e7BGRNlTAAAAACFvJ14AAJ/YAAA73QAAAA0AALMO9/t7sEZE2VMA AAAAIW8nXgAA+uEQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQAAA73QAAAA0AALMO9/t7sEZE2VMAAAAAIW8nXgAA+uEAADvdAAAADQAAsw/3+3uwRkTZUwAA AAAhbydeAAAh+RAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAAADvdAAAADQAAsw/3+3uwRkTZUwAAAAAhbydeAAAh+ffZREaCqgEAQgAAAEIAAAAAFcXtSy0A oLggMn0IAEUAADRFfwAAQAb6vgoKExEKChNiDLyJyaRAZQVENoSFgBCAAJnLAAABAQgKAAAWVgC4 otX32URGvqoBAEIAAABCAAAAABXF7UstAKC4IDJ9CABFAAA0RYIAAEAG+rsKChMRCgoTYgy8icmk QGUFRDaO3YAQgACPcwAAAQEICgAAFlYAuKLV99lERherAQBCAAAAQgAAAAAVxe1LLQCguCAyfQgA RQAANEWFAABABvq4CgoTEQoKE2IMvInJpEBlBUQ2mi2AEIAAhCMAAAEBCAoAABZWALii1ffZREYC rAEA6gUAAOoFAAAAFcXtSy0AoLggMn8IAEUABdxFmAAAQAb0/AoKExIKChNiDLyJygteDvkmJ90P gBCAAM9LAAABAQgKAAAWVgC4otUlgQAAAABAAAAAAAAAAAAAABFibf////8AALTJAAC0yQAAtkcA AAAAAAAAAAAAAAAAADxbAAAADQAAt8D3W2uwRkTZ6gAAAAAhbydeAACR+BAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAAt8D3W2uwRkTZ6gAA AAAhbydeAACR+AAAPFsAAAANAAC3wfdba7BGRNnqAAAAACFvJ14AAErgEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3wfdba7BGRNnqAAAA ACFvJ14AAErgAAA8WwAAAA0AALfC91trsEZE2eoAAAAAIW8nXgAAL9kQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREYnrAEA6gUAAOoF AAAAFcXtSy0AoLggMn8IAEUABdxFmQAAQAb0+woKExIKChNiDLyJygteFKEmJ90PgBCAADbeAAAB AQgKAAAWVgC4otUQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EAAAPFsAAAANAAC3wvdba7BGRNnqAAAAACFvJ14AAC/ZAAA8WwAAAA0AALfD91trsEZE2eoAAAAA IW8nXgAA9MEQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ AAA8WwAAAA0AALfD91trsEZE2eoAAAAAIW8nXgAA9MEAADxbAAAADQAAt8T3W2uwRkTZ6gAAAAAh bydeAADlqxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAA ADxbAAAADQAAt8T3W2uwRkTZ6gAAAAAhbydeAADlqwAAPFsAAAANAAC3xfdba7BGRNnqAAAAACFv J14AAD6zEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREY5rAEAQgAAAEIAAAAAoLggMn8A FcXtSy0IAEUAADRDfUAAQAa8vwoKE2IKChMSicoMvCYn3Q8LXhpJgBAYFqrWAAABAQgKALii1gAA Flb32URGS6wBAOoFAADqBQAAABXF7UstAKC4IDJ/CABFAAXcRZoAAEAG9PoKChMSCgoTYgy8icoL XhpJJifdD4AQgADkQAAAAQEICgAAFlYAuKLVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA8WwAAAA0A ALfF91trsEZE2eoAAAAAIW8nXgAAPrMAADxbAAAADQAAt8b3W2uwRkTZ6gAAAAAhbydeAABbihAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAA t8b3W2uwRkTZ6gAAAAAhbydeAABbigAAPFsAAAANAAC3x/dba7BGRNnqAAAAACFvJ14AAICSEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3 x/dba7BGRNnqAAAAACFvJ14AAICSAAA8WwAAAA0AALfI91trsEZE2eoAAAAAIW8nXgAAeV4QEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGZqwB AOoFAADqBQAAABXF7UstAKC4IDJ/CABFAAXcRZsAAEAG9PkKChMSCgoTYgy8icoLXh/xJifdD4AQ gADlfwAAAQEICgAAFlYAuKLVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3yPdba7BGRNnqAAAAACFvJ14AAHleAAA8WwAAAA0AALfJ 91trsEZE2eoAAAAAIW8nXgAAokYQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQAAA8WwAAAA0AALfJ91trsEZE2eoAAAAAIW8nXgAAokYAADxbAAAADQAAt8r3 W2uwRkTZ6gAAAAAhbydeAADHfxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAAADxbAAAADQAAt8r3W2uwRkTZ6gAAAAAhbydeAADHfwAAPFsAAAANAAC3y/db a7BGRNnqAAAAACFvJ14AABxnEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGeawBAEIAAABCAAAA AKC4IDJ/ABXF7UstCABFAAA0Q39AAEAGvL0KChNiCgoTEonKDLwmJ90PC14lmYAQGBafhgAAAQEI CgC4otYAABZW99lERoysAQDqBQAA6gUAAAAVxe1LLQCguCAyfwgARQAF3EWcAABABvT4CgoTEgoK E2IMvInKC14lmSYn3Q+AEIAAbvgAAAEBCAoAABZWALii1RAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQAAA8WwAAAA0AALfL91trsEZE2eoAAAAAIW8nXgAAHGcAADxbAAAADQAAt8z3W2uwRkTZ6gAA AAAhbydeAAANDRAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAAADxbAAAADQAAt8z3W2uwRkTZ6gAAAAAhbydeAAANDQAAPFsAAAANAAC3zfdba7BGRNnqAAAA ACFvJ14AANYVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EAAAPFsAAAANAAC3zfdba7BGRNnqAAAAACFvJ14AANYVAAA8WwAAAA0AALfO91trsEZE2eoAAAAA 99lERrCsAQByAAAAcgAAAACguCAyfwAVxe1LLQgARQAAZEOBQABABryLCgoTYgoKExKJygy8Jifd DwteK0GAGBgWOt4AAAEBCAoAuKLWAAAWVgHBAAAAAAAAAAAAAAAAAAAAEWJuAAAA8AAAtMkAALTK EgHCAPAAAAAAAAAAAAAAAPfZREazrAEA6gUAAOoFAAAAFcXtSy0AoLggMn8IAEUABdxFnQAAQAb0 9woKExIKChNiDLyJygteK0EmJ90PgBCAADnsAAABAQgKAAAWVgC4otUhbydeAACzLBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAAt873W2uw RkTZ6gAAAAAhbydeAACzLAAAPFsAAAANAAC3z/dba7BGRNnqAAAAACFvJ14AAGg0EBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3z/dba7BG RNnqAAAAACFvJ14AAGg0AAA8WwAAAA0AALfQ91trsEZE2eoAAAAAIW8nXgAASKUQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEPfZREbZrAEA6gUAAOoFAAAAFcXtSy0AoLggMn8IAEUABdxFngAAQAb09goKExIKChNi DLyJygteMOkmJ90PgBCAALLjAAABAQgKAAAWVgC4otUQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEAAAPFsAAAANAAC30Pdba7BGRNnqAAAAACFvJ14AAEilAAA8WwAAAA0AALfR91trsEZE 2eoAAAAAIW8nXgAAk70QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQAAA8WwAAAA0AALfR91trsEZE2eoAAAAAIW8nXgAAk70AADxbAAAADQAAt9L3W2uwRkTZ 6gAAAAAhbydeAAD2hBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAAADxbAAAADQAAt9L3W2uwRkTZ6gAAAAAhbydeAAD2hAAAPFsAAAANAAC30/dba7BGRNnq AAAAACFvJ14AAC2cEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZ REbqrAEAQgAAAEIAAAAAoLggMn8AFcXtSy0IAEUAADRDg0AAQAa8uQoKE2IKChMSicoMvCYn3T8L XjaRgBAYFo5eAAABAQgKALii1gAAFlb32URG86wBAOoFAADqBQAAABXF7UstAKC4IDJ/CABFAAXc RZ8AAEAG9PUKChMSCgoTYgy8icoLXjaRJifdD4AQgAA9sgAAAQEICgAAFlYAuKLVEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA8 WwAAAA0AALfT91trsEZE2eoAAAAAIW8nXgAALZwAADxbAAAADQAAt9T3W2uwRkTZ6gAAAAAhbyde AAA89hAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxb AAAADQAAt9T3W2uwRkTZ6gAAAAAhbydeAAA89gAAPFsAAAANAAC31fdba7BGRNnqAAAAACFvJ14A AOfuEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsA AAANAAC31fdba7BGRNnqAAAAACFvJ14AAOfuAAA8WwAAAA0AALfW91trsEZE2eoAAAAAIW8nXgAA gtcQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBD32URG/KwBAHIAAAByAAAAABXF7UstAKC4IDJ9CABFAABkRaYAAEAG+mcK ChMRCgoTYgy8icmkQGUFRDae3YAYgAB5XAAAAQEICgAAFlYAuKLVIYIAAAAAAAAAAAAAAAAAAAAR hGQAAAAAAAC0zgAAtMwAALZLAAAAAAAAAAAAAEAA99lERiytAQDqBQAA6gUAAAAVxe1LLQCguCAy fwgARQAF3EWgAABABvT0CgoTEgoKE2IMvInKC148OSYn3Q+AEIAAQJ0AAAEBCAoAABZWALii1RAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAAt9b3W2uwRkTZ6gAA AAAhbydeAACC1wAAPFsAAAANAAC31/dba7BGRNnqAAAAACFvJ14AAFnPEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC31/dba7BGRNnqAAAA ACFvJ14AAFnPAAA8WwAAAA0AALfY91trsEZE2eoAAAAAIW8nXgAAoAMQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA8WwAAAA0AALfY91trsEZE2eoAAAAA IW8nXgAAoAMAADxbAAAADQAAt9n3W2uwRkTZ6gAAAAAhbydeAAB7GxAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQ99lERjatAQDqBQAA6gUAAAAVxe1LLQCguCAyfwgARQAF3EWh AABABvTzCgoTEgoKE2IMvInKC15B4SYn3Q+AEIAAFlYAAAEBCAoAABZWALii1RAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ AAA8WwAAAA0AALfZ91trsEZE2eoAAAAAIW8nXgAAexsAADxbAAAADQAAt9r3W2uwRkTZ6gAAAAAh bydeAAAeIhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAA ADxbAAAADQAAt9r3W2uwRkTZ6gAAAAAhbydeAAAeIgAAPFsAAAANAAC32/dba7BGRNnqAAAAACFv J14AAMU6EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAA PFsAAAANAAC32/dba7BGRNnqAAAAACFvJ14AAMU6AAA8WwAAAA0AALfc91trsEZE2eoAAAAAIW8n XgAA1FAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQ ------_=_NextPart_001_01C7966E.FEBFC3DB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C7966E.FEBFC3DB-- From ips-bounces@ietf.org Fri May 18 01:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoucT-00039G-IB; Fri, 18 May 2007 01:03:13 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HoucS-00037G-Mx for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 01:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoucS-000378-D2 for ips@ietf.org; Fri, 18 May 2007 01:03:12 -0400 Received: from m70095e42.tmodns.net ([66.94.9.112] helo=svcstsnq08.hotspot.t-mobile.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoucR-0006Mf-13 for ips@ietf.org; Fri, 18 May 2007 01:03:12 -0400 Received: from IVVTDKV0981 (32.115.224.10.in-addr.arpa [10.224.115.32]) by svcstsnq08.hotspot.t-mobile.com (8.13.7+Sun/8.12.10) with SMTP id l4I538MW010793; Thu, 17 May 2007 22:03:09 -0700 (PDT) Message-ID: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Ken Craig" , References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D444@MERCURY.inside.istor.com> Subject: Re: [Ips] StatSN question Date: Fri, 18 May 2007 01:03:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-0701160000 definitions=main-0702270060 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message ----- From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=0, send a DATA IN PDU with FINAL=1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 18 12:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5c1-0007cb-Qs; Fri, 18 May 2007 12:47:29 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hp5c0-0007Yx-Hx for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 12:47:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5c0-0007WX-37 for ips@ietf.org; Fri, 18 May 2007 12:47:28 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp5bx-0006Md-OC for ips@ietf.org; Fri, 18 May 2007 12:47:28 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 18 May 2007 09:47:25 -0700 X-IronPort-AV: i="4.14,553,1170662400"; d="scan'208"; a="3480865:sNHT30513830" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Ips] StatSN question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 May 2007 09:46:46 -0700 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D473@MERCURY.inside.istor.com> In-Reply-To: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] StatSN question Thread-Index: AceZCdZzk62cC/5PRRKW/k/D62yudAAYftpQ From: "Ken Craig" To: "Eddy Quicksall" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Eddy, Thanks for the response. I've got an Initiator that is updating ExpStatSn before receiving all of the data. I consider that Initiator to be broken but since the RFC doesn't specifically state what you said I've got no choice but to find a way to deal with it. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Thursday, May 17, 2007 10:03 PM To: Ken Craig; ips@ietf.org Subject: Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because=20 the target can use ExpStatSN to free the resources used to send the Data-in.=20 At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was=20 argument given once that the TCP ACK may not really indicate that the data=20 was received and hence the ExpStatSN would be used for that purpose (I don't=20 really remember that well though). Eddy ----- Original Message -----=20 From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=3D0, send a DATA IN PDU with FINAL=3D1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 18 15:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Pv-0003KP-Lv; Fri, 18 May 2007 15:47:11 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hp8Pu-0003KK-DU for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 15:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Pt-0003K9-QC for ips@ietf.org; Fri, 18 May 2007 15:47:09 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8Pt-0006g0-7p for ips@ietf.org; Fri, 18 May 2007 15:47:09 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4IJl8m3117086 for ; Fri, 18 May 2007 19:47:08 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4IJl8Q43985540 for ; Fri, 18 May 2007 21:47:08 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4IJl7HI028904 for ; Fri, 18 May 2007 21:47:08 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4IJl7pk028901; Fri, 18 May 2007 21:47:07 +0200 In-Reply-To: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com> To: "Eddy Quicksall" MIME-Version: 1.0 Subject: Re: [Ips] StatSN question X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Julian Satran Message-ID: Date: Fri, 18 May 2007 22:47:06 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 18/05/2007 22:47:06, Serialize complete at 18/05/2007 22:47:06 X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0903055467==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0903055467== Content-Type: multipart/alternative; boundary="=_alternative 003846BEC22572DF_=" This is a multipart message in MIME format. --=_alternative 003846BEC22572DF_= Content-Type: text/plain; charset="US-ASCII" ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task. It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function. Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done. Julo "Eddy Quicksall" 18/05/07 08:03 To "Ken Craig" , cc Subject Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message ----- From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=0, send a DATA IN PDU with FINAL=1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003846BEC22572DF_= Content-Type: text/html; charset="US-ASCII"
ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task.
It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function.
Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done.

Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

18/05/07 08:03

To
"Ken Craig" <kcraig@istor.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] StatSN question





It would mean the header and data has been received. The reason is because
the target can use ExpStatSN to free the resources used to send the Data-in.
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was
argument given once that the TCP ACK may not really indicate that the data
was received and hence the ExpStatSN would be used for that purpose (I don't
really remember that well though).

Eddy

----- Original Message -----
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 003846BEC22572DF_=-- --===============0903055467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0903055467==-- From ips-bounces@ietf.org Fri May 18 16:05:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8hW-0007dg-79; Fri, 18 May 2007 16:05:22 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hp8hV-0007bn-CE for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 16:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8hU-0007bf-Ql for ips@ietf.org; Fri, 18 May 2007 16:05:20 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8hT-0003Fh-1j for ips@ietf.org; Fri, 18 May 2007 16:05:20 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 18 May 2007 13:05:18 -0700 X-IronPort-AV: i="4.14,553,1170662400"; d="scan'208,217"; a="3482350:sNHT117541310" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Ips] StatSN question MIME-Version: 1.0 Date: Fri, 18 May 2007 13:05:17 -0700 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D475@MERCURY.inside.istor.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] StatSN question Thread-Index: AceZhVS82ubsRGV0Ttan5FjuqWTzjQAAhjIQ From: "Ken Craig" To: "Julian Satran" X-Spam-Score: 0.7 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0378481185==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0378481185== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79987.DB1B88EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79987.DB1B88EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julian, =20 When you say "target may discard whatever it may have hold for the task" aren't you saying the same thing as Eddy. That the ExpStatSN is an indication that the Initiator has also received the data since resources would have been used for the data. =20 Thanks, Ken Craig =20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Friday, May 18, 2007 12:47 PM To: Eddy Quicksall Cc: ips@ietf.org; Ken Craig Subject: Re: [Ips] StatSN question ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task.=20 It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function.=20 Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done.=20 =09 Julo=20 =09 =09 =09 "Eddy Quicksall" =20 18/05/07 08:03=20 To "Ken Craig" , =20 cc Subject Re: [Ips] StatSN question =09 It would mean the header and data has been received. The reason is because=20 the target can use ExpStatSN to free the resources used to send the Data-in.=20 At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was=20 argument given once that the TCP ACK may not really indicate that the data=20 was received and hence the ExpStatSN would be used for that purpose (I don't=20 really remember that well though). =09 Eddy =09 ----- Original Message -----=20 From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question =09 =09 I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. =09 I, as an iSCSI Target running at ERL=3D0, send a DATA IN PDU with FINAL=3D1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? =09 Thanks, Ken Craig =09 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C79987.DB1B88EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Julian,
 
When=20 you say "target may discard whatever it may = have
hold for the task" aren't you saying the same = thing=20 as
Eddy.  That the ExpStatSN is an = indication that=20 the
Initiator has also received the data since = resources=20 would
have been used for the=20 data.
 
Thanks,
Ken Craig
 
 
 -----Original = Message-----
From:=20 Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, = May 18,=20 2007 12:47 PM
To: Eddy Quicksall
Cc: ips@ietf.org; = Ken=20 Craig
Subject: Re: [Ips] StatSN = question


ExpStatSN indicates to the target that the initiator has = received the=20 status for the task and the target may discard whatever it may have = hold for=20 the task.
It also = indicates to to the=20 target when it is safe to send the response to a task abort or a = "group" abort=20 task management function.
Whether you=20 can you use TCP ack for the same pupose dependes on how you stack is = layered=20 and/or how your recovery from end-to-end errors is done. =

Julo


"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net>

18/05/07 08:03

To
"Ken Craig"=20 <kcraig@istor.com>, <ips@ietf.org>=20
cc
Subject
Re: [Ips] StatSN=20 question

=




It would mean the header and data has been received. The = reason is=20 because
the target can use ExpStatSN to free the resources used to = send=20 the Data-in.
At ERL 0 it is faster to just use the TCP ACK; for = ERL > 0=20 I think there was
argument given once that the TCP ACK may not = really=20 indicate that the data
was received and hence the ExpStatSN would = be used=20 for that purpose (I don't
really remember that well=20 though).

Eddy

----- Original Message -----
From: = "Ken Craig"=20 <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, = April=20 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a = question about what ExpStatSN means that
I can't find an answer for = in the=20 reflector archives
or in any of the RFCs.

I, as an iSCSI = Target=20 running at ERL=3D0, send a
DATA IN PDU with FINAL=3D1 and a StatSN = of 0.=20  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this = mean=20 that the Initiator has received
the PDU BHS and all of the data or = is it=20 simply
an acknowledgement that it has received the=20 PDU
BHS?

Thanks,
Ken=20 = Craig


_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

=00 ------_=_NextPart_001_01C79987.DB1B88EB-- --===============0378481185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0378481185==-- From ips-bounces@ietf.org Fri May 18 16:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8r8-0007GA-M4; Fri, 18 May 2007 16:15:18 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hp8r6-0007Bk-Og for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 16:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8r6-00078D-BG for ips@ietf.org; Fri, 18 May 2007 16:15:16 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8r5-0005DJ-GP for ips@ietf.org; Fri, 18 May 2007 16:15:16 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4IKFEQ4335014 for ; Fri, 18 May 2007 20:15:14 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4IKFEKU3985630 for ; Fri, 18 May 2007 22:15:14 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4IKFEst008035 for ; Fri, 18 May 2007 22:15:14 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4IKFE6e008032; Fri, 18 May 2007 22:15:14 +0200 In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D475@MERCURY.inside.istor.com> To: "Ken Craig" MIME-Version: 1.0 Subject: RE: [Ips] StatSN question X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Julian Satran Message-ID: Date: Fri, 18 May 2007 23:15:13 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 18/05/2007 23:15:13, Serialize complete at 18/05/2007 23:15:13 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0133712697==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0133712697== Content-Type: multipart/alternative; boundary="=_alternative 006F40B0C22572DF_=" This is a multipart message in MIME format. --=_alternative 006F40B0C22572DF_= Content-Type: text/plain; charset="US-ASCII" Definitely yes (acknowledging the status is equivalent to acking all the data). In addition resources are help to enable status retransmission even in commands that do not have data transfers. Julo "Ken Craig" 18/05/07 23:05 To Julian Satran/Haifa/IBM@IBMIL cc Subject RE: [Ips] StatSN question Julian, When you say "target may discard whatever it may have hold for the task" aren't you saying the same thing as Eddy. That the ExpStatSN is an indication that the Initiator has also received the data since resources would have been used for the data. Thanks, Ken Craig -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 18, 2007 12:47 PM To: Eddy Quicksall Cc: ips@ietf.org; Ken Craig Subject: Re: [Ips] StatSN question ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task. It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function. Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done. Julo "Eddy Quicksall" 18/05/07 08:03 To "Ken Craig" , cc Subject Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message ----- From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=0, send a DATA IN PDU with FINAL=1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 006F40B0C22572DF_= Content-Type: text/html; charset="US-ASCII"
Definitely yes (acknowledging the status is equivalent to acking all the data). In addition resources are help to enable status retransmission even in commands that do not have data transfers. Julo


"Ken Craig" <kcraig@istor.com>

18/05/07 23:05

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] StatSN question





Julian,
 
When you say "target may discard whatever it may have
hold for the task" aren't you saying the same thing as
Eddy.  That the ExpStatSN is an indication that the
Initiator has also received the data since resources would
have been used for the data.
 
Thanks,
Ken Craig
 
 
 -----Original Message-----
From:
Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent:
Friday, May 18, 2007 12:47 PM
To:
Eddy Quicksall
Cc:
ips@ietf.org; Ken Craig
Subject:
Re: [Ips] StatSN question


ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task.

It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function.

Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done.


Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

18/05/07 08:03


To
"Ken Craig" <kcraig@istor.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] StatSN question







It would mean the header and data has been received. The reason is because
the target can use ExpStatSN to free the resources used to send the Data-in.
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was
argument given once that the TCP ACK may not really indicate that the data
was received and hence the ExpStatSN would be used for that purpose (I don't
really remember that well though).

Eddy

----- Original Message -----
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips


--=_alternative 006F40B0C22572DF_=-- --===============0133712697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0133712697==-- From ips-bounces@ietf.org Sat May 19 16:05:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpVBJ-0000zN-FS; Sat, 19 May 2007 16:05:37 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HpVBI-0000xX-2o for ips-confirm+ok@megatron.ietf.org; Sat, 19 May 2007 16:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpVBH-0000w4-Ou for ips@ietf.org; Sat, 19 May 2007 16:05:35 -0400 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpVBF-0005Rk-6J for ips@ietf.org; Sat, 19 May 2007 16:05:35 -0400 Received: from ISCSIPerson@aol.com by imo-d05.mx.aol.com (mail_out_v38_r9.2.) id 9.d61.8adfc58 (60434); Sat, 19 May 2007 16:05:20 -0400 (EDT) Received: from mblk-r15 (mblk-r15.mblk.aol.com [152.163.211.206]) by ciaaol-d01.mail.aol.com (v115.11) with ESMTP id MAILCIAAOLD013-ec12464f5880182; Sat, 19 May 2007 16:05:20 -0400 To: Julian_Satran@il.ibm.com, kcraig@istor.com Subject: Re: [Ips] StatSN question Date: Sat, 19 May 2007 16:05:20 -0400 In-Reply-To: X-MB-Message-Source: WebUI Received: from 75.36.181.121 by mblk-r15.sysops.aol.com (152.163.211.206) with HTTP (WebMailUI); Sat, 19 May 2007 16:05:20 -0400 MIME-Version: 1.0 From: iscsiperson@aol.com X-MB-Message-Type: User X-Mailer: AOL WebMail 25698 Message-Id: <8C968682942742D-6E8-6589@mblk-r15.sysops.aol.com> X-AOL-IP: 152.163.211.206 X-Spam-Flag: NO X-Spam-Score: 0.4 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1464870895==" Errors-To: ips-bounces@ietf.org --===============1464870895== Content-Type: multipart/alternative; boundary="--------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com" ----------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" In the original message, Ken did NOT say that the "S" bit was set to 1 in the last Data-In PDU. According to the RFC (3270) - Section 10.7.3" "The fields StatSN, Status, and Residual Count only have meaningful content if the S bit is set to 1 and their values are defined in Section 10.4 SCSI Response." My interpretation of that section would be that the iSCSI Initiator should NOT have sent ExpStatSN=1, until the SCSI Response PDU was received. Take Care, Greg Alvey Solution Technoloy www.soltechnology.com -----Original Message----- From: Julian_Satran@il.ibm.com To: kcraig@istor.com Cc: ips@ietf.org Sent: Fri, 18 May 2007 1:15 PM Subject: RE: [Ips] StatSN question Definitely yes (acknowledging the status is equivalent to acking all the data). In addition resources are help to enable status retransmission even in commands that do not have data transfers. Julo "Ken Craig" 18/05/07 23:05 ToJulian Satran/Haifa/IBM@IBMIL cc SubjectRE: [Ips] StatSN question Julian, When you say "target may discard whatever it may have hold for the task" aren't you saying the same thing as Eddy. That the ExpStatSN is an indication that the Initiator has also received the data since resources would have been used for the data. Thanks, Ken Craig -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 18, 2007 12:47 PM To: Eddy Quicksall Cc: ips@ietf.org; Ken Craig Subject: Re: [Ips] StatSN question ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task. It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function. Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done. Julo "Eddy Quicksall" 18/05/07 08:03 To"Ken Craig" , cc SubjectRe: [Ips] StatSN question It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message ----- From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=0, send a DATA IN PDU with FINAL=1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. ----------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"
In the original message, Ken did NOT say that the "S" bit was set to 1 in the last Data-In PDU.
 
According to the RFC (3270) - Section 10.7.3"
 
"The fields StatSN, Status, and Residual Count only have meaningful content if the S bit is set to 1 and their values are defined in Section 10.4 SCSI Response."
 
My interpretation of that section would be that the iSCSI Initiator should NOT have sent ExpStatSN=1, until the SCSI Response PDU was received.
 
Take Care,
 
Greg Alvey
Solution Technoloy
 
 
-----Original Message-----
From: Julian_Satran@il.ibm.com
To: kcraig@istor.com
Cc: ips@ietf.org
Sent: Fri, 18 May 2007 1:15 PM
Subject: RE: [Ips] StatSN question


Definitely yes (acknowledging the status is equivalent to acking all the data). In addition resources are help to enable status retransmission even in commands that do not have data transfers. Julo


"Ken Craig" <kcraig@istor.com>
18/05/07 23:05
To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] StatSN question





Julian,
 
When you say "target may discard whatever it may have
hold for the task" aren't you saying the same thing as
Eddy.  That the ExpStatSN is an indication that the
Initiator has also received the data since resources would
have been used for the data.
 
Thanks,
Ken Craig
 
 
 -----Original Message-----
From:
Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent:
Friday, May 18, 2007 12:47 PM
To:
Eddy Quicksall
Cc:
ips@ietf.org; Ken Craig
Subject:
Re: [Ips] StatSN question


ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task.

It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function.

Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done.


Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
18/05/07 08:03

To
"Ken Craig" <kcraig@istor.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] StatSN question







It would mean the header and data has been received. The reason is because
the target can use ExpStatSN to free the resources used to send the Data-in.
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was
argument given once that the TCP ACK may not really indicate that the data
was received and hence the ExpStatSN would be used for that purpose (I don't
really remember that well though).

Eddy

----- Original Message -----
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
----------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com-- --===============1464870895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1464870895==-- From ips-bounces@ietf.org Sun May 20 22:34:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hpxj9-0005vx-92; Sun, 20 May 2007 22:34:27 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hpxj8-0005vs-8J for ips-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 22:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hpxj7-0005vk-PU for ips@ietf.org; Sun, 20 May 2007 22:34:25 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hpxj7-0004td-0i for ips@ietf.org; Sun, 20 May 2007 22:34:25 -0400 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id CADE61A4BFC; Sun, 20 May 2007 19:34:22 -0700 (PDT) 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: [Ips] StatSN question Date: Sun, 20 May 2007 19:34:18 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309901CCCEC5@aime2k302.adaptec.com> In-reply-to: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D473@MERCURY.inside.istor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] StatSN question Thread-Index: AceZCdZzk62cC/5PRRKW/k/D62yudAAYftpQAHiBRqA= References: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com> <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D473@MERCURY.inside.istor.com> From: "Sandars, Ken" To: "Ken Craig" , "Eddy Quicksall" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi Ken, Interesting initiator. If it is truly issuing an ExpStatSN which acknowledges a response which has not been sent by the target, the implementers should be directed to section 3.2.2.2 of RFC3720. Is it possible that the target is not initialising its StatSN counter correctly? Your example refers to a StatSN of 0 for the Data-In PDU (which I am assuming also has the S bit set). Have a read of section 10.13.4 and ensure the target is incrementing StatSN correctly. HTH, Ken -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com]=20 Sent: Saturday, 19 May 2007 02:47 To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Eddy, Thanks for the response. I've got an Initiator that is updating ExpStatSn before receiving all of the data. I consider that Initiator to be broken but since the RFC doesn't specifically state what you said I've got no choice but to find a way to deal with it. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, May 17, 2007 10:03 PM To: Ken Craig; ips@ietf.org Subject: Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because=20 the target can use ExpStatSN to free the resources used to send the Data-in.=20 At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was=20 argument given once that the TCP ACK may not really indicate that the data=20 was received and hence the ExpStatSN would be used for that purpose (I don't=20 really remember that well though). Eddy ----- Original Message -----=20 From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=3D0, send a DATA IN PDU with FINAL=3D1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon May 21 13:16:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqBUk-0006nJ-Ri; Mon, 21 May 2007 13:16:30 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HqBUi-0006ky-Tx for ips-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 13:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqBUh-0006jR-VQ for ips@ietf.org; Mon, 21 May 2007 13:16:28 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqBUh-000811-CV for ips@ietf.org; Mon, 21 May 2007 13:16:27 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 21 May 2007 10:16:25 -0700 X-IronPort-AV: i="4.14,562,1170662400"; d="scan'208"; a="3509595:sNHT38779220" 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: [Ips] StatSN question Date: Mon, 21 May 2007 10:16:24 -0700 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D47A@MERCURY.inside.istor.com> In-Reply-To: <368FBF3D8437A748BA8222526BF9309901CCCEC5@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] StatSN question Thread-Index: AceZCdZzk62cC/5PRRKW/k/D62yudAAYftpQAHiBRqAAHvrE0A== From: "Ken Craig" To: "Sandars, Ken" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Ken, My iSCSI Target has been working for the last couple of years with all of the Initiators I have been able to get a hold of. I guess I should have been more explicit in my example. The Initiator negotiated a 256K MaxRecvDataSegmentLength of 256K then sent a 128K Read command which allowed me to send all of the data in one PDU. The DATA IN PDU had the Status and Final bits set with Command Status of Good. It wasn't until I had a situation where a few of the Ethernet Frames with the rest of the data for this particular DATA IN PDU were stalled for ~.5 second (due to what I think was the Initiator not opening up its window size) that the problem was seen. =20 Ken Craig -----Original Message----- From: Sandars, Ken [mailto:ken_sandars@adaptec.com]=20 Sent: Sunday, May 20, 2007 7:34 PM To: Ken Craig; Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Hi Ken, Interesting initiator. If it is truly issuing an ExpStatSN which acknowledges a response which has not been sent by the target, the implementers should be directed to section 3.2.2.2 of RFC3720. Is it possible that the target is not initialising its StatSN counter correctly? Your example refers to a StatSN of 0 for the Data-In PDU (which I am assuming also has the S bit set). Have a read of section 10.13.4 and ensure the target is incrementing StatSN correctly. HTH, Ken -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com]=20 Sent: Saturday, 19 May 2007 02:47 To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Eddy, Thanks for the response. I've got an Initiator that is updating ExpStatSn before receiving all of the data. I consider that Initiator to be broken but since the RFC doesn't specifically state what you said I've got no choice but to find a way to deal with it. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, May 17, 2007 10:03 PM To: Ken Craig; ips@ietf.org Subject: Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because=20 the target can use ExpStatSN to free the resources used to send the Data-in.=20 At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was=20 argument given once that the TCP ACK may not really indicate that the data=20 was received and hence the ExpStatSN would be used for that purpose (I don't=20 really remember that well though). Eddy ----- Original Message -----=20 From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=3D0, send a DATA IN PDU with FINAL=3D1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 22 18:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdBp-0000Te-2h; Tue, 22 May 2007 18:50:49 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HqdB7-0007we-BB for ips-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqdB5-0007vo-KJ; Tue, 22 May 2007 18:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqdB5-0004RL-0o; Tue, 22 May 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A6AE126EA0; Tue, 22 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HqdB4-0000wd-HV; Tue, 22 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-08.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Corrections and Clarifications Author(s) : M. Chadalapaka Filename : draft-ietf-ips-iscsi-impl-guide-08.txt,.pdf Pages : 49 Date : 2007-5-22 iSCSI is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-impl-guide-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-22152049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-impl-guide-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-22152049.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed May 23 08:50:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqqIT-0003Bl-Kj; Wed, 23 May 2007 08:50:33 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HqqIS-0003Bg-GN for ips-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 08:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqqIS-0003BY-6N for ips@ietf.org; Wed, 23 May 2007 08:50:32 -0400 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqqIR-0007sU-PJ for ips@ietf.org; Wed, 23 May 2007 08:50:32 -0400 Received: from ibm64aec.bellsouth.net ([74.228.222.58]) by imf20aec.mail.bellsouth.net with ESMTP id <20070523125002.UGMH22883.imf20aec.mail.bellsouth.net@ibm64aec.bellsouth.net> for ; Wed, 23 May 2007 08:50:02 -0400 Received: from IVVTDKV0981 ([74.228.222.58]) by ibm64aec.bellsouth.net with SMTP id <20070523125001.BQHX2600.ibm64aec.bellsouth.net@IVVTDKV0981>; Wed, 23 May 2007 08:50:01 -0400 Message-ID: <002801c79d38$de1a3f60$05faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Ken Craig" , "Sandars, Ken" , References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D47A@MERCURY.inside.istor.com> Subject: Re: [Ips] StatSN question Date: Wed, 23 May 2007 08:49:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org It would behoove all of us if the initiator was fixed. We should not be adding code to overcome a bug in the initiator especially if it is hard to detect. Can you tell us the initiator so we can run tests too? Eddy ----- Original Message ----- From: "Ken Craig" To: "Sandars, Ken" ; Sent: Monday, May 21, 2007 1:16 PM Subject: RE: [Ips] StatSN question Ken, My iSCSI Target has been working for the last couple of years with all of the Initiators I have been able to get a hold of. I guess I should have been more explicit in my example. The Initiator negotiated a 256K MaxRecvDataSegmentLength of 256K then sent a 128K Read command which allowed me to send all of the data in one PDU. The DATA IN PDU had the Status and Final bits set with Command Status of Good. It wasn't until I had a situation where a few of the Ethernet Frames with the rest of the data for this particular DATA IN PDU were stalled for ~.5 second (due to what I think was the Initiator not opening up its window size) that the problem was seen. Ken Craig -----Original Message----- From: Sandars, Ken [mailto:ken_sandars@adaptec.com] Sent: Sunday, May 20, 2007 7:34 PM To: Ken Craig; Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Hi Ken, Interesting initiator. If it is truly issuing an ExpStatSN which acknowledges a response which has not been sent by the target, the implementers should be directed to section 3.2.2.2 of RFC3720. Is it possible that the target is not initialising its StatSN counter correctly? Your example refers to a StatSN of 0 for the Data-In PDU (which I am assuming also has the S bit set). Have a read of section 10.13.4 and ensure the target is incrementing StatSN correctly. HTH, Ken -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com] Sent: Saturday, 19 May 2007 02:47 To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Eddy, Thanks for the response. I've got an Initiator that is updating ExpStatSn before receiving all of the data. I consider that Initiator to be broken but since the RFC doesn't specifically state what you said I've got no choice but to find a way to deal with it. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, May 17, 2007 10:03 PM To: Ken Craig; ips@ietf.org Subject: Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message ----- From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=0, send a DATA IN PDU with FINAL=1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 23 13:29:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqueY-0003MO-DU; Wed, 23 May 2007 13:29:38 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HqueX-0003MJ-VH for ips-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 13:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqueX-0003MB-Le for ips@ietf.org; Wed, 23 May 2007 13:29:37 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqueX-0005TK-77 for ips@ietf.org; Wed, 23 May 2007 13:29:37 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 23 May 2007 10:29:32 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="3529754:sNHT55590760" 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: [Ips] StatSN question Date: Wed, 23 May 2007 10:29:32 -0700 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D482@MERCURY.inside.istor.com> In-Reply-To: <002801c79d38$de1a3f60$05faa8c0@ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] StatSN question Thread-Index: AcedOPOtE+b6s9YxSG6GZ8DPlvxFSQAJt2Og From: "Ken Craig" To: "Eddy Quicksall" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Eddy, The person in my organization that has all of the pertinent information is out of the office until next week so I won't be able to get it to you until then. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, May 23, 2007 5:50 AM To: Ken Craig; Sandars, Ken; ips@ietf.org Subject: Re: [Ips] StatSN question It would behoove all of us if the initiator was fixed. We should not be=20 adding code to overcome a bug in the initiator especially if it is hard to=20 detect. Can you tell us the initiator so we can run tests too? Eddy ----- Original Message -----=20 From: "Ken Craig" To: "Sandars, Ken" ; Sent: Monday, May 21, 2007 1:16 PM Subject: RE: [Ips] StatSN question Ken, My iSCSI Target has been working for the last couple of years with all of the Initiators I have been able to get a hold of. I guess I should have been more explicit in my example. The Initiator negotiated a 256K MaxRecvDataSegmentLength of 256K then sent a 128K Read command which allowed me to send all of the data in one PDU. The DATA IN PDU had the Status and Final bits set with Command Status of Good. It wasn't until I had a situation where a few of the Ethernet Frames with the rest of the data for this particular DATA IN PDU were stalled for ~.5 second (due to what I think was the Initiator not opening up its window size) that the problem was seen. Ken Craig -----Original Message----- From: Sandars, Ken [mailto:ken_sandars@adaptec.com] Sent: Sunday, May 20, 2007 7:34 PM To: Ken Craig; Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Hi Ken, Interesting initiator. If it is truly issuing an ExpStatSN which acknowledges a response which has not been sent by the target, the implementers should be directed to section 3.2.2.2 of RFC3720. Is it possible that the target is not initialising its StatSN counter correctly? Your example refers to a StatSN of 0 for the Data-In PDU (which I am assuming also has the S bit set). Have a read of section 10.13.4 and ensure the target is incrementing StatSN correctly. HTH, Ken -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com] Sent: Saturday, 19 May 2007 02:47 To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Eddy, Thanks for the response. I've got an Initiator that is updating ExpStatSn before receiving all of the data. I consider that Initiator to be broken but since the RFC doesn't specifically state what you said I've got no choice but to find a way to deal with it. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, May 17, 2007 10:03 PM To: Ken Craig; ips@ietf.org Subject: Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message -----=20 From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=3D0, send a DATA IN PDU with FINAL=3D1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 24 00:31:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr4yr-0001Q7-Vq; Thu, 24 May 2007 00:31:17 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hr4yr-0001P4-3c for ips-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 00:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr4yq-0001Ow-Q1 for ips@ietf.org; Thu, 24 May 2007 00:31:16 -0400 Received: from imf23aec.mail.bellsouth.net ([205.152.59.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr4yq-0006D9-Ci for ips@ietf.org; Thu, 24 May 2007 00:31:16 -0400 Received: from ibm66aec.bellsouth.net ([74.228.222.58]) by imf23aec.mail.bellsouth.net with ESMTP id <20070524043115.UUYS17388.imf23aec.mail.bellsouth.net@ibm66aec.bellsouth.net> for ; Thu, 24 May 2007 00:31:15 -0400 Received: from IVVTDKV0981 ([74.228.222.58]) by ibm66aec.bellsouth.net with SMTP id <20070524043113.EPOM19701.ibm66aec.bellsouth.net@IVVTDKV0981>; Thu, 24 May 2007 00:31:13 -0400 Message-ID: <001e01c79dbc$5c91f3f0$05faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Qi, Yanling" , References: <0F08E10B769EAF4EA2C43A573B8CC87FB5773D@NAMAIL3.ad.lsil.com> Subject: Re: [Ips] Handling Expected-data-transfer-legnth and CDB transfer-lenmismatch Date: Thu, 24 May 2007 00:31:08 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: "Qi, Yanling" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424455744==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0424455744== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C79D9A.D2532FE0" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C79D9A.D2532FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the trace, the initiator sent 0x2000 bytes of immediate data. = The target did not request anymore data because the count was 0. So U = with a residual of 0x4000 is correct. The target would just discard the = immediate data. It is legal to write 0 bytes with a WRITE (10) and WRITE = AND VERITY (10) refers back to that.=20 The iSCSI layer is not required to check the Expected Data Transfer = Length against the CDB (to do so would require that the iSCSI layer = understand all of the CDB's). I don't recall seeing any requirement for = the Device Server to check the CDB against the Expected Data Transfer = Length either. Eddy ----- Original Message -----=20 From: Qi, Yanling=20 To: ips@ietf.org=20 Cc: Qi, Yanling=20 Sent: Monday, May 14, 2007 5:29 PM Subject: [Ips] Handling Expected-data-transfer-legnth and CDB = transfer-lenmismatch Hi All, =20 We saw an initiator problem where the expected-data-transfer-length = and transfer-len inside CDB got mismatched for a write-and-verify (10). = The expected-data-transfer-length is 0x4000 but the transfer-len in the = CDB is 0. The target completed the request with good status, turned = Residual-underflow bit on and set residual-count=3D0x4000. See frames 16 = and 38 in the attached ethereal trace file for details. Did the target = handle this error condition correctly? =20 Thanks, =20 --yanling =20 Yanling Qi Engenio Storage Group - LSI Logic 512-794-3713 (Office) 512-794-3702 (Fax) yanling.qi@lsi.com =20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_001B_01C79D9A.D2532FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looking at the trace, the = initiator=20 sent 0x2000 bytes of immediate data. The target did not request anymore = data=20 because the count was 0. So U with a residual of 0x4000 is correct. = The=20 target would just discard the immediate data. It is legal to = write 0=20 bytes with a WRITE (10) and WRITE AND VERITY (10) refers back to = that.=20
 
The iSCSI layer is not = required to=20 check the Expected Data Transfer Length against the CDB (to do so would = require=20 that the iSCSI layer understand all of the CDB's). I don't recall seeing any = requirement for the=20 Device Server to check the CDB against the Expected Data Transfer Length = either.
 
Eddy
----- Original Message -----
From:=20 Qi, = Yanling=20
Sent: Monday, May 14, 2007 5:29 = PM
Subject: [Ips] Handling=20 Expected-data-transfer-legnth and CDB transfer-lenmismatch

Hi=20 All,

 

We saw an initiator = problem where=20 the expected-data-transfer-length and transfer-len inside CDB got = mismatched=20 for a write-and-verify (10). The expected-data-transfer-length is = 0x4000 but=20 the transfer-len in the CDB is 0. The target completed the request = with good=20 status, turned Residual-underflow bit on and set = residual-count=3D0x4000. See=20 frames 16 and 38 in the attached ethereal trace file for details. Did = the=20 target handle this error condition = correctly?

 

Thanks,

 

--yanling

 

Yanling Qi

Engenio Storage Group - LSI=20 Logic

512-794-3713 = (Office)

512-794-3702 = (Fax)

yanling.qi@lsi.com

 


_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_001B_01C79D9A.D2532FE0-- --===============0424455744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0424455744==-- From ips-bounces@ietf.org Thu May 24 10:41:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEVj-0000GL-No; Thu, 24 May 2007 10:41:51 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HrEVi-0000GD-Oj for ips-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 10:41:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEVh-0000G5-MX; Thu, 24 May 2007 10:41:50 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HrEVg-0006Rj-E6; Thu, 24 May 2007 10:41:49 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5A8602ACB2; Thu, 24 May 2007 14:41:18 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HrEVC-0005KC-3L; Thu, 24 May 2007 10:41:18 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 24 May 2007 10:41:18 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ips@ietf.org Subject: [Ips] Last Call: draft-ietf-ips-iscsi-impl-guide (iSCSI Corrections and Clarifications) to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has received a request from the IP Storage WG (ips) to consider the following document: - 'iSCSI Corrections and Clarifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13381&rfc_flag=0 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 31 18:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htsvt-0003ZR-TB; Thu, 31 May 2007 18:15:49 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Htsvt-0003ZF-61 for ips-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htsvs-0003Z6-SQ for ips@ietf.org; Thu, 31 May 2007 18:15:48 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htsvs-0001wi-Ed for ips@ietf.org; Thu, 31 May 2007 18:15:48 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 31 May 2007 15:15:48 -0700 X-IronPort-AV: i="4.16,370,1175497200"; d="scan'208"; a="3595985:sNHT59336620" Content-class: urn:content-classes:message Subject: RE: [Ips] StatSN question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 May 2007 15:15:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D497@MERCURY.inside.istor.com> In-Reply-To: <002801c79d38$de1a3f60$05faa8c0@ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] StatSN question Thread-Index: AcedOPOtE+b6s9YxSG6GZ8DPlvxFSQGl8lBA From: "Ken Craig" To: "Eddy Quicksall" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Eddy, The iSCSI initiator that we have confirmed sends updated ExpStatSN before receiving all of the data is from SourceForge. The name of the project on SourceForge is "linux-iscsi". The version that we looked at the source code for is 4.0.2. I also had a mistake in my detailed example. The Initiator negotiated a 128K MaxRecvDataSegmentLength instead of the 256K I mentioned. That doesn't change anything since the command that turned up the issue was a 128K Read. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, May 23, 2007 5:50 AM To: Ken Craig; Sandars, Ken; ips@ietf.org Subject: Re: [Ips] StatSN question It would behoove all of us if the initiator was fixed. We should not be=20 adding code to overcome a bug in the initiator especially if it is hard to=20 detect. Can you tell us the initiator so we can run tests too? Eddy ----- Original Message -----=20 From: "Ken Craig" To: "Sandars, Ken" ; Sent: Monday, May 21, 2007 1:16 PM Subject: RE: [Ips] StatSN question Ken, My iSCSI Target has been working for the last couple of years with all of the Initiators I have been able to get a hold of. I guess I should have been more explicit in my example. The Initiator negotiated a 256K MaxRecvDataSegmentLength of 256K then sent a 128K Read command which allowed me to send all of the data in one PDU. The DATA IN PDU had the Status and Final bits set with Command Status of Good. It wasn't until I had a situation where a few of the Ethernet Frames with the rest of the data for this particular DATA IN PDU were stalled for ~.5 second (due to what I think was the Initiator not opening up its window size) that the problem was seen. Ken Craig -----Original Message----- From: Sandars, Ken [mailto:ken_sandars@adaptec.com] Sent: Sunday, May 20, 2007 7:34 PM To: Ken Craig; Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Hi Ken, Interesting initiator. If it is truly issuing an ExpStatSN which acknowledges a response which has not been sent by the target, the implementers should be directed to section 3.2.2.2 of RFC3720. Is it possible that the target is not initialising its StatSN counter correctly? Your example refers to a StatSN of 0 for the Data-In PDU (which I am assuming also has the S bit set). Have a read of section 10.13.4 and ensure the target is incrementing StatSN correctly. HTH, Ken -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com] Sent: Saturday, 19 May 2007 02:47 To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] StatSN question Eddy, Thanks for the response. I've got an Initiator that is updating ExpStatSn before receiving all of the data. I consider that Initiator to be broken but since the RFC doesn't specifically state what you said I've got no choice but to find a way to deal with it. Ken Craig -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, May 17, 2007 10:03 PM To: Ken Craig; ips@ietf.org Subject: Re: [Ips] StatSN question It would mean the header and data has been received. The reason is because the target can use ExpStatSN to free the resources used to send the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was argument given once that the TCP ACK may not really indicate that the data was received and hence the ExpStatSN would be used for that purpose (I don't really remember that well though). Eddy ----- Original Message -----=20 From: "Ken Craig" To: Sent: Friday, April 27, 2007 5:23 PM Subject: [Ips] StatSN question I have a question about what ExpStatSN means that I can't find an answer for in the reflector archives or in any of the RFCs. I, as an iSCSI Target running at ERL=3D0, send a DATA IN PDU with FINAL=3D1 and a StatSN of 0. I receive a SCSI CMD PDU with an ExpStatSN of 1. Does this mean that the Initiator has received the PDU BHS and all of the data or is it simply an acknowledgement that it has received the PDU BHS? Thanks, Ken Craig _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips