RE: SACK (was RE:Async Message PDU)

[Black_David@emc.com]

Let's see ... that's to report that something
ate some of the data that the receiver was
expecting, right :-) ??  Sounds like a
reasonable suggestion.

--David

> -----Original Message-----
> From:	julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> Sent:	Friday, March 23, 2001 10:43 AM
> To:	ips@ece.cmu.edu
> Subject:	RE: SACK (was RE:Async Message PDU)
> 
> 
> 
> 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
> > > ---------------------------------------------------
> > >
> 
>