Re: WG chair on buffer exhaustion (again)

Arkady,

Please note the

"....MUST however ensure that the affected DDP Segment 
  is eventually recovered ....way that guarantees ULP-transparency"

language in my suggested text.  So the proposed text does not 
change anything wrt RDMAP and thus the automatic STag 
invalidation, and of course the definition of reliable connection
stays the same as it was because the delivery semantics are still
in-order.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email protected]

----- Original Message ----- 
From: "Kanevsky, Arkady" <[email protected]>
To: <[email protected]>; <[email protected]>
Sent: Thursday, July 31, 2003 8:37 AM
Subject: RE: [rddp] WG chair on buffer exhaustion (again)


> David,
> I am trying to comprehand the 2 issues.
> 
> You stated that Mallikarjun's issue involves statistical (under-) 
> provisioning of buffers can happen without any Shared
> Receive queues.
> 1. What is the definition of reliable connection based on this change?
> 2. How does UPL knows/control what is the connection behavior:
> connection broken(termination DDP stream) if no recv buffer is
> availble vs.
> Send message dropped on the floor and not delivered, but DDP
> connection stays?
> 3. How is the Stag invalidation effected (if at all) with both proposals?
> 
> Thanks,
> Arkady
> 
> Arkady Kanevsky                                email: [email protected]
> Network Appliance                              phone: 781-768-5395
> 375 Totten Pond Rd.                            Fax: 781-895-1195
> 3rd Floor                                              http: www.netapp.com
> Waltham, MA 02451-2010                  general phone: 781-768-5300
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] 
> > Sent: Wednesday, July 30, 2003 5:40 PM
> > To: [email protected]
> > Subject: [rddp] WG chair on buffer exhaustion (again)
> > 
> > 
> > With WG Chair hat on, let me step into this debate:
> > 
> > > > Section 3.2 to:
> > > >     " Note, however, that the ULP needs to address flow control 
> > > > issues.
> > Any
> > > >       ULP that runs on DDP SHOULD consider the lack of an 
> > associated
> > receive
> > > >       buffer to place an inbound Untagged Message of the ULP as an
> > exception."
> > > 
> > > If the local interface has allows the DDP endpoint to know 
> > the valid 
> > > range of MSNs on a stream (which it will for simple Receive 
> > Queues at 
> > > the minimum) then it definitely SHOULD NOT consider the lack of a 
> > > buffer for an *invalid message* to be "an exception".
> > 
> > Two issues are getting conflated here, and need to be kept separate:
> > - Mallikarjun's issue involves statistical (under-) 
> > provisioning of buffers,
> > so that an otherwise valid untagged message shows up 
> > without a buffer
> > available to receive it (if the implementation had done 
> > worst-case
> > provisioning, there would have been a buffer 
> > available).  I believe
> > there is WG rough consensus that this is an exceptional 
> > condition
> > that does not need to immediately cause the termination 
> > of the DDP
> > stream that sent the message, but it SHOULD not occur 
> > frequently.
> > Mallikarjun's proposed text is close enough to what's 
> > needed for this.
> > This condition could happen even on a simple Receive Queue if
> > statistical (under-) provisioning is being used.
> > - Caitlin's issue involves a peer violating a fixed 
> > per-DDP-stream limit on
> > the number of untagged messages allowed .  At the 
> > moment, the exact
> > need and nature of such limits is still an open issue 
> > that needs to be
> > resolved in the context of the security draft.  When we 
> > have it resolved
> > there, additional text will (probably) get driven into 
> > the DDP draft.
> > If the issue is resolved in the manner Caitlin advocates, then
> > her proposed text is certainly a candidate for what the 
> > DDP draft
> > will need to say, but at the moment, the issue is open, and the
> > DDP draft should not change what it says about this issue until
> > it is resolved in the context of the security draft.
> > 
> > Also, I've seen some confusing references to iSER and 
> > assumptions about local interface and resource sharing model. 
> >  Shared Receive Queues have
> > *not* been approved/adopted by this WG (and can't be until we 
> > get the resource sharing issue [2nd bullet above] resolved).  
> > To the extent that iSER requires Shared Receive Queues and 
> > can't cope with any other local resource model, it's probably 
> > made an overly restrictive design assumption that it's 
> > designers would be well-advised to reconsider, keeping in 
> > mind that the Hilland verbs draft is at best an *example* of 
> > a local interface to RDDP; it should not be viewed as 
> > normative functional requirements on that local interface.
> > 
> > With luck, that's useful clarification, but feel free to ask 
> > if anything above doesn't make sense ...
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email protected]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> > 
> > _______________________________________________
> > rddp mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rddp
> > 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>