From ips-bounces@ietf.org Wed Sep 22 01:24:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02592 for ; Wed, 22 Sep 2004 01:24:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9ziI-0006dn-AY for ips-web-archive@ietf.org; Wed, 22 Sep 2004 01:30:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9zXJ-0005mx-PQ; Wed, 22 Sep 2004 01:19:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9zSd-0004tn-S7 for ips@megatron.ietf.org; Wed, 22 Sep 2004 01:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02088 for ; Wed, 22 Sep 2004 01:14:34 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9zZ9-0006Uy-3Q for ips@ietf.org; Wed, 22 Sep 2004 01:21:19 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id B494E6082 for ; Tue, 21 Sep 2004 22:14:28 -0700 (PDT) Received: from [127.0.0.1] (palnai12-566.corp.hp.com [15.244.194.54]) by rosemail.rose.hp.com (Postfix) with ESMTP id 32F0B7FF9 for ; Tue, 21 Sep 2004 22:14:28 -0700 (PDT) Message-ID: <41510A2E.7050306@rose.hp.com> Date: Tue, 21 Sep 2004 22:14:22 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] I-D ACTION:draft-ietf-ips-iwarp-da-00.txt - Flow Control References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Mike is right about the "demand" part, I wasn't planning on adding the suggested text verbatim for that reason ("along these lines"). The text I had planned to add is the following: "In order to meet the functional requirements listed in this section, certain Datamover protocols may require pre-posted buffers from the local iSCSI protocol layer via mechanisms outside the scope of this document and in some implementations, the absence of such buffers may result in a connection failure. Datamover protocols may also realize these functional requirements via methods not explicitly listed in this document." Regarding implications to iSER especially, I do not think there are any. Wearing the iSER co-author's hat, I think iSER has the right approach to flow control. I thought the previous iSER flow control threads generally agreed that it's the case. And finally, I do not believe this is a change per se either. The architecture draft from the beginning intended to leave the flexibility of a specific approach to each Datamover protocol spec. The new text is only making that intent explicit. For the same reason, I personally think we wouldn't lose anything important if the new text isn't added. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > I am uncomfortable with adding the statement that "the Datamover MAY > demand pre-posted buffers for all iSCSI PDUs". What mechanisms will be > available to the datatmover to allow it to determine how many pre-posted > buffers it should "demand" and when it should "demand" the buffers? Are > we revisiting the idea of setting limits on the number of async messages, > immediate commands, etc.? Before we start changing the Datamover > Architecture, I think we ought to understand the implication of the > changes first. > > Mike > Sent by: ips-bounces@ietf.org > To: ips@ietf.org > cc: > Subject: Re: [Ips] I-D ACTION:draft-ietf-ips-iwarp-da-00.txt - Flow > Control > > > > >>Of course a Datamover could be using a transport with flow-control, in >>which >>case it will not have to demand pre-posted buffers. But it should be > > made > >>clear that the Datamover MAY demand pre-posted buffers for all iSCSI >>PDUs and that absence of a buffer MAY result in a connection failure. > > > Okay, I can add some text to the next draft along these lines unless > someone objects. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > > > Caitlin Bestler wrote: > > >>On Sep 15, 2004, at 12:27 AM, Mallikarjun C. wrote: >> >> >>>Caitlin, >>> >>> >>> >>>>In my opinion the absence of enabling language >>>>would actually forbid some of the solutions you listed. >>> >>>It was not intended to. I am open to making changes if you can >>>identify the specific >>>DA language that actually forbids the options that I listed. >> >> >>The term guarantee mandates that barring factors outside of its control, >>such as >>a transport layer error, that the Datamover MUST implement algorithms >>that will >>actually guarantee delivery. >> >>There are only two ways to accomplish that: stalling transmits, and >>demanding >>that the iSCSI layer take deliver of iSCSI PDUs on demand (that is the >>interface >>at the receiving end is a push rather than a pull), or that there be >>flow control >>which will prevent requests from being sent (either by blocking until >>they can >>be sent, or by denying a request and making the consumer try again > > later). > >>A TCP transport accomplishes the pacing at the sending end, that is the >>sender >>is either blocked or temporarily denied (depending on whether the socket > > is > >>blocking or non-blocking). >> >>But that is not how any existing iWarp local interface works. They > > assume > >>that the poster has knowledge that there is a buffer available at the >>other end, >>and that if the poster is wrong in that assumption it is a ULP error >>that warrants >>breaking the connection. (Yes, the implementation is allowed to try to >>recover >>from the fault, but it is an application fault and the application is >>not guaranteed >>that their mistake will be covered). >> >>So an iWarp Datamover is incapable of guaranteeing delivery unless the >>caveat >>is added that there is a valid reason to believe that there is a waiting >>buffer at >>the other end. Shifting the language to reflect that reality won't have >>that much >>impact, because iSCSI already requires the sender to have one form of >>credit >>or another for nearly all iSCSI PDUs. >> >>The other possible solution is to require to deliver the iSCSI PDU to >>the iSCSI >>layer without a receiving buffer. That is, the iSCSI layer MUST accept >>callbacks >>that deliver iSCSI PDUs at line rate. And if *it* wants to drop the >>connection >>because it doesn't have a buffer for them, then it isn't the Datamover > > that > >>is failing to deliver on its guarantee. >> >>That option is actually compatible with the wire protocol, but it is not >>compatible >>with any of the published APIs or verbs for iWarp (or InfiniBand for >>that matter). >> >> >>One possible change would be to clarify the receiving end's > > responsibility > >>to provide receiving buffers for all legitimate iSCSI PDUs that could >>arrive >>on the connection -- and that failure to do so MAY result in Connection >>Failure. >>That is, the Datamover *only* guarantees delivery under certain > > conditions, > >>and guarantees that delivery will be made *or* a connection failure will > > be > >>reported. Further connection failuers will be due to a problem outside >>of its control (transport error or failure of the receiver to supply a >>buffer). >> >>Of course a Datamover could be using a transport with flow-control, in >>which >>case it will not have to demand pre-posted buffers. But it should be > > made > >>clear that the Datamover MAY demand pre-posted buffers for all iSCSI >>PDUs and that absence of a buffer MAY result in a connection failure. >> >>That is a *very* different, but more applicable, requirement than simply >>stating the Datamover "guarantees' delivery. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 03:21:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08715 for ; Wed, 22 Sep 2004 03:21:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1Xz-0008Q5-9T for ips-web-archive@ietf.org; Wed, 22 Sep 2004 03:28:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1Pg-00050T-Lm; Wed, 22 Sep 2004 03:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1OD-0004Ml-HR for ips@megatron.ietf.org; Wed, 22 Sep 2004 03:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08485 for ; Wed, 22 Sep 2004 03:18:07 -0400 (EDT) Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1Ug-0008Lz-RN for ips@ietf.org; Wed, 22 Sep 2004 03:24:54 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 9E73311E0A0; Wed, 22 Sep 2004 03:18:03 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03931-06; Wed, 22 Sep 2004 03:18:02 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id BB12D11E098; Wed, 22 Sep 2004 03:18:02 -0400 (EDT) Received: from 82.166.242.137 (proxying for 82.166.242.137) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Wed, 22 Sep 2004 02:18:02 -0500 (CDT) Message-ID: <39743.82.166.242.137.1095837482.squirrel@mail52a.simplicato.com> In-Reply-To: <41510A2E.7050306@rose.hp.com> References: <41510A2E.7050306@rose.hp.com> Date: Wed, 22 Sep 2004 02:18:02 -0500 (CDT) Subject: Re: [Ips] I-D ACTION:draft-ietf-ips-iwarp-da-00.txt - Flow Control From: "Caitlin Bestler" To: "Mallikarjun C." User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Mallikarjun C. said: > Mike is right about the "demand" part, I wasn't planning on adding the > suggested text verbatim for that reason ("along these lines"). The tex= t > I had planned to add is the following: > > "In order to meet the functional requirements listed in this section, > certain Datamover protocols may require pre-posted buffers from the > local iSCSI protocol layer via mechanisms outside the scope of this > document and in some implementations, the absence of such buffers may > result in a connection failure. Datamover protocols may also realize > these functional requirements via methods not explicitly listed in this > document." > > Regarding implications to iSER especially, I do not think there are any= . > Wearing the iSER co-author's hat, I think iSER has the right approach > to flow control. I thought the previous iSER flow control threads > generally agreed that it's the case. > > And finally, I do not believe this is a change per se either. The > architecture draft from the beginning intended to leave the flexibility > of a specific approach to each Datamover protocol spec. The new text i= s > only making that intent explicit. For the same reason, I personally > think we wouldn't lose anything important if the new text isn't added. That does clarify the responsibility for me, and I agree that it matches the draft's intent (my objection was that I thought the prior wording actually implied a requirement that was not intended). One possible clarification would be to state that the Datamover Consumer may/should assume that it's peer is following all iSCSI flow control when determining how many buffers to pre-post. It may also be worth noting that other Datamover architectures may block on or temporarily reject sending of iSCSI PDUs. That is, they may be using traditional socket semantics. A robust iSCSI design would be prepared for either Datamover option. -- Caitlin Bestler http://asomi.com/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 08:13:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29728 for ; Wed, 22 Sep 2004 08:13:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA66t-0005Tq-QJ for ips-web-archive@ietf.org; Wed, 22 Sep 2004 08:20:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA5wt-0002mK-D0; Wed, 22 Sep 2004 08:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA5pV-0001at-Ud for ips@megatron.ietf.org; Wed, 22 Sep 2004 08:02:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28907 for ; Wed, 22 Sep 2004 08:02:36 -0400 (EDT) Received: from taurus.voltaire.com ([212.143.27.73]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA5w1-0005Fv-Ts for ips@ietf.org; Wed, 22 Sep 2004 08:09:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Sep 2004 14:01:56 +0200 Message-ID: Thread-Topic: DA+iSER Flow Control, Limiting number of oustanding cmds at target Thread-Index: AcSgm/T4Xg3auK1VQlq62wjzcQ0H6g== From: "Alex Nezhinsky" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Subject: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Follwing the discussion about Flow Control. Number of SCSI tasks allowed to be outstanding at target is controlled by the MaxCmdSN field sent by the target. Although the instant values of this parameter change from time to time, and initiator learns them dynamically, it'd be useful if it knew its upper bound. This will avoid allocation and posting of unnecessary receive buffers. There is no such negotiation parameter in iSCSI, but it may be added (for example "MaxOutstandingCommands") to those supported by iSER, as Declarative, Target-only. Alexander Nezhinsky Infiniband Storage Solutions, Voltaire Ltd. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 08:16:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29918 for ; Wed, 22 Sep 2004 08:16:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA69w-0005X0-5U for ips-web-archive@ietf.org; Wed, 22 Sep 2004 08:23:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA5wu-0002mi-Fn; Wed, 22 Sep 2004 08:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA5qf-0001kF-Vf for ips@megatron.ietf.org; Wed, 22 Sep 2004 08:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28976 for ; Wed, 22 Sep 2004 08:03:48 -0400 (EDT) Received: from taurus.voltaire.com ([212.143.27.73]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA5xE-0005Hf-8v for ips@ietf.org; Wed, 22 Sep 2004 08:10:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Sep 2004 14:03:15 +0200 Message-ID: Thread-Topic: DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU Thread-Index: AcSgnCQg0CBysAHdTQ+wfIVYL0MC4g== From: "Alex Nezhinsky" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable A question/suggestion for Datamover Architecture (DA) spec. In section 11.3.5.1 ("Interactions for sending an iSCSI PDU", "SCSI Data-OUT") DataDescriptorOut parameter=20 is suggested. It is supposed to describe a buffer, which will serve as the data segment of Data-OUT PDU being sent.=20 It seems redundant, as the entire data buffer for the task has been passed with Command PDU,=20 so the BufferOffset and DSL fields of Data-OUT's BHS should suffice to describe the data.=20 In the current form iSCSI layer may pass a buffer incosistent with the data descriptor passed with the Command PDU.=20 If DataDescriptorOut parameter is removed, Send_Control is always safe.=20 I'd anticipate at least a notice (like the one in 11.3.1) stating that it's up to implementation.=20 Are there other considerations that I missed? =20 Alexander Nezhinsky Infiniband Storage Solutions, Voltaire Ltd. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 12:38:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22287 for ; Wed, 22 Sep 2004 12:38:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAAFT-0002Up-Qv for ips-web-archive@ietf.org; Wed, 22 Sep 2004 12:45:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAA4Z-0000ok-HQ; Wed, 22 Sep 2004 12:34:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAA1c-0000Bn-L5 for ips@megatron.ietf.org; Wed, 22 Sep 2004 12:31:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21619 for ; Wed, 22 Sep 2004 12:31:21 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAA8A-0002Ju-VM for ips@ietf.org; Wed, 22 Sep 2004 12:38:14 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8MGUmcs174382; Wed, 22 Sep 2004 12:30:48 -0400 Received: from d03nmar1.almaden.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MGUl8u104430; Wed, 22 Sep 2004 10:30:48 -0600 In-Reply-To: Importance: Normal MIME-Version: 1.0 To: "Alex Nezhinsky" Subject: Re: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Wed, 22 Sep 2004 09:30:44 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build V70_M2_07222004 Beta 2NP|July 22, 2004) at 09/22/2004 09:30:47, Serialize complete at 09/22/2004 09:30:47 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 The target uses MaxCmdSN to indicate the maximum CmdSN the initiator can send. In other words, it allows the target to determine the number of pre-posted buffers required to receive those commands. However, it is up to the initiator to determine how many commands, up to MaxCmdSN - ExpCmdSN + 1, that it wants to send, which in turn determines the number of pre-posted buffers needed at the initiator to receive the responses to those commands that are sent (SCSI Response, Reject, etc.). This has worked well for iSCSI and I don't see any reason why a new key needs to be added for iSER. Mike Sent by: ips-bounces@ietf.org To: cc: Subject: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target Follwing the discussion about Flow Control. Number of SCSI tasks allowed to be outstanding at target is controlled by the MaxCmdSN field sent by the target. Although the instant values of this parameter change from time to time, and initiator learns them dynamically, it'd be useful if it knew its upper bound. This will avoid allocation and posting of unnecessary receive buffers. There is no such negotiation parameter in iSCSI, but it may be added (for example "MaxOutstandingCommands") to those supported by iSER, as Declarative, Target-only. Alexander Nezhinsky Infiniband Storage Solutions, Voltaire Ltd. _______________________________________________ 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 Sep 22 12:51:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23098 for ; Wed, 22 Sep 2004 12:51:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAARI-0002ip-LZ for ips-web-archive@ietf.org; Wed, 22 Sep 2004 12:57:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAAG7-0003Wb-Ul; Wed, 22 Sep 2004 12:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAAAu-0002I8-Oz for ips@megatron.ietf.org; Wed, 22 Sep 2004 12:41:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22396 for ; Wed, 22 Sep 2004 12:40:57 -0400 (EDT) Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAAHM-0002Vl-JN for ips@ietf.org; Wed, 22 Sep 2004 12:47:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Sep 2004 09:40:08 -0700 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290036028@mail1irv.inside.istor.com> Thread-Topic: Abort Task Set question Thread-Index: AcSgwtJBEWjdk0DYTlCK0HdaquyBNQ== From: "Ken Craig" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Ips] Abort Task Set question 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Does Step d of the Target's responsibilities in Section 10.6.2 only apply to the StatSNs sent by the aborted Tasks? The step doesn't make a distinction between aborted and non-aborted tasks. Thanks, Kenneth Ray Craig, Jr. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 13:42:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26509 for ; Wed, 22 Sep 2004 13:42:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CABFF-0003e6-P9 for ips-web-archive@ietf.org; Wed, 22 Sep 2004 13:49:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAB1X-000660-Mb; Wed, 22 Sep 2004 13:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAAz6-0003oa-7E for ips@megatron.ietf.org; Wed, 22 Sep 2004 13:32:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25930 for ; Wed, 22 Sep 2004 13:32:48 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAB5h-0003Sv-UQ for ips@ietf.org; Wed, 22 Sep 2004 13:39:42 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8MHWIbZ789328; Wed, 22 Sep 2004 13:32:18 -0400 Received: from d03nmar1.almaden.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MHWHQ1255564; Wed, 22 Sep 2004 11:32:17 -0600 In-Reply-To: Importance: Normal MIME-Version: 1.0 To: "Alex Nezhinsky" Subject: Re: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Wed, 22 Sep 2004 10:32:14 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build V70_M2_07222004 Beta 2NP|July 22, 2004) at 09/22/2004 10:32:17, Serialize complete at 09/22/2004 10:32:17 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Alex, When a SCSI Write (or bidirectional) command is issued, the datamover needs to do something special with the I/O buffer referenced by DataDescriptorOut if there is solicited data. This is because solicited data is transformed into RDMA Read operations. As an example of how this is handled by a datamover, see section 7.3.1 of draft-ietf-ips-iser-00.txt on SCSI Commands. If there is only unsolicited data, in the form of immediate data or non-immediate data, there is no requirement for the datamover to save the information on DataDescriptorOut after the SCSI command is processed. So when the iSCSI layer invokes the Send_Control operational primitive later to send the SCSI Data-out with the unsolicited data, it must again inform the datamover of where the unsolicated data is located via DataDescriptorOut. One can argue that when there is solicited data, the datamover is expected to recover DataDescriptorOut from the previous Send_Control invocation for the SCSI command. But since the iSCSI layer has to qualify Send_Control with DataDescriptorOut for SCSI Data-out for the unsolicited data only case anyway, it would be simpler to always qualify the Send_Control invocation for SCSI Data-out with DataDescriptorOut. Mike Sent by: ips-bounces@ietf.org To: cc: Subject: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU A question/suggestion for Datamover Architecture (DA) spec. In section 11.3.5.1 ("Interactions for sending an iSCSI PDU", "SCSI Data-OUT") DataDescriptorOut parameter is suggested. It is supposed to describe a buffer, which will serve as the data segment of Data-OUT PDU being sent. It seems redundant, as the entire data buffer for the task has been passed with Command PDU, so the BufferOffset and DSL fields of Data-OUT's BHS should suffice to describe the data. In the current form iSCSI layer may pass a buffer incosistent with the data descriptor passed with the Command PDU. If DataDescriptorOut parameter is removed, Send_Control is always safe. I'd anticipate at least a notice (like the one in 11.3.1) stating that it's up to implementation. Are there other considerations that I missed? Alexander Nezhinsky Infiniband Storage Solutions, Voltaire Ltd. _______________________________________________ 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 Sep 22 14:01:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27637 for ; Wed, 22 Sep 2004 14:01:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CABWy-0003yl-Ew for ips-web-archive@ietf.org; Wed, 22 Sep 2004 14:07:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CABJm-0001FB-AI; Wed, 22 Sep 2004 13:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CABEj-0000VB-8Z for ips@megatron.ietf.org; Wed, 22 Sep 2004 13:49:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27017 for ; Wed, 22 Sep 2004 13:48:59 -0400 (EDT) Received: from taurus.voltaire.com ([212.143.27.73]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CABLL-0003ms-KZ for ips@ietf.org; Wed, 22 Sep 2004 13:55:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] DA+iSER Flow Control, Limiting number of oustanding cmds at target Date: Wed, 22 Sep 2004 19:48:27 +0200 Message-ID: Thread-Topic: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target Thread-Index: AcSgwazclFev9mLJT0u2W+Ez4XIFigABwI/g From: "Alex Nezhinsky" To: "Mike Ko" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable > The target uses MaxCmdSN to indicate the maximum CmdSN the=20 > initiator can send. In other words, it allows the target to=20 > determine the number of pre-posted buffers required to=20 > receive those commands. However, it is up to the initiator=20 > to determine how many commands, up to MaxCmdSN - ExpCmdSN=20 > + 1, that it wants to send, which in turn determines the number of > pre-posted buffers needed at the initiator to receive the=20 > responses to those commands that are sent (SCSI Response, Reject, etc.).=20 Sure, this is exactly what I meant by:=20 >> the instant values of this parameter change from time to=20 >> time, and initiator learns them dynamically > This has worked well for iSCSI and I don't=20 > see any reason why a new key needs to be added for iSER. The only reason may be that the initiator does not know the upper bound when it executes Allocate_Connection_Resources.=20 Thus it should guess how much buffers should be allocated for the worst case.=20 This number may be too small, and then, in order to take advantage of the greater concurrency level=20 offered by the target additional buffers should be allocated. This allocation attempt can fail. In iSCSI the buffers are allocated by the iSCSI layer itself. It has the liberty of trying to allocate additional buffers=20 and if failed, to decide to pospone the command.=20 In iSER Allocate_Connection_Resources is supposed to allocate *all* resources which can be ever needed by the connection, so this poses a problem. If the initiator has a configuration parameter which places its own upper bound on the number of=20 simultaneously outstanding tasks, and if it happens to be smaller than the one actually employed=20 by the target, then it's ok. If this parameter value (or the initiator's wild guess) is greater, =20 then the initiator will try to allocate more buffers than it is actually required.=20 This may lead to an unjustified Allocate_Connection_Resources failure. =20 Alexander Nezhinsky _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 14:20:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28806 for ; Wed, 22 Sep 2004 14:20:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CABpo-0004Fw-N6 for ips-web-archive@ietf.org; Wed, 22 Sep 2004 14:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CABft-0005sk-Md; Wed, 22 Sep 2004 14:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CABby-0004tf-D2 for ips@megatron.ietf.org; Wed, 22 Sep 2004 14:13:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28302 for ; Wed, 22 Sep 2004 14:13:00 -0400 (EDT) Received: from taurus.voltaire.com ([212.143.27.73]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CABib-00049O-3d for ips@ietf.org; Wed, 22 Sep 2004 14:19:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU Date: Wed, 22 Sep 2004 20:12:26 +0200 Message-ID: Thread-Topic: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU Thread-Index: AcSgyrDViIOzJdp4TdWxZGpneDiuWgAAdvTA From: "Alex Nezhinsky" To: "Mike Ko" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Mike, The issue that I tried to address is that the same data is passed to iSER twice in different descriptors,=20 which is potentially unsafe. I can see two alternatives: 1) Only the solicited data (if any) is passed to Send_Control with the Command PDU;=20 All unsolicited data is passed piece-wise to Send_Control in subsequent invocations with Data-OUT PDUs. 2) The entire data (both unsolicited and solicited) is passed to Send_Control with the Command PDU;=20 subsequent invocations of Send_Control only specify the offset and length of the data segments=20 in Data-OUT PDUs to send (this is what I suggested previously). In either way each data portion is described only once. If it's required that the iSER layer should not save the unsolicited data descriptors, then the 1) may be acceptable. On the other hand, one can argue that it is advantageous to save the entire task data description=20 when a command is sent. A possible reason: this memory has to be registered with a H/W (unsolicited as well)=20 so doing it once is more efficient. Alexander Nezhinsky _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 17:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15716 for ; Wed, 22 Sep 2004 17:03:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAENM-0000PY-4j for ips-web-archive@ietf.org; Wed, 22 Sep 2004 17:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAE9b-0006b4-1a; Wed, 22 Sep 2004 16:55:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAE4U-0005Vz-Qa for ips@megatron.ietf.org; Wed, 22 Sep 2004 16:50:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15172 for ; Wed, 22 Sep 2004 16:50:36 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEB8-0000D0-UI for ips@ietf.org; Wed, 22 Sep 2004 16:57:31 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 149494C2E; Wed, 22 Sep 2004 16:50:36 -0400 (EDT) Received: from [127.0.0.1] (dhcp-roseor-beb168.rose.hp.com [15.23.141.168]) by rosemail.rose.hp.com (Postfix) with ESMTP id C03387FF3; Wed, 22 Sep 2004 13:50:35 -0700 (PDT) Message-ID: <4151E599.4000606@rose.hp.com> Date: Wed, 22 Sep 2004 13:50:33 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Nezhinsky Subject: Re: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Alex, > 1) Only the solicited data (if any) is passed to Send_Control with the > Command PDU; We chose not to go this route because in the example of iSER, doing so would mean that the zero-based STag's "address 0" would actually be UnsolicitedDataSize bytes into the I/O Buffer for the I/O. This in turn would mean that the target has to subtract this value (assuming that target iSER layer keeps a cumulative count of unsolicited # of bytes for each command) from the BufferOffset/R2T value to derive the Data Source TO for each RDMA Read. This all seemed like needless complexity. > 2) The entire data (both unsolicited and solicited) is passed to > Send_Control with the Command PDU; > subsequent invocations of Send_Control only specify the offset and > length of the data segments > in Data-OUT PDUs to send (this is what I suggested previously). This is doable, but the desire to be able to discard the descriptors after the memory registration (in the iSER example) is what led to the current text. As you suggested, I would perhaps add an implementation caveat (as in 11.3.1) to 11.3.5.1 as well. I hope that addresses the concern. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Alex Nezhinsky wrote: > Mike, > > The issue that I tried to address is that the same data is passed to > iSER twice in different descriptors, > which is potentially unsafe. > > I can see two alternatives: > 1) Only the solicited data (if any) is passed to Send_Control with the > Command PDU; > All unsolicited data is passed piece-wise to Send_Control in > subsequent invocations with Data-OUT PDUs. > 2) The entire data (both unsolicited and solicited) is passed to > Send_Control with the Command PDU; > subsequent invocations of Send_Control only specify the offset and > length of the data segments > in Data-OUT PDUs to send (this is what I suggested previously). > > In either way each data portion is described only once. > > If it's required that the iSER layer should not save the unsolicited > data descriptors, then the 1) may be acceptable. > > On the other hand, one can argue that it is advantageous to save the > entire task data description > when a command is sent. A possible reason: this memory has to be > registered with a H/W (unsolicited as well) > so doing it once is more efficient. > > Alexander Nezhinsky > > _______________________________________________ > 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 Sep 22 17:19:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16644 for ; Wed, 22 Sep 2004 17:19:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEdT-0000fV-J7 for ips-web-archive@ietf.org; Wed, 22 Sep 2004 17:26:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEJv-0000UX-Tb; Wed, 22 Sep 2004 17:06:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEDm-0007RK-3a for ips@megatron.ietf.org; Wed, 22 Sep 2004 17:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15510 for ; Wed, 22 Sep 2004 17:00:11 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEKO-0000LH-VA for ips@ietf.org; Wed, 22 Sep 2004 17:07:06 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 855CF120A0; Wed, 22 Sep 2004 14:00:10 -0700 (PDT) Received: from [127.0.0.1] (dhcp-roseor-beb168.rose.hp.com [15.23.141.168]) by rosemail.rose.hp.com (Postfix) with ESMTP id 6C339822B; Wed, 22 Sep 2004 14:00:10 -0700 (PDT) Message-ID: <4151E7D9.60504@rose.hp.com> Date: Wed, 22 Sep 2004 14:00:09 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Nezhinsky Subject: Re: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Alex, > The only reason may be that the initiator does not know the upper bound > when it executes Allocate_Connection_Resources. It appears that your concern is wrt sizing of per-task buffer resources on the invocation of Allocate_Connection_Resources. Note that section 9.4 in DA says the following: "Note that the Datamover layer however does not allocate any Datamover-specific task-level resources upon invocation of this Primitive." The task buffers are thus not related to Allocate_Connection_Resources. The buffer management is specific to implementations. DA only specifies the architectural primitives that are minimally required to allow the definition of a Datamover protocol, but not everything for an implementation. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Alex Nezhinsky wrote: >>The target uses MaxCmdSN to indicate the maximum CmdSN the >>initiator can send. In other words, it allows the target to >>determine the number of pre-posted buffers required to >>receive those commands. However, it is up to the initiator >>to determine how many commands, up to MaxCmdSN - ExpCmdSN >>+ 1, that it wants to send, which in turn determines the number of >>pre-posted buffers needed at the initiator to receive the >>responses to those commands that are sent (SCSI Response, Reject, > > etc.). > > Sure, this is exactly what I meant by: > >> the instant values of this parameter change from time to > >> time, and initiator learns them dynamically > > >> This has worked well for iSCSI and I don't >>see any reason why a new key needs to be added for iSER. > > > The only reason may be that the initiator does not know the upper bound > when it executes Allocate_Connection_Resources. > Thus it should guess how much buffers should be allocated for the worst > case. > This number may be too small, and then, in order to take advantage of > the greater concurrency level > offered by the target additional buffers should be allocated. This > allocation attempt can fail. > In iSCSI the buffers are allocated by the iSCSI layer itself. It has the > liberty of trying to allocate additional buffers > and if failed, to decide to pospone the command. > In iSER Allocate_Connection_Resources is supposed to allocate *all* > resources which can be ever needed by the connection, so this poses a > problem. > If the initiator has a configuration parameter which places its own > upper bound on the number of > simultaneously outstanding tasks, and if it happens to be smaller than > the one actually employed > by the target, then it's ok. If this parameter value (or the initiator's > wild guess) is greater, > then the initiator will try to allocate more buffers than it is actually > required. > This may lead to an unjustified Allocate_Connection_Resources failure. > > Alexander Nezhinsky > > _______________________________________________ > 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 Sep 22 17:25:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17103 for ; Wed, 22 Sep 2004 17:25:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAEiv-0000mE-1S for ips-web-archive@ietf.org; Wed, 22 Sep 2004 17:32:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEYO-00030N-VQ; Wed, 22 Sep 2004 17:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAEKh-0000ef-TV for ips@megatron.ietf.org; Wed, 22 Sep 2004 17:07:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15958 for ; Wed, 22 Sep 2004 17:07:20 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAERL-0000U9-Na for ips@ietf.org; Wed, 22 Sep 2004 17:14:16 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8ML6mZd017754; Wed, 22 Sep 2004 17:06:48 -0400 Received: from d03nmar1.almaden.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ML6l8u099470; Wed, 22 Sep 2004 15:06:47 -0600 In-Reply-To: Importance: Normal MIME-Version: 1.0 To: "Alex Nezhinsky" Subject: RE: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Wed, 22 Sep 2004 14:06:45 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build V70_M2_07222004 Beta 2NP|July 22, 2004) at 09/22/2004 14:06:47, Serialize complete at 09/22/2004 14:06:47 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Alex, Alternative 1 does not work if there are immediate data to be sent with the command since the data descriptor in this proposal only specifies solicited data. Alternative 2 requires the datamover to save the information on the data buffer when a SCSI Write command is issued and there are unsolicited non-immediate data that needs to be sent. This will require additional bookkeeping on the part of the datamover such as creating a local mapping that associates the ITT with the data buffer. There are also additonal chores like having to remove the mapping when a SCSI Response is recieved. So the question is how "potentially unsafe" it is for the iSCSI layer to pass DataDescriptorOut to the datamover layer when it invokes the Send_Control to send the SCSI Command and SCSI Data-out. It seems to me that this is an implementation issue and it does not justify changing the datamover architecture especially since it will create addional bookkeeping chores at the datamover. Mike To: "Mike Ko" cc: Subject: RE: [Ips] DA, Send_Control, DataDescriptorOut parameter of Data-OUT PDU Mike, The issue that I tried to address is that the same data is passed to iSER twice in different descriptors, which is potentially unsafe. I can see two alternatives: 1) Only the solicited data (if any) is passed to Send_Control with the Command PDU; All unsolicited data is passed piece-wise to Send_Control in subsequent invocations with Data-OUT PDUs. 2) The entire data (both unsolicited and solicited) is passed to Send_Control with the Command PDU; subsequent invocations of Send_Control only specify the offset and length of the data segments in Data-OUT PDUs to send (this is what I suggested previously). In either way each data portion is described only once. If it's required that the iSER layer should not save the unsolicited data descriptors, then the 1) may be acceptable. On the other hand, one can argue that it is advantageous to save the entire task data description when a command is sent. A possible reason: this memory has to be registered with a H/W (unsolicited as well) so doing it once is more efficient. Alexander Nezhinsky _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 22 18:15:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21527 for ; Wed, 22 Sep 2004 18:15:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAFUz-0001kd-CU for ips-web-archive@ietf.org; Wed, 22 Sep 2004 18:22:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAFGr-00008a-Dv; Wed, 22 Sep 2004 18:07:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAFAH-0004a7-SU for ips@megatron.ietf.org; Wed, 22 Sep 2004 18:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19722 for ; Wed, 22 Sep 2004 18:00:38 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAFGv-0001U7-Gg for ips@ietf.org; Wed, 22 Sep 2004 18:07:34 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i8MM0XIW016154; Wed, 22 Sep 2004 18:00:34 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Sep 2004 18:00:32 -0400 Message-ID: To: kcraig@istor.com, ips@ietf.org Subject: RE: [Ips] Abort Task Set question Date: Wed, 22 Sep 2004 18:00:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.9.22.3 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, TO_HAS_SPACES 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > Does Step d of the Target's responsibilities in > Section 10.6.2 only apply to the StatSNs sent by > the aborted Tasks? The step doesn't make a > distinction between aborted and non-aborted tasks. It applies to all because it would be a bad thing for a successful completion response to a SCSI task within the scope of the ABORT/CLEAR TASK SET to arrive after the task management response indicating that the abort or clear function is complete. In general, a SCSI abort is considered successful if the task completed before the abort got to it, but it's necessary to either force presentation of the responses for such tasks to the SCSI level on the initiators before declaring the abort to have completed or ensure that they are discarded if received subsequently - the latter would be a mess for the iSCSI TASK SET functions, hence the text you referred to. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 24 10:30:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15513 for ; Fri, 24 Sep 2004 10:30:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CArD5-0002vx-P2 for ips-web-archive@ietf.org; Fri, 24 Sep 2004 10:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqyf-0006Bt-O3; Fri, 24 Sep 2004 10:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAqxE-0005g0-EE for ips@megatron.ietf.org; Fri, 24 Sep 2004 10:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14674 for ; Fri, 24 Sep 2004 10:21:42 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAr4E-0002hd-Ie for ips@ietf.org; Fri, 24 Sep 2004 10:28:59 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8OELBdW135818; Fri, 24 Sep 2004 14:21:11 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8OELAT8046884; Fri, 24 Sep 2004 16:21:11 +0200 In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF290036028@mail1irv.inside.istor.com> To: "Ken Craig" Subject: Re: [Ips] Abort Task Set question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 From: Julian Satran Message-ID: Date: Fri, 24 Sep 2004 15:21:07 +0100 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 24/09/2004 16:21:10, Serialize complete at 24/09/2004 16:21:10 X-Spam-Score: 0.9 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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="===============1460223102==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multipart message in MIME format. --===============1460223102== Content-Type: multipart/alternative; boundary="=_alternative 003C6E13C1256F19_=" This is a multipart message in MIME format. --=_alternative 003C6E13C1256F19_= Content-Type: text/plain; charset="US-ASCII" Ken - step d applies to all StatSNs. It is meant to insure that "all is clear" when the response to the abort is sent (no status will have to be resent after) - Julo "Ken Craig" Sent by: ips-bounces@ietf.org 22/09/04 18:40 To cc Subject [Ips] Abort Task Set question Does Step d of the Target's responsibilities in Section 10.6.2 only apply to the StatSNs sent by the aborted Tasks? The step doesn't make a distinction between aborted and non-aborted tasks. Thanks, Kenneth Ray Craig, Jr. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003C6E13C1256F19_= Content-Type: text/html; charset="US-ASCII"
Ken - step d applies to all StatSNs. It is meant to insure that "all is clear" when the response to the abort is sent (no status will have to be resent after) - Julo


