Subject: RE: [rddp] RDDP Buffer Issues

From: "Williams, Jim" <[email-masked]>
Date: Fri, 15 Nov 2002 12:33:47 -0500

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, November 14, 2002 7:52 PM
> To: [email-masked]'
> Cc: Williams, Jim
> Subject: Re: [rddp] RDDP Buffer Issues
>
> [...]
>
> So what you are proposing is a ULP restriction, or a
> requirement that the DDP actively prevent the ULP from being
> stupid. With limited exceptions, I do not believe this is an
> appropriate requirement. 

I won't go through your entire response point by point.  But I
think there is a philosophical difference between your
approach to protocol design and what I am proposing.  I also
think that many will agree with your philosophy, so I won't
try to convert you.  But I will at least try to make
clear my motivation here.

The primary goal is not to prevent the ULP from being
"stupid", although that may be a beneficial side effect.
The primary goal is to prevent the ULP from using 
other protocol layers in ways for which they were not
architected, particularly the transport layer.

If anything the goal is to prevent the ULP from being
"too clever".  If the ULP is designed so that its
proper operations depends on transport properties 
that are not architected, The ULP may work fine
and be quite "happy".  The problem is that
non-architectural dependencies are created between
layers.  The result of this is that the overall
internet architecture becomes very brittle and
difficult to evolve.  Architects and implementors
working on a specific protocol layer do things
that seem perfectly reasonable from their perspective,
but end up breaking some pre-existing ULP they
never even heard of.

The whole internet is currently suffering 
greatly from this type of problem.

So the ULP actually may have little incentive
to avoid being "stupid".  But the IETF can and
should have significant incentive to make sure
the "stupid" ULPs don't proliferate.
Figuring out a mechanism to prevent this is
not easy and requires work.  Understandably, 
this work may seem a bit silly and 
overly nit picking to those whose primary
interest is in getting an "ad hoc" solution
in place that works and doing it quickly.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 15 Nov 2002 13:51:21 -0600

On 11/15/02, Williams, Jim wrote:

>I won't go through your entire response point by point. 
>But I think there is a philosophical difference between
>your approach to protocol design and what I am proposing. 
>I also think that many will agree with your philosophy, so
>I won't try to convert you.  But I will at least try to
>make clear my motivation here.
>
>If anything the goal is to prevent the ULP from being "too
>clever".  If the ULP is designed so that its proper
>operations depends on transport properties that are not
>architected, The ULP may work fine and be quite "happy". 
>The problem is that non-architectural dependencies are
>created between layers.  The result of this is that the
>overall internet architecture becomes very brittle and
>difficult to evolve.  Architects and implementors working
>on a specific protocol layer do things that seem perfectly
>reasonable from their perspective, but end up breaking
>some pre-existing ULP they never even heard of.
>

I also agree that applications should be discouraged from
relying upon implementation quirks.

However, I view the fact that a ULP buffer advertisement is
ULP sliceable as a required feature, and not as an
implementation quirk.

I think a case can be made that the local ULP MUST be given
the ability to invalidate an STag synchronously with an
untagged received. This would have the benefit of avoiding
reliance upon a potentially suspect peer to avoid the
post-receive vunerability window. However, for reasons I
have covered earlier, I do not view it as a major
vunerability.

If the Data Sink ULP lacks trust in its peer, then it SHOULD
use one-shot STags that are enabled ONLY for the target
buffer. It SHOULD invalidate them manually before examining
the content of the received buffer, or disconnect if the
remote end failed to request the invalidation.

Those are not onerous restrictions, but mandating the
existence of a local invalidate option would improve the
situation. It certainly feels cleaner.

Beyond that, however, I do not see how any of your
suggestions can be made to work without requiring that all
STags be made one-shot transfer buffers. This is far from
optimum for a large number of applications.

I remain firmly convinced that management of shared buffers
is a ULP issue, and that the hardware MUST NOT impose any
standard solutions that all applications must follow.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Michael Krause <[email-masked]>
Date: Sun, 17 Nov 2002 08:34:33 -0800

>have covered earlier, I do not view it as a major

It is a local RNIC implementation issue that could be used by ULP for such 
purposes. -

>standard solutions that all applications must follow.

Agreed.

Mike