RE: SACK (was RE:Async Message PDU)

[julian_satran@il.ibm.com]

how about SNACK?

Julo

Black_David@emc.com on 23/03/2001 06:52:20

Please respond to Black_David@emc.com

To:   marjorie_krueger@hp.com, ips@ece.cmu.edu
cc:
Subject:  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
> > ---------------------------------------------------
> >