"Ken Craig" <kcraig@istor.com>
Sent by: ips-bounces@ietf.org

22/09/04 18:40

To
<ips@ietf.org>
cc
Subject
[Ips] Abort Task Set question





Does Step d of the Target's responsibilities in
Section 10.6.2 only apply to the StatSNs sent by
the aborted Tasks?  The step doesn't make a
distinction between aborted and non-aborted tasks.

Thanks,
Kenneth Ray Craig, Jr.

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 003C6E13C1256F19_=-- --===============1460223102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1460223102==-- From ips-bounces@ietf.org Fri Sep 24 14:12:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03005 for ; Fri, 24 Sep 2004 14:12:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAufT-0008GU-1n for ips-web-archive@ietf.org; Fri, 24 Sep 2004 14:19:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAuQ6-00081H-EF; Fri, 24 Sep 2004 14:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAuCH-0004z1-6i for ips@megatron.ietf.org; Fri, 24 Sep 2004 13:49:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01473 for ; Fri, 24 Sep 2004 13:49:28 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAuJG-0007lp-KR for ips@ietf.org; Fri, 24 Sep 2004 13:56:45 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8OHmfFW138820; Fri, 24 Sep 2004 17:48:41 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8OHmcG6219224; Fri, 24 Sep 2004 19:48:39 +0200 In-Reply-To: To: "Alex Nezhinsky" Subject: RE: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 From: Julian Satran Message-ID: Date: Fri, 24 Sep 2004 18:48:35 +0100 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 24/09/2004 19:48:39, Serialize complete at 24/09/2004 19:48:39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: ips@ietf.org, Mike Ko 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="===============0873573158==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b This is a multipart message in MIME format. --===============0873573158== Content-Type: multipart/alternative; boundary="=_alternative 005BEC65C1256F19_=" This is a multipart message in MIME format. --=_alternative 005BEC65C1256F19_= Content-Type: text/plain; charset="US-ASCII" Alex, MaxCmdSN is negotiated. The target and the initiator can set themselves bounds per connection and/or total and "downgrade" any attempt to exceed the bounds. There is no need to negotiate a bound. Am I missing something? Julo "Alex Nezhinsky" Sent by: ips-bounces@ietf.org 22/09/04 19:48 To "Mike Ko" cc ips@ietf.org Subject RE: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target > The target uses MaxCmdSN to indicate the maximum CmdSN the > initiator can send. In other words, it allows the target to > determine the number of pre-posted buffers required to > receive those commands. However, it is up to the initiator > to determine how many commands, up to MaxCmdSN - ExpCmdSN > + 1, that it wants to send, which in turn determines the number of > pre-posted buffers needed at the initiator to receive the > responses to those commands that are sent (SCSI Response, Reject, etc.). Sure, this is exactly what I meant by: >> the instant values of this parameter change from time to >> time, and initiator learns them dynamically > This has worked well for iSCSI and I don't > see any reason why a new key needs to be added for iSER. The only reason may be that the initiator does not know the upper bound when it executes Allocate_Connection_Resources. Thus it should guess how much buffers should be allocated for the worst case. This number may be too small, and then, in order to take advantage of the greater concurrency level offered by the target additional buffers should be allocated. This allocation attempt can fail. In iSCSI the buffers are allocated by the iSCSI layer itself. It has the liberty of trying to allocate additional buffers and if failed, to decide to pospone the command. In iSER Allocate_Connection_Resources is supposed to allocate *all* resources which can be ever needed by the connection, so this poses a problem. If the initiator has a configuration parameter which places its own upper bound on the number of simultaneously outstanding tasks, and if it happens to be smaller than the one actually employed by the target, then it's ok. If this parameter value (or the initiator's wild guess) is greater, then the initiator will try to allocate more buffers than it is actually required. This may lead to an unjustified Allocate_Connection_Resources failure. Alexander Nezhinsky _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005BEC65C1256F19_= Content-Type: text/html; charset="US-ASCII"
Alex,

