SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: SACK (was RE:Async Message PDU)



    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
    > > ---------------------------------------------------
    > > 
    


Home

Last updated: Tue Sep 04 01:05:16 2001
6315 messages in chronological order