From ips-bounces@ietf.org Thu Aug 16 13:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILjZr-0000BN-50; Thu, 16 Aug 2007 13:56:11 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1ILjZp-0000BF-O9 for ips-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 13:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILjZp-0000B7-EO for ips@ietf.org; Thu, 16 Aug 2007 13:56:09 -0400 Received: from fmailhost01.isp.att.net ([204.127.217.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILjZo-0006wv-2J for ips@ietf.org; Thu, 16 Aug 2007 13:56:09 -0400 Received: from ivvtdkv0981 (adsl-153-208-233.jax.bellsouth.net[70.153.208.233]) by bellsouth.net (frfwmhc01) with SMTP id <20070816175607H0100i383ae>; Thu, 16 Aug 2007 17:56:07 +0000 X-Originating-IP: [70.153.208.233] Message-ID: <000601c7e02e$a8a87c00$0602a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 16 Aug 2007 13:55:39 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ips] test 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="===============1695151235==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1695151235== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7E00D.211B1C50" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7E00D.211B1C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please disregard ------=_NextPart_000_0003_01C7E00D.211B1C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please disregard
------=_NextPart_000_0003_01C7E00D.211B1C50-- --===============1695151235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1695151235==-- From ips-bounces@ietf.org Sat Aug 18 11:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMPua-00015L-RZ; Sat, 18 Aug 2007 11:08:24 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IMPuZ-00015E-Mx for ips-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 11:08:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMPuZ-000155-Cq for ips@ietf.org; Sat, 18 Aug 2007 11:08:23 -0400 Received: from smtp112.plus.mail.sp1.yahoo.com ([69.147.95.75]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IMPuY-0005aM-VN for ips@ietf.org; Sat, 18 Aug 2007 11:08:23 -0400 Received: (qmail 9351 invoked from network); 18 Aug 2007 15:08:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:Importance; b=bY/W271uRQTmFb+VQowHzXOtiQ/AX8kABe4A5F6ydi7NsKBMqzZOC56gBMGJ/36ZkPZ+J05f8TehxTcpMeIyBZKDU3Xl9oXNPgCNs80LAnFuYrqSlCh83vgMhoXAKq3U2So90hV80iQ8+Sls7UtpfZK8q6G1aSFCcUvbwer4qjo= ; Received: from unknown (HELO abhi) (ram_sunee@71.136.186.192 with login) by smtp112.plus.mail.sp1.yahoo.com with SMTP; 18 Aug 2007 15:08:22 -0000 X-YMail-OSG: 3ODG.xIVM1ml6MObnRjYAHMV4KczCtDfb_U1NMHqyPORJ58ytIMymKaKm7dxh9xS8IQAKoqkyw-- From: "RAM SUNEE" To: "Ips" Date: Sat, 18 Aug 2007 08:08:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: High X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ips] DefaultTime2Retain Negotiation during Discovery Session X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hello, During LoginOperational negotiation phase of Discovery Session, Initiator didn't initiate negogiation for DefaultTime2Retain key. Target tried to negotiate for this key a value of 0,but initiator tried to enter full feature phase without responding to this specific key. In this case what target is supposed to do? Also, if the same situation happens during Normal Session,what the target is supposed to do? Thanks, Ram. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Aug 18 11:30:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMQEO-0000Il-Bn; Sat, 18 Aug 2007 11:28:52 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IMQEN-0000Ig-KO for ips-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 11:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMQEN-0000IY-AJ for ips@ietf.org; Sat, 18 Aug 2007 11:28:51 -0400 Received: from smtpout.mac.com ([17.250.248.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMQEM-00069s-SK for ips@ietf.org; Sat, 18 Aug 2007 11:28:51 -0400 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout14/MantshX 4.0) with ESMTP id l7IFSnuN006871; Sat, 18 Aug 2007 08:28:50 -0700 (PDT) Received: from wrstuden-mbp.home.54thstreetzoo.com (wsip-72-214-2-130.sd.sd.cox.net [72.214.2.130]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l7IFSn2m017211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Aug 2007 08:28:49 -0700 (PDT) From: William Studenmund To: RAM SUNEE In-Reply-To: Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session X-Priority: 1 (Highest) References: Message-Id: <1E6F8FA8-D149-482C-9903-75BD9FC08554@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v898) Date: Sat, 18 Aug 2007 08:28:48 -0700 X-Mailer: Apple Mail (2.898) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > Hello, > > During LoginOperational negotiation phase of Discovery Session, > Initiator > didn't initiate negogiation for DefaultTime2Retain key. > Target tried to negotiate for this key a value of 0,but initiator > tried to > enter full feature phase without responding to this specific key. > In this case what target is supposed to do? What do you mean "tried to enter full feature phase without responding"? It sent back an empty PDU requesting transitioning to FFP? Did the target correctly not offer to transition to FFP (did not set the 'T' bit in the login response)? The target should not set the 'T' bit and it should wait for the initiator to answer, and eventually time out the login. From the RFC: 12.16. DefaultTime2Retain Use: LO Senders: Initiator and Target Scope: SW DefaultTime2Retain= Default is 20. Result function is Minimum. So it's valid to negotiate in a discovery session. > Also, if the same situation happens during Normal Session,what the > target is > supposed to do? Same thing. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Aug 18 12:47:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMRRG-0002dU-5Q; Sat, 18 Aug 2007 12:46:14 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IMRRE-0002dN-Nf for ips-confirm+ok@megatron.ietf.org; Sat, 18 Aug 2007 12:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMRRE-0002dE-E9 for ips@ietf.org; Sat, 18 Aug 2007 12:46:12 -0400 Received: from smtp125.plus.mail.sp1.yahoo.com ([69.147.95.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IMRRE-0002r4-0g for ips@ietf.org; Sat, 18 Aug 2007 12:46:12 -0400 Received: (qmail 48680 invoked from network); 18 Aug 2007 16:46:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:Importance:In-Reply-To; b=Y7+2bcTicj0vHlZnY9fSKuBftsxEOWD+bw+1F8290prb+LNKrY1Wr/r8J57mJgwNgiLWAgX/CUuk7VtLy4oCP2yQfd4kfjqWzIviL9/lJ0OIzSmHr7eA4plbwXhtn3vYUZ/ehe6pLC/6WQGVlACUHdD6zw6cvRTC38R5snb5HPo= ; Received: from unknown (HELO abhi) (ram_sunee@71.136.186.192 with login) by smtp125.plus.mail.sp1.yahoo.com with SMTP; 18 Aug 2007 16:46:11 -0000 X-YMail-OSG: H7ArNjAVM1lqtzrV6n_zjcOmBbZljPFppgKxdJZMQv5yup.BZwMpWS8Q9ofNR418pPuJ2ggT4A-- From: "RAM SUNEE" To: "Ips" , "William Studenmund" Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Sat, 18 Aug 2007 09:46:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: High In-Reply-To: <1E6F8FA8-D149-482C-9903-75BD9FC08554@mac.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----Original Message----- From: William Studenmund [mailto:wrstuden@mac.com] Sent: Saturday, August 18, 2007 8:29 AM To: RAM SUNEE Cc: Ips Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > Hello, > > During LoginOperational negotiation phase of Discovery Session, > Initiator > didn't initiate negogiation for DefaultTime2Retain key. > Target tried to negotiate for this key a value of 0,but initiator > tried to > enter full feature phase without responding to this specific key. > In this case what target is supposed to do? What do you mean "tried to enter full feature phase without responding"? It sent back an empty PDU requesting transitioning to FFP? Did the target correctly not offer to transition to FFP (did not set the 'T' bit in the login response)? The target should not set the 'T' bit and it should wait for the initiator to answer, and eventually time out the login. From the RFC: 12.16. DefaultTime2Retain Use: LO Senders: Initiator and Target Scope: SW DefaultTime2Retain= Default is 20. Result function is Minimum. So it's valid to negotiate in a discovery session. RAM> Target didn't set 'T' bit when it sent Login response with DefaultTime2Retain key. What I mean here is that Intiator responded back with a Login request with an empty PDU(no keys), requesting transition to FFP. Because initiator responded back here, there is no question of timing out the login.What is the correct way the target should handle this? > Also, if the same situation happens during Normal Session,what the > target is > supposed to do? Same thing. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Aug 19 23:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMyCT-0000K6-AF; Sun, 19 Aug 2007 23:45:09 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IMyCR-0000K0-Ef for ips-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 23:45:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMyCQ-0000IE-MA for ips@ietf.org; Sun, 19 Aug 2007 23:45:06 -0400 Received: from ts.adaptec.com ([162.62.93.58] helo=mail-gw3.adaptec.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IMyCP-0002NK-T9 for ips@ietf.org; Sun, 19 Aug 2007 23:45:06 -0400 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 510471A9FD5; Sun, 19 Aug 2007 20:45:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Sun, 19 Aug 2007 20:45:00 -0700 Message-ID: <368FBF3D8437A748BA8222526BF93099024A0B82@aime2k302.adaptec.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DefaultTime2Retain Negotiation during Discovery Session Thread-Index: Acfip/1baWzfPeuxSl6vfgpePVyPbgAM2pqw References: <1E6F8FA8-D149-482C-9903-75BD9FC08554@mac.com> From: "Sandars, Ken" To: "RAM SUNEE" , "Ips" , "William Studenmund" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi Ram, So you're probably in a delightful loop where the initiator sends an empty Login request PDU which requests a transition to FFP, and the target responds with an empty Login response refusing to transit. This goes on forever, and probably quite quickly. Two valid target implementations to break out of this are: 1. Limit the number of Login responses the target will send before it gives up. Let this be a gross number - say over a hundred, a thousand, whatever you prefer. 2. Limit the duration from the start of the TCP connection to reaching FFP. If the login phase goes over your arbitrary limit, terminate the sequence. Cheers Ken -----Original Message----- From: RAM SUNEE [mailto:ram_sunee@yahoo.com]=20 Sent: Sunday, 19 August 2007 02:46 To: Ips; William Studenmund Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High -----Original Message----- From: William Studenmund [mailto:wrstuden@mac.com] Sent: Saturday, August 18, 2007 8:29 AM To: RAM SUNEE Cc: Ips Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > Hello, > > During LoginOperational negotiation phase of Discovery Session,=20 > Initiator didn't initiate negogiation for DefaultTime2Retain key. > Target tried to negotiate for this key a value of 0,but initiator=20 > tried to enter full feature phase without responding to this specific=20 > key. > In this case what target is supposed to do? What do you mean "tried to enter full feature phase without responding"? It sent back an empty PDU requesting transitioning to FFP? Did the target correctly not offer to transition to FFP (did not set the 'T' bit in the login response)? The target should not set the 'T' bit and it should wait for the initiator to answer, and eventually time out the login. From the RFC: 12.16. DefaultTime2Retain Use: LO Senders: Initiator and Target Scope: SW DefaultTime2Retain=3D Default is 20. Result function is Minimum. So it's valid to negotiate in a discovery session. RAM> Target didn't set 'T' bit when it sent Login response with DefaultTime2Retain key. What I mean here is that Intiator responded back with a Login request with an empty PDU(no keys), requesting transition to FFP. Because initiator responded back here, there is no question of timing out the login.What is the correct way the target should handle this? > Also, if the same situation happens during Normal Session,what the=20 > target is supposed to do? Same thing. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 01:14:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMzYr-0000xh-BX; Mon, 20 Aug 2007 01:12:21 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IMzYq-0000xb-KN for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 01:12:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMzYp-0000vh-Dj for ips@ietf.org; Mon, 20 Aug 2007 01:12:19 -0400 Received: from smtpout.mac.com ([17.250.248.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMzYn-0001ZZ-Vh for ips@ietf.org; Mon, 20 Aug 2007 01:12:19 -0400 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout14/MantshX 4.0) with ESMTP id l7K5CH27005903; Sun, 19 Aug 2007 22:12:17 -0700 (PDT) Received: from [17.151.76.128] ([17.151.76.128]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l7K5CGAI004712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 19 Aug 2007 22:12:17 -0700 (PDT) From: William Studenmund To: RAM SUNEE In-Reply-To: Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session X-Priority: 1 (Highest) References: Message-Id: <5A7FB95C-5E0A-48F1-BBB0-5578486D75C5@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v898) Date: Sun, 19 Aug 2007 22:12:16 -0700 X-Mailer: Apple Mail (2.898) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote: > On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > >> Hello, >> >> During LoginOperational negotiation phase of Discovery Session, >> Initiator >> didn't initiate negogiation for DefaultTime2Retain key. >> Target tried to negotiate for this key a value of 0,but initiator >> tried to >> enter full feature phase without responding to this specific key. >> In this case what target is supposed to do? > > What do you mean "tried to enter full feature phase without > responding"? It sent back an empty PDU requesting transitioning to > FFP? Did the target correctly not offer to transition to FFP (did not > set the 'T' bit in the login response)? The target should not set the > 'T' bit and it should wait for the initiator to answer, and eventually > time out the login. > > From the RFC: > 12.16. DefaultTime2Retain > > Use: LO Senders: Initiator and Target Scope: SW > > DefaultTime2Retain= > > Default is 20. Result function is Minimum. > > So it's valid to negotiate in a discovery session. > > RAM> Target didn't set 'T' bit when it sent Login response with > DefaultTime2Retain key. > What I mean here is that Intiator responded back with a Login > request with > an empty PDU(no keys), requesting transition to FFP. > Because initiator responded back here, there is no question of > timing out > the login.What is the correct way the target should handle this? The target should send back an empty PDU denying the transition to FFP. There certainly is a question of timing out the login. :-) It is perfectly reasonable for a target to terminate a login that doesn't complete after a number of replies. Ken mentioned 100 or 1000 PDUs. I'd set the limit lower, say at 20. Another option is to keep the count low, say 10, and reset it when you get a reasonable PDU. I also recommend that if you kill a login attempt for this reason (didn't complete, were outstanding Keys), log why you're doingthis and what keys were outstanding. This will help customers escalate the issue w/ the initiator vendor. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 11:12:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8uG-0002fN-EY; Mon, 20 Aug 2007 11:11:04 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IN8uF-0002dv-8Y for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 11:11:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8uE-0002cs-Si for ips@ietf.org; Mon, 20 Aug 2007 11:11:02 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN8uE-00020C-Bz for ips@ietf.org; Mon, 20 Aug 2007 11:11:02 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 20 Aug 2007 08:10:59 -0700 X-IronPort-AV: i="4.19,285,1183359600"; d="scan'208"; a="3966293:sNHT36066690" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Mon, 20 Aug 2007 08:10:58 -0700 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D546@MERCURY.inside.istor.com> In-Reply-To: <5A7FB95C-5E0A-48F1-BBB0-5578486D75C5@mac.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DefaultTime2Retain Negotiation during Discovery Session Thread-Index: Acfi6RNl4Fh+E5YtTtq83h8kdNX2VgAUthqA From: "Ken Craig" To: "William Studenmund" , "RAM SUNEE" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org William, Wouldn't it also be legal for the Target to terminate the Login with a response code of Initiator Error after the receipt of the first empty PDU since the value was offered by the Target but not returned by the Initiator? Thanks, Ken Craig -----Original Message----- From: William Studenmund [mailto:wrstuden@mac.com]=20 Sent: Sunday, August 19, 2007 10:12 PM To: RAM SUNEE Cc: Ips Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote: > On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > >> Hello, >> >> During LoginOperational negotiation phase of Discovery Session,=20 >> Initiator didn't initiate negogiation for DefaultTime2Retain key. >> Target tried to negotiate for this key a value of 0,but initiator >> tried to >> enter full feature phase without responding to this specific key. >> In this case what target is supposed to do? > > What do you mean "tried to enter full feature phase without=20 > responding"? It sent back an empty PDU requesting transitioning to=20 > FFP? Did the target correctly not offer to transition to FFP (did not=20 > set the 'T' bit in the login response)? The target should not set the=20 > 'T' bit and it should wait for the initiator to answer, and eventually > time out the login. > > From the RFC: > 12.16. DefaultTime2Retain > > Use: LO Senders: Initiator and Target Scope: SW > > DefaultTime2Retain=3D > > Default is 20. Result function is Minimum. > > So it's valid to negotiate in a discovery session. > > RAM> Target didn't set 'T' bit when it sent Login response with > DefaultTime2Retain key. > What I mean here is that Intiator responded back with a Login > request with > an empty PDU(no keys), requesting transition to FFP. > Because initiator responded back here, there is no question of =20 > timing out > the login.What is the correct way the target should handle this? The target should send back an empty PDU denying the transition to FFP. There certainly is a question of timing out the login. :-) It is =20 perfectly reasonable for a target to terminate a login that doesn't =20 complete after a number of replies. Ken mentioned 100 or 1000 PDUs. =20 I'd set the limit lower, say at 20. Another option is to keep the =20 count low, say 10, and reset it when you get a reasonable PDU. I also recommend that if you kill a login attempt for this reason =20 (didn't complete, were outstanding Keys), log why you're doingthis and =20 what keys were outstanding. This will help customers escalate the =20 issue w/ the initiator vendor. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 14:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INBpd-0000MF-FH; Mon, 20 Aug 2007 14:18:29 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1INBpW-0000Eq-OV for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 14:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INBpW-0000Dv-0r for ips@ietf.org; Mon, 20 Aug 2007 14:18:22 -0400 Received: from web37106.mail.mud.yahoo.com ([209.191.85.108]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INBpU-0004zN-Ki for ips@ietf.org; Mon, 20 Aug 2007 14:18:21 -0400 Received: (qmail 67367 invoked by uid 60001); 20 Aug 2007 18:18:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PkzHXQR8E1WQggZ/aQJR1WHvJ/cei5s+CRgzla0DYfEN2mptc1scyZbPEExyzUpayDCef84kBffg2O9YQAWvyiHZq4GdUWaV2NgzIDaAhb6y37qn47OMUpEMYXcAF7inRRsgf4fW1bK0OCX1mNB6YJP3JUAZyJikYwssE0GV5bA=; X-YMail-OSG: nYgAkpQVM1kkzfgumlB5t1BxL1hExllwZbRRWzRi2EeyKDtVD_D45VNRAjR3cRkBGbwhHVzFqA-- Received: from [12.170.66.34] by web37106.mail.mud.yahoo.com via HTTP; Mon, 20 Aug 2007 11:18:20 PDT Date: Mon, 20 Aug 2007 11:18:20 -0700 (PDT) From: RAMS Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session To: William Studenmund , ips@ietf.org In-Reply-To: <5A7FB95C-5E0A-48F1-BBB0-5578486D75C5@mac.com> MIME-Version: 1.0 Message-ID: <243351.66898.qm@web37106.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0029031572==" Errors-To: ips-bounces@ietf.org --===============0029031572== Content-Type: multipart/alternative; boundary="0-1395101254-1187633900=:66898" Content-Transfer-Encoding: 8bit --0-1395101254-1187633900=:66898 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Please see below between William Studenmund wrote: On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote: > On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > >> Hello, >> >> During LoginOperational negotiation phase of Discovery Session, >> Initiator >> didn't initiate negogiation for DefaultTime2Retain key. >> Target tried to negotiate for this key a value of 0,but initiator >> tried to >> enter full feature phase without responding to this specific key. >> In this case what target is supposed to do? > > What do you mean "tried to enter full feature phase without > responding"? It sent back an empty PDU requesting transitioning to > FFP? Did the target correctly not offer to transition to FFP (did not > set the 'T' bit in the login response)? The target should not set the > 'T' bit and it should wait for the initiator to answer, and eventually > time out the login. > > From the RFC: > 12.16. DefaultTime2Retain > > Use: LO Senders: Initiator and Target Scope: SW > > DefaultTime2Retain= > > Default is 20. Result function is Minimum. > > So it's valid to negotiate in a discovery session. > > RAM> Target didn't set 'T' bit when it sent Login response with > DefaultTime2Retain key. > What I mean here is that Intiator responded back with a Login > request with > an empty PDU(no keys), requesting transition to FFP. > Because initiator responded back here, there is no question of > timing out > the login.What is the correct way the target should handle this? The target should send back an empty PDU denying the transition to FFP. There certainly is a question of timing out the login. :-) It is perfectly reasonable for a target to terminate a login that doesn't complete after a number of replies. Ken mentioned 100 or 1000 PDUs. I'd set the limit lower, say at 20. Another option is to keep the count low, say 10, and reset it when you get a reasonable PDU. I also recommend that if you kill a login attempt for this reason (didn't complete, were outstanding Keys), log why you're doingthis and what keys were outstanding. This will help customers escalate the issue w/ the initiator vendor. How much is the DefaultTime2Retain key important, when only error recovery level '0' was supported by iSCSI Target? Is it mandatory that there should be a successful negotiation for this specific key, to progress the login into full feature phase? My understanding of RFC3720 is, this key is only meaningful only if error recovery level negotiated is '1' or above(i.e '2') Take care, Bill --0-1395101254-1187633900=:66898 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Please see below between <RAM> </RAM>

William Studenmund <wrstuden@mac.com> wrote:
On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote:

> On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote:
>
>> Hello,
>>
>> During LoginOperational negotiation phase of Discovery Session,
>> Initiator
>> didn't initiate negogiation for DefaultTime2Retain key.
>> Target tried to negotiate for this key a value of 0,but initiator
>> tried to
>> enter full feature phase without responding to this specific key.
>> In this case what target is supposed to do?
>
> What do you mean "tried to enter full feature phase without
> responding"? It sent back an empty PDU requesting transitioning to
> FFP? Did the target correctly not offer to transition to FFP (did not
> set the 'T' bit in the login response)? The target should not set the
> 'T' bit and it should wait for the initiator to answer, and eventually
> time out the login.
>
> From the RFC:
> 12.16. DefaultTime2Retain
>
> Use: LO Senders: Initiator and Target Scope: SW
>
> DefaultTime2Retain=
>
> Default is 20. Result function is Minimum.
>
> So it's valid to negotiate in a discovery session.
>
> RAM> Target didn't set 'T' bit when it sent Login response with
> DefaultTime2Retain key.
> What I mean here is that Intiator responded back with a Login
> request with
> an empty PDU(no keys), requesting transition to FFP.
> Because initiator responded back here, there is no question of
> timing out
> the login.What is the correct way the target should handle this?

The target should send back an empty PDU denying the transition to FFP.

There certainly is a question of timing out the login. :-) It is
perfectly reasonable for a target to terminate a login that doesn't
complete after a number of replies. Ken mentioned 100 or 1000 PDUs.
I'd set the limit lower, say at 20. Another option is to keep the
count low, say 10, and reset it when you get a reasonable PDU.