MaxCmdSN is negotiated. The target and the initiator can set themselves bounds per connection and/or total and "downgrade" any attempt to exceed the bounds.
There is no need to negotiate a bound. Am I missing something?

Julo


"Alex Nezhinsky" <alexn@voltaire.com>
Sent by: ips-bounces@ietf.org

22/09/04 19:48

To
"Mike Ko" <mako@almaden.ibm.com>
cc
ips@ietf.org
Subject
RE: [Ips] DA+iSER Flow Control,        Limiting number of oustanding cmds at target





> The target uses MaxCmdSN to indicate the maximum CmdSN the
> initiator can send.  In other words, it allows the target to
> determine the number of pre-posted buffers required to
> receive those commands.  However, it is up to the initiator
> to determine how many commands, up to MaxCmdSN - ExpCmdSN
> + 1, that it wants to send, which in turn determines the number of
> pre-posted buffers needed at the initiator to receive the
> responses to those commands that are sent (SCSI Response, Reject,
etc.).

Sure, this is exactly what I meant by:
           >> the instant values of this parameter change from time to
           >> time, and initiator learns them dynamically

>  This has worked well for iSCSI and I don't
> see any reason why a new key needs to be added for iSER.

The only reason may be that the initiator does not know the upper bound
when it executes Allocate_Connection_Resources.
Thus it should guess how much buffers should be allocated for the worst
case.
This number may be too small, and then, in order to take advantage of
the greater concurrency level
offered by the target additional buffers should be allocated. This
allocation attempt can fail.
In iSCSI the buffers are allocated by the iSCSI layer itself. It has the
liberty of trying to allocate additional buffers
and if failed, to decide to pospone the command.
In iSER Allocate_Connection_Resources is supposed to allocate *all*
resources which can be ever needed by the connection, so this poses a
problem.
If the initiator has a configuration parameter which places its own
upper bound on the number of
simultaneously outstanding tasks, and if it happens to be smaller than
the one actually employed
by the target, then it's ok. If this parameter value (or the initiator's
wild guess) is greater,  
then the initiator will try to allocate more buffers than it is actually
required.
This may lead to an unjustified Allocate_Connection_Resources failure.  

