RE: WG chair on buffer exhaustion

I agree that the security draft should focus on requirements, not on
implementation details. I'll try to draft something up to be reviewed by
this group that doesn't choose one implementation over the other.



Jim




-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Caitlin Bestler
Sent: Tuesday, July 22, 2003 6:59 AM
To: Culley, Paul
Cc: [email protected]; [email protected]
Subject: Re: [rddp] WG chair on buffer exhaustion


On Tuesday, July 22, 2003, at 08:29 AM, Culley, Paul wrote:

> As pointed out earlier in this thread, the mechanism that returns
> "credits" for the "hard limit" can become an additional burden for
> implementations, depending on how that is done.  A "loose" credit
check
> and/or update can significantly reduce that burden.

As covered earlier on the list, I disagree that this is an unreasonable
burden on the iWARP implementation. The only thing required is a simple
credit count for each DDP stream endpoint

However, Pat Thaler's post did raise legitimate scenarios where 
maintaining
such a count would be an imposition on the local ULP. While I do not 
believe
they represent a typical strategy, they are valid.

So my suggestion is that the drafts move in the direction of being 
permissive
as to the *mechanism* by which the limit is enforced. The security 
draft should
note that use of a "soft" mechanism requires the local ULP to account 
for that
softness and have sufficient slack to absorb the delay. I'll point out 
that
a "soft" credit check combined with sequential ordering can require 
absorbing
a *lot* of slack.

But if a given local interface *can* work, then there is no reason not 
to allow it.
Security drafts should provide guidance on how to evaluate the impact 
of a specific
interface without enumerating them. Focusing on the two questions of 
*when* an invalid
MSN is detected and when a buffer is bound to an MSN provides this type 
of analysis
tool that should be applicable to any local interface.

The goal should remain that accepting an untagged message with an 
invalid MSN should
never put handling of a valid untagged message at risk -- especially 
when the valid
untagged message is part of a different session. (A "session" for these 
purposes is
a set of DDP Streams that serve the exact same set of masters. That is, 
if a fault
on Stream X impairs Stream Y, there is no party that has a complaint 
because at the
application layer Stream X and Stream Y do not represent distinct 
interests.
Generally, a session is a single stream.)

But I believe that goal can be stated without prescribing *specific* 
methods of
achieving it.





Caitlin Bestler - [email protected] - http://asomi.com/


_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp