RE: SACK (was RE:Async Message PDU)

["Mallikarjun C." <cbm@rose.hp.com>]

Thanks to Marjorie for raising this question again.

How about SRR (Selective Run Request)?
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com

>I think picking a new name for SACK to avoid confusion
>with TCP is an excellent idea.  Any suggestions for a
>new name?
>
>--David
>
>> -----Original Message-----
>> From:	KRUEGER,MARJORIE (HP-Roseville,ex1) [SMTP:marjorie_krueger@hp.com]
>> Sent:	Thursday, March 22, 2001 7:35 PM
>> To:	'Black_David@emc.com'; ips@ece.cmu.edu
>> Subject:	RE: SACK (was RE:Async Message PDU)
>> 
>> David,
>> Sorry for the delayed reaction, I'm just catching up - You stated that a
>> decision was made at the Orlando interim meeting to "change some of the
>> terminology with the goal of each term and acronym being unambiguously
>> owned
>> by a single layer in the protocol stack".  I think that's the right thing
>> to
>> do, so can we agree to rename SACK to something that doesn't cause
>> confusion
>> with the TCP construct?
>> 
>> Marjorie Krueger
>> Networked Storage Architecture
>> Networked Storage Solutions Org.
>> Hewlett-Packard
>> tel: +1 916 785 2656
>> fax: +1 916 785 0391
>> email: marjorie_krueger@hp.com 
>> 
>> > -----Original Message-----
>> > From: Black_David@emc.com [mailto:Black_David@emc.com]
>> > Sent: Thursday, March 01, 2001 11:37 AM
>> > To: cbm@rose.hp.com; ips@ece.cmu.edu
>> > Subject: RE: Async Message PDU
>> > 
>> > 
>> > Julian will doubtless pick up the rest of these,
>> > but I thought I'd take this issue, since it was
>> > part of what we did in Orlando.
>> > 
>> > > 4. Somehow, "Asynchronous Message" seems at odds with the 
>> > rest of the
>> > > usage in the draft in regards to PDUs (since a message is 
>> > introduced as
>> > > PDU in section 1.2).  Should we may be just call it an AEN 
>> > PDU?  Section
>> > > 2.14.3 calls this so.  (I realize that it may not always 
>> > result in a 
>> > > SCSI-level AER.)
>> > 
>> > One of the things we did in Orlando was to change
>> > some of the terminology with the goal of each term and
>> > acronym being unambiguously owned by a single layer
>> > in the protocol stack, in particular making a sharp
>> > distinction between SCSI concepts and iSCSI mechanisms.
>> > 
>> > All the *RN entities changed to *SN for this reason
>> > (SCSI has a CmdRN, so all *RN entities are SCSI, and
>> > all *SN entities are iSCSI).  Similarly, all AE*
>> > entities are SCSI, and we went with "Asynchronous
>> > Message <*>" to name the iSCSI entities.  This matters
>> > here because there are circumstances in which iSCSI
>> > will send Asynchronous Message PDUs for its own use
>> > even when SCSI has disabled AER.  The usage of "AEN
>> > PDU" in 2.14.3 is probably an editing oversight.
>> > Suggestions for words to use instead of "Message"
>> > are welcome, but they must not start with the letter
>> > "E" ;-).
>> > 
>> > Thanks,
>> > --David
>> > ---------------------------------------------------
>> > David L. Black, Senior Technologist
>> > EMC Corporation, 42 South St., Hopkinton, MA  01748
>> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
>> > black_david@emc.com       Mobile: +1 (978) 394-7754
>> > ---------------------------------------------------
>> > 
>