Alexander Nezhinsky

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 005BEC65C1256F19_=-- --===============0873573158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0873573158==-- From ips-bounces@ietf.org Wed Sep 29 01:37:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27696 for ; Wed, 29 Sep 2004 01:37:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCXHr-00053D-Ak for ips-web-archive@ietf.org; Wed, 29 Sep 2004 01:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCX6g-00072E-UT; Wed, 29 Sep 2004 01:34:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCX0e-00060S-PI for ips@megatron.ietf.org; Wed, 29 Sep 2004 01:28:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27387 for ; Wed, 29 Sep 2004 01:28:11 -0400 (EDT) Received: from web50402.mail.yahoo.com ([206.190.38.67]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCX8c-0004uC-1p for ips@ietf.org; Wed, 29 Sep 2004 01:36:27 -0400 Message-ID: <20040929052740.70780.qmail@web50402.mail.yahoo.com> Received: from [203.187.215.134] by web50402.mail.yahoo.com via HTTP; Tue, 28 Sep 2004 22:27:40 PDT Date: Tue, 28 Sep 2004 22:27:40 -0700 (PDT) From: ulka vaze To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ips] query about initiator 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi All, I have a questions regarding working of iscsi initiator 1.Once Lgin is complete how does initiator finds theLU's on target? 2.Does it fire inquiry first on device? 3.If target device has multiple LU s how does it informs initiator about it? Thanks ulka __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 29 02:01:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00695 for ; Wed, 29 Sep 2004 02:01:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCXei-0005Wv-Tq for ips-web-archive@ietf.org; Wed, 29 Sep 2004 02:09:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCXIr-0000ko-KP; Wed, 29 Sep 2004 01:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCXDq-0008FQ-9G for ips@megatron.ietf.org; Wed, 29 Sep 2004 01:41:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28073 for ; Wed, 29 Sep 2004 01:41:49 -0400 (EDT) Received: from web50404.mail.yahoo.com ([206.190.38.69]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CCXLn-00058D-VX for ips@ietf.org; Wed, 29 Sep 2004 01:50:05 -0400 Message-ID: <20040929054117.37578.qmail@web50404.mail.yahoo.com> Received: from [203.187.215.134] by web50404.mail.yahoo.com via HTTP; Tue, 28 Sep 2004 22:41:17 PDT Date: Tue, 28 Sep 2004 22:41:17 -0700 (PDT) From: ulka vaze To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ips] scsi target mode 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi all, I have few questions regarding SCSI target mode and i am posting here because lot of scsi experts are here. 1.When scsi hba is configured in target mode will it expose single LU to initiator on the other host? 2.My set up is like this: I have connected scsi controller configured in target mode and initiator on the other host pc and both are connected by scsi cable.What type of device initiator will find? 3.If i connect the multiple scsi disks on the target machine through another controller which i want to expose to initiator how should i go about it? 4.how does initiator finds multiple LU's on target device? THanks, ulka _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 29 08:46:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28706 for ; Wed, 29 Sep 2004 08:46:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCdyW-0005aw-E9 for ips-web-archive@ietf.org; Wed, 29 Sep 2004 08:54:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdje-0006Pp-8G; Wed, 29 Sep 2004 08:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdYh-0004Fn-KY for ips@megatron.ietf.org; Wed, 29 Sep 2004 08:27:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27118 for ; Wed, 29 Sep 2004 08:27:46 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCdgj-0005An-KR for ips@ietf.org; Wed, 29 Sep 2004 08:36:06 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc11) with SMTP id <20040929122715011001famue> (Authid: esquicksall); Wed, 29 Sep 2004 12:27:16 +0000 Message-ID: <000a01c4a61f$a79d08e0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "ulka vaze" , References: <20040929052740.70780.qmail@web50402.mail.yahoo.com> Subject: Re: [Ips] query about initiator Date: Wed, 29 Sep 2004 08:27:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit This is actually a SCSI issue, not iSCSI. Once logged in, the initiator can discover the LU's in various ways. 1) In legacy SCSI, the initiator ususally will do some command to each possible LU (Inquiry is ususally used for this). This method can still be used today but it only gets one LU at a time. 2) Most recent targets will support the Report LUNs command. That will report all LUs. Eddy ----- Original Message ----- From: "ulka vaze" To: Sent: Wednesday, September 29, 2004 1:27 AM Subject: [Ips] query about initiator > Hi All, > I have a questions regarding working of iscsi > initiator > 1.Once Lgin is complete how does initiator finds > theLU's on target? > 2.Does it fire inquiry first on device? > 3.If target device has multiple LU s how does it > informs initiator about it? > Thanks > ulka > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail > > _______________________________________________ > 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 Sep 29 08:58:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29538 for ; Wed, 29 Sep 2004 08:58:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCeAe-0005rb-J0 for ips-web-archive@ietf.org; Wed, 29 Sep 2004 09:07:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdoV-0008LJ-Um; Wed, 29 Sep 2004 08:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdfO-0005jb-P8 for ips@megatron.ietf.org; Wed, 29 Sep 2004 08:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27771 for ; Wed, 29 Sep 2004 08:34:41 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCdnR-0005Jy-8I for ips@ietf.org; Wed, 29 Sep 2004 08:43:01 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc11) with SMTP id <20040929123411011001efe6e> (Authid: esquicksall); Wed, 29 Sep 2004 12:34:11 +0000 Message-ID: <001301c4a620$9f7bee00$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "ulka vaze" , References: <20040929054117.37578.qmail@web50404.mail.yahoo.com> Subject: Re: [Ips] scsi target mode Date: Wed, 29 Sep 2004 08:34:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit I would suggest going to another reflector for these types of questions as some are HBA related and none are iSCSI related. Try www.experts-exchange.com. Eddy ----- Original Message ----- From: "ulka vaze" To: Sent: Wednesday, September 29, 2004 1:41 AM Subject: [Ips] scsi target mode > Hi all, > I have few questions regarding SCSI target mode and i > am posting here because lot of scsi experts are here. > 1.When scsi hba is configured in target mode will it > expose single LU to initiator on the other host? > 2.My set up is like this: > I have connected scsi controller configured in target > mode and initiator on the other host pc and both are > connected by scsi cable.What type of device initiator > will find? > 3.If i connect the multiple scsi disks on the target > machine through another controller which i want to > expose to initiator how should i go about it? > 4.how does initiator finds multiple LU's on target > device? > THanks, > ulka > > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > > _______________________________________________ > 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 Sep 29 14:33:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26641 for ; Wed, 29 Sep 2004 14:33:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCjOe-0004VS-1D for ips-web-archive@ietf.org; Wed, 29 Sep 2004 14:41:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCj1m-0000Ho-W3; Wed, 29 Sep 2004 14:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCixH-0007Rf-Cx; Wed, 29 Sep 2004 14:13:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24750; Wed, 29 Sep 2004 14:13:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCj5M-000476-Ud; Wed, 29 Sep 2004 14:21:53 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CCilX-0005Xd-EL; Wed, 29 Sep 2004 14:01:23 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 29 Sep 2004 14:01:23 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ips mailing list , Internet Architecture Board , ips chair , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Internet Storage Name Service (iSNS)' to Proposed Standard 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The IESG has approved the following document: - 'Internet Storage Name Service (iSNS) ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary iSNS allows the administrator to go beyond a simple device-by-device management model, where each storage device is manually and individually configured with its own list of known initiators and targets. Using the iSNS, each storage device subordinates its discovery and management responsibilities to the iSNS server. The iSNS server thereby serves as the consolidated configuration point through which management stations can configure and manage the entire storage network, including both iSCSI and Fibre Channel devices. This specification records consensus that iSNS is optional to implement for iSCSI and mandatory for iFCP. The specification includes server authentication among other security services, as well as a security analysis. Working Group Summary The working group conducted thorough review of this document and had strong consensus to advance this document. Protocol Quality The specification was reviewed for the IESG by Allison Mankin. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 30 17:02:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02463 for ; Thu, 30 Sep 2004 17:02:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD8Cn-0003kL-3L for ips-web-archive@ietf.org; Thu, 30 Sep 2004 17:11:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7R8-0006Qz-L1; Thu, 30 Sep 2004 16:21:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD7Dn-0005ir-DO for ips@megatron.ietf.org; Thu, 30 Sep 2004 16:08:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25603 for ; Thu, 30 Sep 2004 16:08:08 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD7M6-0001Os-9O for ips@ietf.org; Thu, 30 Sep 2004 16:16:46 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel10.hp.com (Postfix) with ESMTP id E13F77939 for ; Thu, 30 Sep 2004 13:08:08 -0700 (PDT) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Sep 2004 13:08:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Sep 2004 13:08:07 -0700 Message-ID: <95AC37E4A7C3304D94DB6AF7F64FA1B501513C65@cacexc08.americas.cpqcorp.net> Thread-Topic: Initiator CHAP authentication of target? Thread-Index: AcSnKTPE/amZq2ldQTmJ6YuUFQfaQQ== From: "Krueger, Marjorie" To: X-OriginalArrivalTime: 30 Sep 2004 20:08:08.0751 (UTC) FILETIME=[34615BF0:01C4A729] X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ips] Initiator CHAP authentication of target? 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="===============1854461958==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. --===============1854461958== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A729.34293FC5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A729.34293FC5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable If a target supplies a CHAP name <> iSCSI node name in the login response and the initiator claims to support authentication of the target, is it valid for the initiator to ignore the supplied CHAP name when authenticating the target? =20 Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard=20 ------_=_NextPart_001_01C4A729.34293FC5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
If a = target supplies=20 a CHAP name <> iSCSI node name in the login response and the = initiator=20 claims to support authentication of the target, is it valid for the = initiator to=20 ignore the supplied CHAP name when authenticating the=20 target?
 