I also recommend that if you kill a login attempt for this reason
(didn't complete, were outstanding Keys), log why you're doingthis and
what keys were outstanding. This will help customers escalate the
issue w/ the initiator vendor.
 
<RAM> How much is the DefaultTime2Retain key important, when only error recovery level '0' was supported by iSCSI Target?  Is it mandatory that there should be a successful negotiation for this specific key, to progress the login into full feature phase? My understanding of RFC3720 is, this key is only meaningful only if error recovery level negotiated is '1' or above(i.e '2')
</RAM>

Take care,

Bill

--0-1395101254-1187633900=:66898-- --===============0029031572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0029031572==-- From ips-bounces@ietf.org Mon Aug 20 14:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCB6-0001Qz-Ij; Mon, 20 Aug 2007 14:40:40 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1INCB4-0001Qo-QZ for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 14:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCB4-0001Qg-H2 for ips@ietf.org; Mon, 20 Aug 2007 14:40:38 -0400 Received: from smtpout.mac.com ([17.250.248.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INCB2-0005gy-Ty for ips@ietf.org; Mon, 20 Aug 2007 14:40:38 -0400 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id l7KIea6u019691; Mon, 20 Aug 2007 11:40:36 -0700 (PDT) Received: from [17.151.76.128] ([17.151.76.128]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l7KIeTtj020903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2007 11:40:35 -0700 (PDT) Message-Id: From: William Studenmund To: RAMS In-Reply-To: <243351.66898.qm@web37106.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v898) Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Mon, 20 Aug 2007 11:40:28 -0700 References: <243351.66898.qm@web37106.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.898) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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="===============1625393726==" Errors-To: ips-bounces@ietf.org --===============1625393726== Content-Type: multipart/alternative; boundary=Apple-Mail-7-1022114944 --Apple-Mail-7-1022114944 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 20, 2007, at 11:18 AM, RAMS wrote: > Please see below between > > William Studenmund wrote: > On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote: > > > RAM> Target didn't set 'T' bit when it sent Login response with > > DefaultTime2Retain key. > > What I mean here is that Intiator responded back with a Login > > request with > > an empty PDU(no keys), requesting transition to FFP. > > Because initiator responded back here, there is no question of > > timing out > > the login.What is the correct way the target should handle this? > > The target should send back an empty PDU denying the transition to > FFP. > > There certainly is a question of timing out the login. :-) It is > perfectly reasonable for a target to terminate a login that doesn't > complete after a number of replies. Ken mentioned 100 or 1000 PDUs. > I'd set the limit lower, say at 20. Another option is to keep the > count low, say 10, and reset it when you get a reasonable PDU. > > I also recommend that if you kill a login attempt for this reason > (didn't complete, were outstanding Keys), log why you're doingthis and > what keys were outstanding. This will help customers escalate the > issue w/ the initiator vendor. > > How much is the DefaultTime2Retain key important, when only > error recovery level '0' was supported by iSCSI Target? Is it > mandatory that there should be a successful negotiation for this > specific key, to progress the login into full feature phase? My > understanding of RFC3720 is, this key is only meaningful only if > error recovery level negotiated is '1' or above(i.e '2') > DefaultTime2Retain has a default value, so if you're happy with that, you don't need to negotiate. Ever. If the target makes an offer, the initiator has to answer. In my opinion, ERL 1 doesn't change DefaultTime2Retain's meaning much. ERL 1 is about recovery within a connection, and leaves what happens when a connection fails up in the air. Since DefaultTime2Retain deals with what happens when a connection fails, they deal with orthogonal concepts. In my experience, the thing that adds lots of complexity isn't directly going to ERL 2, it's supporting MaxConnections > 1. A session with two FFP connections and ERL 0 has a lot of recovery stuff going on. Put another way, most of what people think of for ERL 2 actually comes with ERL 0 && MaxConenctions > 1. DefaultTime2Retain directly matters for ERL 0 as it sets a timer for the session to fail out. Session failure constitutes an I-T Nexus loss, which can have SCSI consequences. If all your target supports is READ(10) and WRITE(10) (or READ(16) and WRITE(16)) and one connection, you won't notice DefaultTime2Retain much. But if you support more features, say multiple connections and/ or SCSI Reservations (Persistent or otherwise), then it becomes important. Take care, Bill --Apple-Mail-7-1022114944 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Aug 20, 2007, at = 11:18 AM, RAMS wrote:

Please see = below between <RAM> </RAM>

William Studenmund = <wrstuden@mac.com> = wrote:
On Aug 18, = 2007, at 9:46 AM, RAM SUNEE = wrote:

> RAM> Target didn't set = 'T' bit when it sent Login response with
> DefaultTime2Retain = key.
> What I mean here is that Intiator responded back with a = Login
> request with
> an empty PDU(no keys), requesting = transition to FFP.
> Because initiator responded back here, there = is no question of
> timing out
> the login.What is the = correct way the target should handle this?

The target should send = back an empty PDU denying the transition to FFP.

There certainly = is a question of timing out the login. :-) It is
perfectly = reasonable for a target to terminate a login that doesn't
complete = after a number of replies. Ken mentioned 100 or 1000 PDUs.
I'd set = the limit lower, say at 20. Another option is to keep the
count low, = say 10, and reset it when you get a reasonable PDU.

I also = recommend that if you kill a login attempt for this reason
(didn't = complete, were outstanding Keys), log why you're doingthis and
what = keys were outstanding. This will help customers escalate the
issue = w/ the initiator vendor.
=
 
<RAM> How much is the = DefaultTime2Retain key important, when only error recovery level = '0' was supported by iSCSI Target?  Is it mandatory that there = should be a successful negotiation for this specific key, to progress = the login into full feature phase? My understanding of RFC3720 is, this = key is only meaningful only if error recovery level negotiated is '1' or = above(i.e '2')
=
</RAM>

DefaultTim= e2Retain has a default value, so if you're happy with that, you don't = need to negotiate. Ever.

If the target makes an = offer, the initiator has to answer.

In my opinion, ERL 1 = doesn't change DefaultTime2Retain's meaning much. ERL 1 is about = recovery within a connection, and leaves what happens when a connection = fails up in the air. Since DefaultTime2Retain deals with what happens = when a connection fails, they deal with orthogonal = concepts.

In = my experience, the thing that adds lots of complexity isn't directly = going to ERL 2, it's supporting MaxConnections > 1. A session with = two FFP connections and ERL 0 has a lot of recovery stuff going on. Put = another way, most of what people think of for ERL 2 actually comes with = ERL 0 && MaxConenctions > 1.

DefaultTime2Retain = directly matters for ERL 0 as it sets a timer for the session to fail = out. Session failure constitutes an I-T Nexus loss, which can have SCSI = consequences.

If all your target = supports is READ(10) and WRITE(10) (or READ(16) and WRITE(16)) and one = connection, you won't notice DefaultTime2Retain much. But if you support = more features, say multiple connections and/or SCSI Reservations = (Persistent or otherwise), then it becomes important.

Take care,

Bill
= --Apple-Mail-7-1022114944-- --===============1625393726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1625393726==-- From ips-bounces@ietf.org Mon Aug 20 15:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCeQ-0000aN-PF; Mon, 20 Aug 2007 15:10:58 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1INCeO-0000aG-Mp for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 15:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCeO-0000a8-Cn for ips@ietf.org; Mon, 20 Aug 2007 15:10:56 -0400 Received: from mail1.pillardata.com ([63.251.178.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INCeN-0006a9-4O for ips@ietf.org; Mon, 20 Aug 2007 15:10:56 -0400 Received: from coex02.trans.corp ([172.18.24.19]) by mail1.pillardata.com with ESMTP; 20 Aug 2007 13:10:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Mon, 20 Aug 2007 13:11:11 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE03DA71A9@coex02.trans.corp> In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D546@MERCURY.inside.istor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DefaultTime2Retain Negotiation during Discovery Session Thread-Index: Acfi6RNl4Fh+E5YtTtq83h8kdNX2VgAUthqAAAesRRA= From: "Paul Hughes" To: "Ken Craig" , "William Studenmund" , "RAM SUNEE" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I think it's legal to terminate a login if a proposed key is not = answered in the next login request/response (with exceptions for Boolean = negotiations having optional responses). I don't think RFC3720 states = this explicitly, but this seems to indicate that initiators and targets = should not delay answering a proposed key: 5.2. Text Mode Negotiation A target or initiator SHOULD NOT use a Text or Login Response or Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule. My interpretation is that DefaultTime2Retain requires an answer and does = not require an empty PDU request/response, therefore the acceptor must = answer in the next login request/response. Thanks, Paul -----Original Message----- From: Ken Craig [mailto:kcraig@istor.com] Sent: Monday, August 20, 2007 9:11 AM To: William Studenmund; RAM SUNEE Cc: Ips Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session William, Wouldn't it also be legal for the Target to terminate the Login with a response code of Initiator Error after the receipt of the first empty PDU since the value was offered by the Target but not returned by the Initiator? Thanks, Ken Craig -----Original Message----- From: William Studenmund [mailto:wrstuden@mac.com]=20 Sent: Sunday, August 19, 2007 10:12 PM To: RAM SUNEE Cc: Ips Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote: > On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > >> Hello, >> >> During LoginOperational negotiation phase of Discovery Session,=20 >> Initiator didn't initiate negogiation for DefaultTime2Retain key. >> Target tried to negotiate for this key a value of 0,but initiator >> tried to >> enter full feature phase without responding to this specific key. >> In this case what target is supposed to do? > > What do you mean "tried to enter full feature phase without=20 > responding"? It sent back an empty PDU requesting transitioning to=20 > FFP? Did the target correctly not offer to transition to FFP (did not=20 > set the 'T' bit in the login response)? The target should not set the=20 > 'T' bit and it should wait for the initiator to answer, and eventually > time out the login. > > From the RFC: > 12.16. DefaultTime2Retain > > Use: LO Senders: Initiator and Target Scope: SW > > DefaultTime2Retain=3D > > Default is 20. Result function is Minimum. > > So it's valid to negotiate in a discovery session. > > RAM> Target didn't set 'T' bit when it sent Login response with > DefaultTime2Retain key. > What I mean here is that Intiator responded back with a Login > request with > an empty PDU(no keys), requesting transition to FFP. > Because initiator responded back here, there is no question of =20 > timing out > the login.What is the correct way the target should handle this? The target should send back an empty PDU denying the transition to FFP. There certainly is a question of timing out the login. :-) It is =20 perfectly reasonable for a target to terminate a login that doesn't =20 complete after a number of replies. Ken mentioned 100 or 1000 PDUs. =20 I'd set the limit lower, say at 20. Another option is to keep the =20 count low, say 10, and reset it when you get a reasonable PDU. I also recommend that if you kill a login attempt for this reason =20 (didn't complete, were outstanding Keys), log why you're doingthis and =20 what keys were outstanding. This will help customers escalate the =20 issue w/ the initiator vendor. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 15:30:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCvy-0004X7-TM; Mon, 20 Aug 2007 15:29:06 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1INCvy-0004Vk-7E for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 15:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCvx-0004TZ-T7 for ips@ietf.org; Mon, 20 Aug 2007 15:29:05 -0400 Received: from smtpout.mac.com ([17.250.248.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INCvw-0007Cq-Jy for ips@ietf.org; Mon, 20 Aug 2007 15:29:05 -0400 Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id l7KJT4kL013299; Mon, 20 Aug 2007 12:29:04 -0700 (PDT) Received: from [17.151.76.128] ([17.151.76.128]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l7KJSxau013863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2007 12:29:04 -0700 (PDT) Message-Id: <8214FE5E-F0E3-4EB3-B9E1-5AD1191B6F22@mac.com> From: William Studenmund To: Paul Hughes In-Reply-To: <16236EEEF4D4264DA31C2E35E3607CFE03DA71A9@coex02.trans.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v898) Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Mon, 20 Aug 2007 12:28:58 -0700 References: <16236EEEF4D4264DA31C2E35E3607CFE03DA71A9@coex02.trans.corp> X-Mailer: Apple Mail (2.898) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote: > I think it's legal to terminate a login if a proposed key is not > answered in the next login request/response (with exceptions for > Boolean negotiations having optional responses). I don't think > RFC3720 states this explicitly, but this seems to indicate that > initiators and targets should not delay answering a proposed key: > > 5.2. Text Mode Negotiation > > A target or initiator SHOULD NOT use a Text or Login Response or > Text > or Login Request with no data segment (DataSegmentLength 0) unless > explicitly required by a general or a key-specific negotiation rule. > > My interpretation is that DefaultTime2Retain requires an answer and > does not require an empty PDU request/response, therefore the > acceptor must answer in the next login request/response. In the example we're talking about, I think terminating negotiation would be fine. The thing though is that the text above is a SHOULD NOT, not MUST NOT. So there _could_ be a good reason for delaying. I can think of one, but I admit it's a corner case. Say the initiator has made key offers to the target which the target hasn't responded to. Say the target then offers a key, but in order to answer, the initiator needs to know the answer to the offers it made. In this case, it seems appropriate for the initiator to send an empty PDU, so that the target can answer the offers the initiator made (and the target didn't answer last pass). I admit that's a corner case. And we could have a real problem if both sides want the answer from the other to respond. I also can't see why we'd run into this with the current set of keys. The only explicit tiering we have is with the marker keys, and the initiator can offer both "do markers" and "markers are at X" in one offer, then the target can answer yes or no on markers and "Irrelevant" for the interval if it says no. So I think an immediate terminate is OK, and waiting for a few round trips is OK too. As an aside I wonder if the initiator implementation is getting confused by the offer of 0 (which is PERFECTLY VALID) and internally overloading 0 with "nothing to do." Ram, can you tell is which initiator is doing this? It's OK if you can't. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 15:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IND2Z-0001Ol-4i; Mon, 20 Aug 2007 15:35:55 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IND2Y-0001Np-7X for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 15:35:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IND2X-0001Mm-TK for ips@ietf.org; Mon, 20 Aug 2007 15:35:53 -0400 Received: from exprod8og58.obsmtp.com ([64.18.3.98]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IND2X-0001yp-FS for ips@ietf.org; Mon, 20 Aug 2007 15:35:53 -0400 Received: from source ([12.110.134.31]) by exprod8ob58.obsmtp.com ([64.18.7.12]) with SMTP; Mon, 20 Aug 2007 12:35:26 PDT Received: from pkoning-laptop.equallogic.com.equallogic.com ([172.25.202.120]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 15:35:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18121.60665.446507.312750@pkoning-laptop.equallogic.com> Date: Mon, 20 Aug 2007 15:35:21 -0400 From: Paul Koning To: wrstuden@mac.com Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session References: <16236EEEF4D4264DA31C2E35E3607CFE03DA71A9@coex02.trans.corp> <8214FE5E-F0E3-4EB3-B9E1-5AD1191B6F22@mac.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 20 Aug 2007 19:35:27.0876 (UTC) FILETIME=[43001440:01C7E361] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Errors-To: ips-bounces@ietf.org >>>>> "William" == William Studenmund writes: William> On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote: >> I think it's legal to terminate a login if a proposed key is not >> answered in the next login request/response (with exceptions for >> Boolean negotiations having optional responses). I don't think >> RFC3720 states this explicitly, but this seems to indicate that >> initiators and targets should not delay answering a proposed key: >> >> 5.2. Text Mode Negotiation >> >> A target or initiator SHOULD NOT use a Text or Login Response or >> Text or Login Request with no data segment (DataSegmentLength 0) >> unless explicitly required by a general or a key-specific >> negotiation rule. >> >> My interpretation is that DefaultTime2Retain requires an answer >> and does not require an empty PDU request/response, therefore the >> acceptor must answer in the next login request/response. William> In the example we're talking about, I think terminating William> negotiation would be fine. William> The thing though is that the text above is a SHOULD NOT, not William> MUST NOT. So there _could_ be a good reason for delaying. I William> can think of one, but I admit it's a corner case. If the spec says a sender SHOULD NOT do X, then the receiving end is NOT allowed to insist that the sender do X. So that means that terminating the negotiation would be a protocol violation, because it produces a failure to interoperate with a conforming sender. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 15:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IND5C-0002eN-J6; Mon, 20 Aug 2007 15:38:38 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IND5B-0002eG-1H for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 15:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IND5A-0002e8-O3 for ips@ietf.org; Mon, 20 Aug 2007 15:38:36 -0400 Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IND59-0007V6-Df for ips@ietf.org; Mon, 20 Aug 2007 15:38:36 -0400 Received: from mercury.inside.istor.com ([192.168.50.30]) by stork.inside.istor.com with ESMTP; 20 Aug 2007 12:38:32 -0700 X-IronPort-AV: i="4.19,285,1183359600"; d="scan'208"; a="3967228:sNHT26395430" Content-class: urn:content-classes:message Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2007 12:38:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D54B@MERCURY.inside.istor.com> In-Reply-To: <8214FE5E-F0E3-4EB3-B9E1-5AD1191B6F22@mac.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] DefaultTime2Retain Negotiation during Discovery Session Thread-Index: AcfjYGoustkt539SQwOKDR+FpauNVQAAGifA From: "Ken Craig" To: "William Studenmund" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org William, To me the fact that the Initiator attempted to transition to FFP without answering the key is reason enough to terminate the login with an error. Thanks, Ken Craig -----Original Message----- From: William Studenmund [mailto:wrstuden@mac.com]=20 Sent: Monday, August 20, 2007 12:29 PM To: Paul Hughes Cc: Ips Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote: > I think it's legal to terminate a login if a proposed key is not > answered in the next login request/response (with exceptions for =20 > Boolean negotiations having optional responses). I don't think =20 > RFC3720 states this explicitly, but this seems to indicate that =20 > initiators and targets should not delay answering a proposed key: > > 5.2. Text Mode Negotiation > > A target or initiator SHOULD NOT use a Text or Login Response or > Text > or Login Request with no data segment (DataSegmentLength 0) unless > explicitly required by a general or a key-specific negotiation rule. > > My interpretation is that DefaultTime2Retain requires an answer and > does not require an empty PDU request/response, therefore the =20 > acceptor must answer in the next login request/response. In the example we're talking about, I think terminating negotiation =20 would be fine. The thing though is that the text above is a SHOULD NOT, not MUST NOT. =20 So there _could_ be a good reason for delaying. I can think of one, =20 but I admit it's a corner case. Say the initiator has made key offers to the target which the target =20 hasn't responded to. Say the target then offers a key, but in order to =20 answer, the initiator needs to know the answer to the offers it made. =20 In this case, it seems appropriate for the initiator to send an empty =20 PDU, so that the target can answer the offers the initiator made (and =20 the target didn't answer last pass). I admit that's a corner case. And we could have a real problem if both =20 sides want the answer from the other to respond. I also can't see why =20 we'd run into this with the current set of keys. The only explicit =20 tiering we have is with the marker keys, and the initiator can offer =20 both "do markers" and "markers are at X" in one offer, then the target =20 can answer yes or no on markers and "Irrelevant" for the interval if =20 it says no. So I think an immediate terminate is OK, and waiting for a few round =20 trips is OK too. As an aside I wonder if the initiator implementation is getting =20 confused by the offer of 0 (which is PERFECTLY VALID) and internally =20 overloading 0 with "nothing to do." Ram, can you tell is which =20 initiator is doing this? It's OK if you can't. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 20 16:02:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDQa-0003Td-4v; Mon, 20 Aug 2007 16:00:44 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1INDQZ-0003TQ-0k for ips-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 16:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDQY-0003TI-MU for ips@ietf.org; Mon, 20 Aug 2007 16:00:42 -0400 Received: from smtpout.mac.com ([17.250.248.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INDQY-0002fi-9X for ips@ietf.org; Mon, 20 Aug 2007 16:00:42 -0400 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/smtpout14/MantshX 4.0) with ESMTP id l7KK0egl020936; Mon, 20 Aug 2007 13:00:40 -0700 (PDT) Received: from [17.151.76.128] ([17.151.76.128]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l7KK0W4Y006200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2007 13:00:40 -0700 (PDT) Message-Id: From: William Studenmund To: Ken Craig In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D54B@MERCURY.inside.istor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v898) Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Date: Mon, 20 Aug 2007 13:00:32 -0700 References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D54B@MERCURY.inside.istor.com> X-Mailer: Apple Mail (2.898) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Ips X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Aug 20, 2007, at 12:38 PM, Ken Craig wrote: > William, > > To me the fact that the Initiator attempted to > transition to FFP without answering the key is > reason enough to terminate the login with an > error. True. I agree. It depends on why we want to kill the login attempt. :-) I think that an empty PDU alone isn't enough, especially given Paul Konig's comment about interoperation. Trying to skip answering a key, however is. Good call. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 21 14:50:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYlt-0005KY-9t; Tue, 21 Aug 2007 14:48:09 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1INYls-0005KS-32 for ips-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 14:48:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYlr-0005KK-Oa for ips@ietf.org; Tue, 21 Aug 2007 14:48:07 -0400 Received: from web51707.mail.re2.yahoo.com ([206.190.38.225]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INYlr-0000AY-5O for ips@ietf.org; Tue, 21 Aug 2007 14:48:07 -0400 Received: (qmail 26699 invoked by uid 60001); 21 Aug 2007 18:48:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=GgPD10ut+gg2+15CqhxyzthigpIITH96KwGRF0xyxnAl5i62TSxUQIY8Y3Y/NeqAv5qAsw0iEIFvC2l9bkcG2tVTYQdtCX48hkVschqUDPv/TddAGaOLJ9u/PleiEN1OyBHcCtNQRYz2IGftHZOXyRcb0PfKg7f/aT0ERqwb3C0=; X-YMail-OSG: RoRKUdIVM1lQHSBKvyaXTZnyWZkgw7xEdsWciTDlAwVgUNNF5giRhuL_RFlzS0Iowj_OH.6rMHuyOmQC5xwZduNKbeHaQ..IVJbgGEMOp8s6E5Q6z5ftiY.Q3k9aV9IWrB9q22SQHdQd7ww- Received: from [15.203.169.124] by web51707.mail.re2.yahoo.com via HTTP; Tue, 21 Aug 2007 11:48:06 PDT Date: Tue, 21 Aug 2007 11:48:06 -0700 (PDT) From: "Mallikarjun C." Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session To: Ips In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <837780.25744.qm@web51707.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Given the default ErrorRecoveryLevel=0 and MaxConnections=1 for the Discovery session, the only thing an initiator would get by a non-zero DefaultTime2Retain is session continuation (jump straight from FAILED to LOGGED_IN) when the only connection in the session fails. Typical motivation for a session continuation then is avoiding SCSI side effects related to I_T nexus loss, and there wouldn't be any obviously for a Discovery session anyway. Given all that, it's unlikely that an initiator would attempt a session continuation for a Discovery session at all. On its part OTOH, it's not an undue burden for a target to support it if a continuation were attempted - minimal state, primarily around TSIH & Initiator Port, I'd imagine. None of this justifies what appears a negotiation protocol violation identified on this thread. Mallikarjun --- William Studenmund wrote: > On Aug 20, 2007, at 12:38 PM, Ken Craig wrote: > > > William, > > > > To me the fact that the Initiator attempted to > > transition to FFP without answering the key is > > reason enough to terminate the login with an > > error. > > True. I agree. > > It depends on why we want to kill the login attempt. > :-) > > I think that an empty PDU alone isn't enough, > especially given Paul > Konig's comment about interoperation. > > Trying to skip answering a key, however is. Good > call. > > Take care, > > Bill > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 31 05:53:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3Ah-00019q-39; Fri, 31 Aug 2007 05:52:11 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IR3Ag-00017c-0A for ips-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 05:52:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3Ac-00012b-4l for ips@ietf.org; Fri, 31 Aug 2007 05:52:06 -0400 Received: from web30108.mail.mud.yahoo.com ([209.191.69.40]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IR3Ab-0006UO-HQ for ips@ietf.org; Fri, 31 Aug 2007 05:52:05 -0400 Received: (qmail 19204 invoked by uid 60001); 31 Aug 2007 09:52:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=0AxxQeoFtu3vXLifu9Y6pAaDUT8lIee+1da6kEeMsnhRdp4DPm/pI71cMmm4lEWPxtAdl2INv8hgIpiIXpgCZThXtn01AtTaagPnQ7S7aPzX2Fg21DA7mhgt0C+wLwjDBjIlL4p1vIsEA9MtWJPH+0JPi/QAT4curNf3hav8eGE=; X-YMail-OSG: gCBl.3kVM1nxu1yet_LX0fIWE90UkmcW9vmRrBnmfrUwtU9bw8gn5OW0eVFnerGbtPSHbkYFxzvsNBGYCdyKfdznLe1F.T4FsB745o4cETMnUYr2L3SmQgJ5RTHSVw-- Received: from [61.12.16.156] by web30108.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2007 02:52:04 PDT Date: Fri, 31 Aug 2007 02:52:04 -0700 (PDT) From: Parav Pandit To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <921981.18764.qm@web30108.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ips] rationale to send PDUs in increasing CmdSn on single connection X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi, RFC 3720, section 3.2.2.1 says "On any connection, the iSCSI initiator MUST send the commands in increasing order of CmdSN, except for commands that are retransmitted due to digest error recovery and connection recovery. " (Assuming Single TCP connection ISCSI session) 1. I interpret above 3.2.2.1 statement as SCSI layer gives SCSI commands to the ISCSI stack in the order of Cmd-1 and Cmd-2. Cmd-1 will have CmdSn = 10. Cmd-2 will have CmdSn = 11. ISCSI stack CAN send PDUs to the TCP layer in following order ONLY. PDU-1 with Cmd-1. PDU-2 with Cmd-2. Is this correct interpretation? Or 2. On a SINGLE connection can ISCSI stack send the PDU-1 with Cmd-2 followed by PDU-2 with Cmd-1? Assuming the answer of the question #2 is No, 3. If there are multiple connections in a session then command MAY any way reach out of order. And targets need to wait for the previous expected commands. So targets will receive out of order ISCSI PDUs from the TCP layer and ISCSI stack handles them. So then why initiators have restriction of sending command in the increasing order of CmdSn on SINGLE TCP connection? Is it to simplify the implementation of targets supporting only single TCP connection? Regards, Parav Pandit ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 31 11:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8oi-00071A-2v; Fri, 31 Aug 2007 11:53:52 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IR8oh-000714-E5 for ips-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 11:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8oh-00070v-4Y for ips@ietf.org; Fri, 31 Aug 2007 11:53:51 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8of-00022h-IA for ips@ietf.org; Fri, 31 Aug 2007 11:53:51 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l7VFrmrW308080 for ; Fri, 31 Aug 2007 15:53:48 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7VFrmht2134044 for ; Fri, 31 Aug 2007 17:53:48 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7VFrmIa015357 for ; Fri, 31 Aug 2007 17:53:48 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7VFrmdH015354; Fri, 31 Aug 2007 17:53:48 +0200 In-Reply-To: <921981.18764.qm@web30108.mail.mud.yahoo.com> References: <921981.18764.qm@web30108.mail.mud.yahoo.com> To: Parav Pandit MIME-Version: 1.0 Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn on single connection X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Julian Satran Message-ID: Date: Fri, 31 Aug 2007 18:53:46 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 31/08/2007 18:53:47, Serialize complete at 31/08/2007 18:53:47 X-Spam-Score: -4.0 (----) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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="===============0253834226==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0253834226== Content-Type: multipart/alternative; boundary="=_alternative 00574814C2257348_=" This is a multipart message in MIME format. --=_alternative 00574814C2257348_= Content-Type: text/plain; charset="US-ASCII" Parav Pandit wrote on 31/08/2007 12:52:04: > Hi, > > RFC 3720, section 3.2.2.1 says > > "On any connection, the iSCSI initiator MUST send the > commands in increasing order of CmdSN, except for > commands that are retransmitted due to digest error > recovery and connection recovery. " > > (Assuming Single TCP connection ISCSI session) > > 1. I interpret above 3.2.2.1 statement as > SCSI layer gives SCSI commands to the ISCSI stack in > the order of Cmd-1 and Cmd-2. > Cmd-1 will have CmdSn = 10. > Cmd-2 will have CmdSn = 11. > ISCSI stack CAN send PDUs to the TCP layer in > following order ONLY. > PDU-1 with Cmd-1. > PDU-2 with Cmd-2. > > Is this correct interpretation? > Or > Yes > 2. On a SINGLE connection can ISCSI stack send the > PDU-1 with Cmd-2 followed by > PDU-2 with Cmd-1? > NO > Assuming the answer of the question #2 is No, > > 3. If there are multiple connections in a session then > command MAY any way reach out of order. And targets > need to wait for the previous expected commands. > > So targets will receive out of order ISCSI PDUs from > the TCP layer and ISCSI stack handles them. > > So then why initiators have restriction of sending > command in the increasing order of CmdSn on SINGLE TCP > connection? > To simplify recovery and to... > Is it to simplify the implementation of targets > supporting only single TCP connection? > > and there was no visible motivation for out of order commands on a single connection > Regards, > Parav Pandit > > > > > ____________________________________________________________________________________ > Looking for a deal? Find great prices on flights and hotels with > Yahoo! FareChase. > http://farechase.yahoo.com/ > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00574814C2257348_= Content-Type: text/html; charset="US-ASCII"

Parav Pandit <paravpandit@yahoo.com> wrote on 31/08/2007 12:52:04:

> Hi,
>  
> RFC 3720, section 3.2.2.1 says
>
> "On any connection, the iSCSI initiator MUST send the
> commands in increasing order of CmdSN, except for
> commands that are retransmitted due to digest error
> recovery and connection recovery. "
>
> (Assuming Single TCP connection ISCSI session)
>
> 1. I interpret above 3.2.2.1 statement as
> SCSI layer gives SCSI commands to the ISCSI stack in
> the order of Cmd-1 and Cmd-2.
> Cmd-1 will have CmdSn = 10.
> Cmd-2 will have CmdSn = 11.
> ISCSI stack CAN send PDUs to the TCP layer in
> following order ONLY.
> PDU-1 with Cmd-1.
> PDU-2 with Cmd-2.
>
> Is this correct interpretation?
> Or
>
Yes
> 2. On a SINGLE connection can ISCSI stack send the
> PDU-1 with Cmd-2 followed by
> PDU-2 with Cmd-1?
>
NO
> Assuming the answer of the question #2 is No,
>
> 3. If there are multiple connections in a session then
> command MAY any way reach out of order. And targets
> need to wait for the previous expected commands.
>
> So targets will receive out of order ISCSI PDUs from
> the TCP layer and ISCSI stack handles them.
>
> So then why initiators have restriction of sending
> command in the increasing order of CmdSn on SINGLE TCP
> connection?
>
To simplify recovery and to...
> Is it to simplify the implementation of targets
> supporting only single TCP connection?
>
>

and there was no visible motivation for out of order commands on a single connection

> Regards,
> Parav Pandit
>
>
>
>        
> ____________________________________________________________________________________
> Looking for a deal? Find great prices on flights and hotels with
> Yahoo! FareChase.
> http://farechase.yahoo.com/
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 00574814C2257348_=-- --===============0253834226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0253834226==-- From ips-bounces@ietf.org Fri Aug 31 14:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRBKs-0003xz-17; Fri, 31 Aug 2007 14:35:14 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IRBKq-0003xs-Qz for ips-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 14:35:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRBKq-0003xk-FZ for ips@ietf.org; Fri, 31 Aug 2007 14:35:12 -0400 Received: from father.pmc-sierra.com ([216.241.224.13] helo=father.pmc-sierra.bc.ca) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRBKp-0007u6-JB for ips@ietf.org; Fri, 31 Aug 2007 14:35:12 -0400 Received: (qmail 19350 invoked by uid 101); 31 Aug 2007 18:35:08 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by father.pmc-sierra.com with SMTP; 31 Aug 2007 18:35:08 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l7VIZ7tU001875; Fri, 31 Aug 2007 11:35:08 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Aug 2007 11:35:07 -0700 Message-ID: From: David Sheehy To: Julian Satran , Parav Pandit Subject: RE: [Ips] rationale to send PDUs in increasing CmdSn on single co nnection Date: Fri, 31 Aug 2007 11:34:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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="===============1592949982==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1592949982== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EBFD.A171041C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7EBFD.A171041C Content-Type: text/plain > and there was no visible motivation for out of order commands on a single connection On the contrary, there was plenty of motivation. It was overridden by the desire for simplified implementations over single TCP connections as the Parav conjectured. There are DMA related efficiencies that can be realized in situations with a mix of solicited and immediate/unsolicited I/O traffic. The folks in favor of this optimization were outvoted by those who wanted to simplify their single connection based implementations. Dave _____ From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 31, 2007 8:54 AM To: Parav Pandit Cc: ips@ietf.org Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn on single connection Parav Pandit wrote on 31/08/2007 12:52:04: > Hi, > > RFC 3720, section 3.2.2.1 says > > "On any connection, the iSCSI initiator MUST send the > commands in increasing order of CmdSN, except for > commands that are retransmitted due to digest error > recovery and connection recovery. " > > (Assuming Single TCP connection ISCSI session) > > 1. I interpret above 3.2.2.1 statement as > SCSI layer gives SCSI commands to the ISCSI stack in > the order of Cmd-1 and Cmd-2. > Cmd-1 will have CmdSn = 10. > Cmd-2 will have CmdSn = 11. > ISCSI stack CAN send PDUs to the TCP layer in > following order ONLY. > PDU-1 with Cmd-1. > PDU-2 with Cmd-2. > > Is this correct interpretation? > Or > Yes > 2. On a SINGLE connection can ISCSI stack send the > PDU-1 with Cmd-2 followed by > PDU-2 with Cmd-1? > NO > Assuming the answer of the question #2 is No, > > 3. If there are multiple connections in a session then > command MAY any way reach out of order. And targets > need to wait for the previous expected commands. > > So targets will receive out of order ISCSI PDUs from > the TCP layer and ISCSI stack handles them. > > So then why initiators have restriction of sending > command in the increasing order of CmdSn on SINGLE TCP > connection? > To simplify recovery and to... > Is it to simplify the implementation of targets > supporting only single TCP connection? > > and there was no visible motivation for out of order commands on a single connection > Regards, > Parav Pandit > > > > > ____________________________________________________________________________________ > Looking for a deal? Find great prices on flights and hotels with > Yahoo! FareChase. > http://farechase.yahoo.com/ > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C7EBFD.A171041C Content-Type: text/html
> and there was no visible motivation for out of order commands on a single connection
 
On the contrary, there was plenty of motivation. It was overridden by the desire for simplified implementations over single TCP connections as the Parav conjectured. There are DMA related efficiencies that can be realized in situations with a mix of solicited and immediate/unsolicited I/O traffic. The folks in favor of this optimization were outvoted by those who wanted to simplify their single connection based implementations.
 
Dave

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 31, 2007 8:54 AM
To: Parav Pandit
Cc: ips@ietf.org
Subject: Re: [Ips] rationale to send PDUs in increasing CmdSn on single connection



Parav Pandit <paravpandit@yahoo.com> wrote on 31/08/2007 12:52:04:

> Hi,
>  
> RFC 3720, section 3.2.2.1 says
>
> "On any connection, the iSCSI initiator MUST send the
> commands in increasing order of CmdSN, except for
> commands that are retransmitted due to digest error
> recovery and connection recovery. "
>
> (Assuming Single TCP connection ISCSI session)
>
> 1. I interpret above 3.2.2.1 statement as
> SCSI layer gives SCSI commands to the ISCSI stack in
> the order of Cmd-1 and Cmd-2.
> Cmd-1 will have CmdSn = 10.
> Cmd-2 will have CmdSn = 11.
> ISCSI stack CAN send PDUs to the TCP layer in
> following order ONLY.
> PDU-1 with Cmd-1.
> PDU-2 with Cmd-2.
>
> Is this correct interpretation?
> Or
>
Yes
> 2. On a SINGLE connection can ISCSI stack send the
> PDU-1 with Cmd-2 followed by
> PDU-2 with Cmd-1?
>
NO
> Assuming the answer of the question #2 is No,
>
> 3. If there are multiple connections in a session then
> command MAY any way reach out of order. And targets
> need to wait for the previous expected commands.
>
> So targets will receive out of order ISCSI PDUs from
> the TCP layer and ISCSI stack handles them.
>
> So then why initiators have restriction of sending
> command in the increasing order of CmdSn on SINGLE TCP
> connection?
>
To simplify recovery and to...
> Is it to simplify the implementation of targets
> supporting only single TCP connection?
>
>

and there was no visible motivation for out of order commands on a single connection

> Regards,
> Parav Pandit
>
>
>
>        
> ____________________________________________________________________________________
> Looking for a deal? Find great prices on flights and hotels with
> Yahoo! FareChase.
> http://farechase.yahoo.com/
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 ------_=_NextPart_001_01C7EBFD.A171041C-- --===============1592949982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1592949982==--