Marjorie Krueger
Networked Storage = Architecture
Networked=20 Storage Solutions
Hewlett-Packard=20

------_=_NextPart_001_01C4A729.34293FC5-- --===============1854461958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1854461958==-- From ips-bounces@ietf.org Thu Sep 30 18:42:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10435 for ; Thu, 30 Sep 2004 18:42:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD9le-0005zC-Rv for ips-web-archive@ietf.org; Thu, 30 Sep 2004 18:51:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD9R8-0000VR-Kg; Thu, 30 Sep 2004 18:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD9F0-0003n7-Na for ips@megatron.ietf.org; Thu, 30 Sep 2004 18:17:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08313 for ; Thu, 30 Sep 2004 18:17:29 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD9NF-0005S0-0i for ips@ietf.org; Thu, 30 Sep 2004 18:26:09 -0400 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 6376A870AC; Thu, 30 Sep 2004 18:17:25 -0400 (EDT) In-Reply-To: <95AC37E4A7C3304D94DB6AF7F64FA1B501513C65@cacexc08.americas.cpqcorp.net> References: <95AC37E4A7C3304D94DB6AF7F64FA1B501513C65@cacexc08.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <7DF965AE-132E-11D9-9F7D-000A95D14BEC@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Initiator CHAP authentication of target? Date: Thu, 30 Sep 2004 15:17:10 -0700 To: "Krueger, Marjorie" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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="===============0414122282==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --===============0414122282== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-163838127" --Apple-Mail-6-163838127 Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-163838121; protocol="application/pkcs7-signature" --Apple-Mail-5-163838121 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 30, 2004, at 1:08 PM, Krueger, Marjorie wrote: > If a target supplies a CHAP name <> iSCSI node name in the login > response and the initiator claims to support authentication of the > target, is it valid for the initiator to ignore the supplied CHAP name > when authenticating the target? What do you mean by "CHAP name <> iSCSI node name"? I am going to guess you're asking if an initiator can ignore a CHAP name (CHAP_N) the target supplied earlier in the login process. If you mean something else, well, ignore the rest. :-) I think the answer is either yes, or the initiator should close the connection. Quoting RFC 3720, section 11.1.4: In the third step, the initiator MUST continue with: CHAP_N= CHAP_R= or, if it requires target authentication, with: CHAP_N= CHAP_R= CHAP_I= CHAP_C= If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST either answer with a Login reject with "Authentication Failure" or reply with: CHAP_N= CHAP_R= If target authentication fails, the initiator MUST close the connection. So it'd be wrong for the target to have sent a CHAP_N earlier in the login. Take care, Bill --Apple-Mail-5-163838121 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfDCCBXgw ggNgoAMCAQICAUYwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcg WW9yazERMA8GA1UEBxMITmV3IFlvcmsxHTAbBgNVBAoTFFdhc2FiaSBTeXN0ZW1zLCBJbmMuMQww CgYDVQQLEwNHSFExHzAdBgNVBAMTFldhc2FiaSBTeXN0ZW1zIFJvb3QgQ0ExKjAoBgkqhkiG9w0B CQEWG3dlYm1hc3RlckB3YXNhYmlzeXN0ZW1zLmNvbTAeFw0wMzA4MTExODU2NDZaFw0wODA2MjUx ODU2NDZaMIGXMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU2Fu IERpZWdvMRcwFQYDVQQKEw5XYXNhYmkgU3lzdGVtczEbMBkGA1UEAxMSV2lsbGlhbSBTdHVkZW5t dW5kMSkwJwYJKoZIhvcNAQkBFhp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA9CZhg4GVWYTRGcJz8lU1ipzInlBuGqfZQs88Z1rTP7+c3AyhKwpE TyTmK4UhxslzKa93YLqifLxZKYt1jI6FNq40IQWCKBVywWBwmL5guCu0851f9ywH5Uj2wJdiDrOI sOJKNpwNqml8bFdTrFS2qvyCxTIWVMLYAzUBBcl2F7MCAwEAAaOCATkwggE1MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTt mjHbSBlMV48RWOBETM3EV0Tm/jCB2gYDVR0jBIHSMIHPgBQrBOnN88CNCHPaV5wLS212tcrgBaGB s6SBsDCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9y azEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMW V2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5 c3RlbXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4ICAQCpxoPEYunR7qiXyycEZd0UIatSt/WalMoH nuN9S421iS/sD1wSDqzHyM5YyUWn4z4o6VhT2kD9UV4lk5aXxxefEfGzFcR7Xyah7tO3ziuReFfx qUP5+DTlwDuUBc8Iow6NwY9GlRCKFSsEroLWLGODyYWgN1ojjKOtcXRiOZkYTP3VfDUV2/Xrhh9O l6+3Otf069+KWeOWedWeMsbe1rac96yPEjPogToWkBXVJEeEQktd0BLETt7GUuSZg2Fho/nslqZv nnnKZmrOfdFy9iXDL9T0Hp/OHf5B9RP+r00BJJFO8JzBPIL2IA3CBPApOQty5A00Jg1CGfDQxiV3 s8G0aRUbmFqg9r0OfhPYjJ8BHfw1HHWb7Cu91Sw+d5UnYracZhsR2Gc5H5CnfS6IZhc7ulfnSX8f I4BXR4vbeRUG76J3rkkbkO1haYHLk5w5RlICHsJOBSElG9ggLBWNIfUZwAzo84lfmDmJMP1YCOmi DFCbW1DgxhqVFpYEf5Pq2pVcCguopK2G9oZjH5fxq6ehisk9dN+7NEQ4OSqC43ehaStYOoQAJruN e6e5tCtRMx7bMI7eVPiHxE9/Y38Q+sc5oRN9mCyyAXMweuMRNHAHAWdFB7NhHD6gBa2lh91zIMdf iSVRlBXoMrBKJX6VecgnhvUp4G6QAnN7EMu6QHlc/jGCA0swggNHAgEBMIGzMIGtMQswCQYDVQQG EwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExRXYXNh YmkgU3lzdGVtcywgSW5jLjEMMAoGA1UECxMDR0hRMR8wHQYDVQQDExZXYXNhYmkgU3lzdGVtcyBS b290IENBMSowKAYJKoZIhvcNAQkBFht3ZWJtYXN0ZXJAd2FzYWJpc3lzdGVtcy5jb20CAUYwCQYF Kw4DAhoFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQw OTMwMjIxNzExWjAjBgkqhkiG9w0BCQQxFgQUAZFa146rKb7tZ9svBsS7YCjA4TswgcQGCSsGAQQB gjcQBDGBtjCBszCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhO ZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0G A1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdh c2FiaXN5c3RlbXMuY29tAgFGMIHGBgsqhkiG9w0BCRACCzGBtqCBszCBrTELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5 c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBD QTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5c3RlbXMuY29tAgFGMA0GCSqGSIb3 DQEBAQUABIGAlw5SBZsOl0Y+mBufYaJ55rWtB3ljTI2tf628W+cS0+sFd/RgAiLQq11q7X8yM4/h lOh6SyYXOt9oaGX5xom3EdI/5LsMuiWPEe3/hDFbUIUGGmvZjbyX94FIQvweOII4GAEGgn0LxaX2 itBotnxl+yhJ2n+DluQuHIsh0aeebeYAAAAAAAA= --Apple-Mail-5-163838121-- --Apple-Mail-6-163838127 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBXIX0DJT2Egh26K0RAsPyAJ9Bi2I+Y7dtf3E0xcRqQH2Ao0nA6QCeMCUB 2lgDaz277vLbd3s7lj5FN5Q= =9hcY -----END PGP SIGNATURE----- --Apple-Mail-6-163838127-- --===============0414122282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0414122282==-- From ips-bounces@ietf.org Thu Sep 30 18:44:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10565 for ; Thu, 30 Sep 2004 18:44:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD9nD-00061K-0h for ips-web-archive@ietf.org; Thu, 30 Sep 2004 18:52:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD9VP-0001Kk-9v; Thu, 30 Sep 2004 18:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD9Jz-0006Lh-6B for ips@megatron.ietf.org; Thu, 30 Sep 2004 18:22:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09148 for ; Thu, 30 Sep 2004 18:22:39 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD9SJ-0005ZG-Bm for ips@ietf.org; Thu, 30 Sep 2004 18:31:19 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel12.hp.com (Postfix) with ESMTP id 2408340230B; Thu, 30 Sep 2004 15:22:41 -0700 (PDT) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Sep 2004 15:22:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Initiator CHAP authentication of target? Date: Thu, 30 Sep 2004 15:22:39 -0700 Message-ID: <95AC37E4A7C3304D94DB6AF7F64FA1B501513CC6@cacexc08.americas.cpqcorp.net> Thread-Topic: [Ips] Initiator CHAP authentication of target? Thread-Index: AcSnO0keLrmcAFt7SBSL9+Ye4vB4tAAADamA From: "Krueger, Marjorie" To: "William Studenmund" X-OriginalArrivalTime: 30 Sep 2004 22:22:40.0898 (UTC) FILETIME=[FFC13E20:01C4A73B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable So if=20 > or, if it requires target authentication, with: >=20 > CHAP_N=3D CHAP_R=3D CHAP_I=3D CHAP_C=3D >=20 > If the initiator authentication fails, the target MUST=20 > answer with a > Login reject with "Authentication Failure" status. =20 > Otherwise, if the > initiator required target authentication, the target MUST either > answer with a Login reject with "Authentication Failure" or reply > with: >=20 > CHAP_N=3D CHAP_R=3D And the target replys with CHAP_N that is not defined and the initiator accepts that (accepts anything) is that valid behavior? In otherwords, if the initiator ignores CHAP_N and only uses the target node name and CHAP_R to authenticate, is that valid behavior? Shouldn't the target be able to force the use of CHAP_N? -Marjorie=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 30 18:55:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11596 for ; Thu, 30 Sep 2004 18:55:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD9yE-0006Hj-5f for ips-web-archive@ietf.org; Thu, 30 Sep 2004 19:04:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD9dl-0004ME-Aa; Thu, 30 Sep 2004 18:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD9TU-0000zH-C6 for ips@megatron.ietf.org; Thu, 30 Sep 2004 18:32:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09830 for ; Thu, 30 Sep 2004 18:32:29 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD9bn-0005mi-Sv for ips@ietf.org; Thu, 30 Sep 2004 18:41:09 -0400 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C8EBA870AC; Thu, 30 Sep 2004 18:32:29 -0400 (EDT) In-Reply-To: <95AC37E4A7C3304D94DB6AF7F64FA1B501513CC6@cacexc08.americas.cpqcorp.net> References: <95AC37E4A7C3304D94DB6AF7F64FA1B501513CC6@cacexc08.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <98897F3E-1330-11D9-9F7D-000A95D14BEC@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Initiator CHAP authentication of target? Date: Thu, 30 Sep 2004 15:32:16 -0700 To: "Krueger, Marjorie" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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="===============0805047148==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac --===============0805047148== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-164741685" --Apple-Mail-8-164741685 Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-164741680; protocol="application/pkcs7-signature" --Apple-Mail-7-164741680 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 30, 2004, at 3:22 PM, Krueger, Marjorie wrote: > So if > >> or, if it requires target authentication, with: >> >> CHAP_N= CHAP_R= CHAP_I= CHAP_C= >> >> If the initiator authentication fails, the target MUST >> answer with a >> Login reject with "Authentication Failure" status. >> Otherwise, if the >> initiator required target authentication, the target MUST either >> answer with a Login reject with "Authentication Failure" or reply >> with: >> >> CHAP_N= CHAP_R= > > And the target replys with CHAP_N that is not defined and the initiator > accepts that (accepts anything) is that valid behavior? In otherwords, > if the initiator ignores CHAP_N and only uses the target node name and > CHAP_R to authenticate, is that valid behavior? Shouldn't the target > be > able to force the use of CHAP_N? I'm confused. The initiator can't NOT use CHAP_N. Thus the target shouldn't be able to force something that's required. :-) To quote the paragraph after the one above: Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C and R are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes. So an initiator that just uses the target's name for CHAP purposes seems broken. Take care, Bill --Apple-Mail-7-164741680 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfDCCBXgw ggNgoAMCAQICAUYwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcg WW9yazERMA8GA1UEBxMITmV3IFlvcmsxHTAbBgNVBAoTFFdhc2FiaSBTeXN0ZW1zLCBJbmMuMQww CgYDVQQLEwNHSFExHzAdBgNVBAMTFldhc2FiaSBTeXN0ZW1zIFJvb3QgQ0ExKjAoBgkqhkiG9w0B CQEWG3dlYm1hc3RlckB3YXNhYmlzeXN0ZW1zLmNvbTAeFw0wMzA4MTExODU2NDZaFw0wODA2MjUx ODU2NDZaMIGXMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU2Fu IERpZWdvMRcwFQYDVQQKEw5XYXNhYmkgU3lzdGVtczEbMBkGA1UEAxMSV2lsbGlhbSBTdHVkZW5t dW5kMSkwJwYJKoZIhvcNAQkBFhp3cnN0dWRlbkB3YXNhYmlzeXN0ZW1zLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA9CZhg4GVWYTRGcJz8lU1ipzInlBuGqfZQs88Z1rTP7+c3AyhKwpE TyTmK4UhxslzKa93YLqifLxZKYt1jI6FNq40IQWCKBVywWBwmL5guCu0851f9ywH5Uj2wJdiDrOI sOJKNpwNqml8bFdTrFS2qvyCxTIWVMLYAzUBBcl2F7MCAwEAAaOCATkwggE1MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTt mjHbSBlMV48RWOBETM3EV0Tm/jCB2gYDVR0jBIHSMIHPgBQrBOnN88CNCHPaV5wLS212tcrgBaGB s6SBsDCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9y azEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMW V2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5 c3RlbXMuY29tggEAMA0GCSqGSIb3DQEBBAUAA4ICAQCpxoPEYunR7qiXyycEZd0UIatSt/WalMoH nuN9S421iS/sD1wSDqzHyM5YyUWn4z4o6VhT2kD9UV4lk5aXxxefEfGzFcR7Xyah7tO3ziuReFfx qUP5+DTlwDuUBc8Iow6NwY9GlRCKFSsEroLWLGODyYWgN1ojjKOtcXRiOZkYTP3VfDUV2/Xrhh9O l6+3Otf069+KWeOWedWeMsbe1rac96yPEjPogToWkBXVJEeEQktd0BLETt7GUuSZg2Fho/nslqZv nnnKZmrOfdFy9iXDL9T0Hp/OHf5B9RP+r00BJJFO8JzBPIL2IA3CBPApOQty5A00Jg1CGfDQxiV3 s8G0aRUbmFqg9r0OfhPYjJ8BHfw1HHWb7Cu91Sw+d5UnYracZhsR2Gc5H5CnfS6IZhc7ulfnSX8f I4BXR4vbeRUG76J3rkkbkO1haYHLk5w5RlICHsJOBSElG9ggLBWNIfUZwAzo84lfmDmJMP1YCOmi DFCbW1DgxhqVFpYEf5Pq2pVcCguopK2G9oZjH5fxq6ehisk9dN+7NEQ4OSqC43ehaStYOoQAJruN e6e5tCtRMx7bMI7eVPiHxE9/Y38Q+sc5oRN9mCyyAXMweuMRNHAHAWdFB7NhHD6gBa2lh91zIMdf iSVRlBXoMrBKJX6VecgnhvUp4G6QAnN7EMu6QHlc/jGCA0swggNHAgEBMIGzMIGtMQswCQYDVQQG EwJVUzERMA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExRXYXNh YmkgU3lzdGVtcywgSW5jLjEMMAoGA1UECxMDR0hRMR8wHQYDVQQDExZXYXNhYmkgU3lzdGVtcyBS b290IENBMSowKAYJKoZIhvcNAQkBFht3ZWJtYXN0ZXJAd2FzYWJpc3lzdGVtcy5jb20CAUYwCQYF Kw4DAhoFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQw OTMwMjIzMjE3WjAjBgkqhkiG9w0BCQQxFgQUtsHd1zr6xExC5GNAUHzmTbaOxRswgcQGCSsGAQQB gjcQBDGBtjCBszCBrTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhO ZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0G A1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBDQTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdh c2FiaXN5c3RlbXMuY29tAgFGMIHGBgsqhkiG9w0BCRACCzGBtqCBszCBrTELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEdMBsGA1UEChMUV2FzYWJpIFN5 c3RlbXMsIEluYy4xDDAKBgNVBAsTA0dIUTEfMB0GA1UEAxMWV2FzYWJpIFN5c3RlbXMgUm9vdCBD QTEqMCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQHdhc2FiaXN5c3RlbXMuY29tAgFGMA0GCSqGSIb3 DQEBAQUABIGAgqIRft2rsLCY0j09lhavkDZS5qngl6WEUqAFxjuQvfblkQTDq3qaTiOpjtkkAcyo e+gKIeojVDgynQVzJWeirY41WOVsPEwBkH2aVT0v8ws1sFURw2w+h/SqyxacHAU1WLveDyNsANAf 6XsAOnPpE0eFWcUF6BljXURHlBEjDXQAAAAAAAA= --Apple-Mail-7-164741680-- --Apple-Mail-8-164741685 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBXIl8DJT2Egh26K0RAgcBAJ4twfojEKeS9910Vpgul+HnZlZk9gCePdOT E/WuSnMGoTtUH2yTW6ftvx8= =3yCi -----END PGP SIGNATURE----- --Apple-Mail-8-164741685-- --===============0805047148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0805047148==-- From ips-bounces@ietf.org Thu Sep 30 19:51:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15039 for ; Thu, 30 Sep 2004 19:51:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDAq6-0007Jc-9I for ips-web-archive@ietf.org; Thu, 30 Sep 2004 19:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDAeb-0003vx-1n; Thu, 30 Sep 2004 19:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDALZ-0008NP-IA for ips@megatron.ietf.org; Thu, 30 Sep 2004 19:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13445 for ; Thu, 30 Sep 2004 19:28:21 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDATu-0006tj-C7 for ips@ietf.org; Thu, 30 Sep 2004 19:37:02 -0400 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel11.hp.com (Postfix) with ESMTP id 8B6356F16; Thu, 30 Sep 2004 16:28:23 -0700 (PDT) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Sep 2004 16:28:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Initiator CHAP authentication of target? Date: Thu, 30 Sep 2004 16:28:22 -0700 Message-ID: <95AC37E4A7C3304D94DB6AF7F64FA1B501513CEB@cacexc08.americas.cpqcorp.net> Thread-Topic: [Ips] Initiator CHAP authentication of target? Thread-Index: AcSnPWSkfY4xD3pwSCKhfYYut2DoMgABy59Q From: "Krueger, Marjorie" To: "William Studenmund" X-OriginalArrivalTime: 30 Sep 2004 23:28:23.0401 (UTC) FILETIME=[2DAB7590:01C4A745] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable It appears a certain initiator is ignoring CHAP_N returned by the target and just using the target node name for CHAP_N regardless of what the target sent in the login sequence. I think it seems like invalid behavior but I just wanted to check with this audience. Thanks Marjorie > -----Original Message----- > From: William Studenmund [mailto:wrstuden@wasabisystems.com]=20 > Sent: Thursday, September 30, 2004 3:32 PM > To: Krueger, Marjorie > Cc: ips@ietf.org > Subject: Re: [Ips] Initiator CHAP authentication of target? >=20 > On Sep 30, 2004, at 3:22 PM, Krueger, Marjorie wrote: >=20 > > So if > > > >> or, if it requires target authentication, with: > >> > >> CHAP_N=3D CHAP_R=3D CHAP_I=3D CHAP_C=3D > >> > >> If the initiator authentication fails, the target MUST answer=20 > >> with a > >> Login reject with "Authentication Failure" status. > >> Otherwise, if the > >> initiator required target authentication, the target=20 > MUST either > >> answer with a Login reject with "Authentication=20 > Failure" or reply > >> with: > >> > >> CHAP_N=3D CHAP_R=3D > > > > And the target replys with CHAP_N that is not defined and the=20 > > initiator accepts that (accepts anything) is that valid=20 > behavior? In=20 > > otherwords, if the initiator ignores CHAP_N and only uses=20 > the target=20 > > node name and CHAP_R to authenticate, is that valid behavior? =20 > > Shouldn't the target be able to force the use of CHAP_N? >=20 > I'm confused. The initiator can't NOT use CHAP_N. Thus the=20 > target shouldn't be able to force something that's required. :-) >=20 > To quote the paragraph after the one above: >=20 > Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, > Algorithm, Identifier, Challenge, and Response as defined in > [RFC1994], N is a text string, A,A1,A2, and I are=20 > numbers, and C and > R are large-binary-values and their binary length (not=20 > the length of > the character string that represents them in encoded=20 > form) MUST not > exceed 1024 bytes. >=20 > So an initiator that just uses the target's name for CHAP=20 > purposes seems broken. >=20 > Take care, >=20 > Bill >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips