Subject: current status of the RESCAP working group....

From: Michael Mealling <[email-masked]>
Date: Mon, 24 Jun 2002 08:32:53 -0400

Hi everyone,
  As you should see in a few days we have finally gotten current versions
of the requirements, scenarios and MUA documents out. In my opinion, the
scenarios and requirements documents look good enough to be published
as Informational. The MUA document desperately needs to be updated as
it has been surpassed by CONNEG and a few other related efforts. But
Paul has let me know that he will no longer be able to be author or editor
on the document. This leads me to a rather hard suggestion:

  Should we simply publish the scenarios and requirements documents and
close the group? The only mailing list discussion has been between
Keith and myself and that, at least to me, illustrates that most on the
mailing list don't see a need for the protocol. For those that do 
want to work on the protocol (like myself) we can continue using this
mailing list to do so. If the workign group still wants to proceed 
then we will need new authors/editors for just about all of the documents.

Comments?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: James M Galvin <[email-masked]>
Date: Mon, 24 Jun 2002 09:50:15 -0400 (EDT)

For completeness, as co-Chair I do agree we should publish what we have
and close down the group.

RESCAP started with high hopes years ago, as most working groups do.
But even for myself it has been overtaken by events.

If interest warrants at some later time we can always restart.  In any
case, individuals can continue to move forward and use the mailing list
to keep us all informed of their progress.

Jim

On Mon, 24 Jun 2002, Michael Mealling wrote:

    Date: Mon, 24 Jun 2002 08:32:53 -0400
    From: Michael Mealling <[email-masked]>
    To: [email-masked]
    Subject: current status of the RESCAP working group....

    Hi everyone,

    Comments?

    -MM

---

From: Michael Mealling <[email-masked]>
Date: Mon, 24 Jun 2002 10:43:01 -0400

On Mon, Jun 24, 2002 at 02:48:17PM +0100, Graham Klyne wrote:
> At 08:32 AM 6/24/02 -0400, you wrote:
> Given that there are some implementations, I'd have thought it was at least 
> worth publishing the current protocol documents as informational, just so 
> they don't expire.

Well, from my point of view the current protocol documents need to much
work to publish them as they currently stand. The perception would be that
the current documents would be the output of the group and I don't
think there's any way to get concensus on that yet. I as a co-chair
can't interpret working group concensus reliably when only 3 people ever 
post to the list.

Keith and I have been talking to each other on some issues with the
documents but we haven't come to any conclusions. So far it looks
as though he and I are the only implementers too. I would be much
more comfortable closing the group and "just doing it" on the list
as though we still were a group.

Just FYI, here are the issues I'm currently struggling with on the 
protocol documents:

1) The transport is still not specified concretely enough. I want to 
preserve the UDP transport but the "just send big packets" approach
causes problems. I personally would like to see some method of
doing protocol layer UDP packet reconstruction ala TFTP (without a session 
context so its not completely re-inventing TCP and doesn't suffer from DoS
attacks)

2) Attribute names needs better management. In many of the applications
I intend on using RESCAP for the attribute name is a URI and in many cases
its a URN (i.e. using the 'urn:ietf:params:' namespace). But Keith really
has problems with this approach (it does inflate the packet size 
considerably). I can't just dump it because those are the actual attribute
names that need to be used (see XKMS as an example). So what is the
recommended practice?

3) In almost all of the use cases I have the result of a query only
has one answer struct, hence I end up wasting a whole set of BLOB
headers on an answer BLOB when it would be more efficient and less
cumbersome to make a query_response look like this:

BEGIN query_response
string request_id
int query_status
int version_hi
int version_low
struct<> assertions
struct<> signatures
struct<> additional
END

4) An assertion's value is a string only. In many cases the value's returned
are lists of strings. Should we allow either a BLOB or a string or should
we simply say its always a string and list encoding is on a per attribute
basis? As an implementor I would prefer having one and only one way to
implement lists of strings (unless the attribute type specifies it already
as in MIME type lists (i.e. the Accept: header format).

Keith and I have been 'round and 'round on some of these with no real 
concensus even among the two of us. I personally wouldn't feel comfortable
publishing the current protocol documents until at least these 4 points
are addressed....

-MM

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 12:08:54 -0400

It seems to me that rescap has always lacked critical mass.
I don't see how it's been OBE (the problems still haven't been solved)
but it does seem to suffer from a chicken-and-egg problem.
and (perhaps unfortunatley) it's nearly always easier to get interest in 
developing a specific solution to a specific problem than to develop
a general solution to a general one.

we can keep the list open for those who want to discuss things,
and we can publish the documents either sooner as WG documents or
later as individual documents.  it doesn't really matter much to me;
at least for my own documents I would probably rather publish them
as individual submissions than to pretend that I had the support
of a WG when the WG only had 2 or 3 active members besides myself.

but having been on IESG I can say that even a dormant WG takes resources
(if nothing else, you have to periodically agonize over whether to kill
it or think about how to get it going).  so I suspect that we can free 
up IESG energy for more productive efforts if we disband.

Keith

> Date: Mon, 24 Jun 2002 09:50:15 -0400 (EDT)
> From: James M Galvin <[email-masked]>
> Subject: Re: current status of the RESCAP working group....
> In-reply-to: <[email-masked]>
> To: [email-masked]
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 12:37:28 -0400

> context so its not completely re-inventing TCP and doesn't suffer from DoS

mumble.  if you want to do better than having the fragements be reassembled
at the kernel layer, you really need selective ack or selective retransmit,
and that has an impact on server scalability.  the problem is that to do
selective retransmit the server needs to buffer the entire response until
it is sure that the client has received it, and by the time you add the
protocol machinery to do that you are (a) close to the protocol overhead of 
TCP and (b) you're doing the work in the server  rather than in the kernel
where it would be more efficient.  or you could just have the server redo
the query which avoids having a session context but doesn't make it immune
to DoS attacks.  DoS attacks are an issue any time an attacker can get the 
server to expend significant resources with only a small investment on 
the attacker's part, which is certainly the case for RC queries. 

I'm not saying it couldn't be done, I'm saying that it's somewhat tricky
to define it in such a way that it works better than TCP, and 
and it seems like a marginal gain.  If we did do it then we should expose
the request id and version #s in each response fragment, so that 
the server isn't actually required to save each response - it can 
redo the query if it wants.  also, we'd need to decide how to handle
non-idempotent requests. 
 
> names that need to be used (see XKMS as an example). So what is the

I think the current document is clear - URIs are permitted in attribute
names but RC doesn't insist that attribute names be URIs.  I think this
is the right approach, in that it allows RC to work with any attribute
set.  conflicts can be prevented by insisting that each set of 
attribute names have a unique (to RC) prefix, with URI prefixes
automatically reserved.

Personally I think that using URIs as attribute names is a bad idea,
but the fact that I think this shouldn't be a show stopper for the protocol,
since the protocol is (by design) mostly agnostic about the format of 
attribute names.
 
> cumbersome to make a query_response look like this:

sigh.  we could do this, but it makes the server code more complicated.
it's a tradeoff between protocol overhead and server overhead.
but it's not such a big impact on the server that I'll insist on 
keeping it the way it is, and if it will allow more packets to get
under the MTU without fragmentation then it might even be worth it.
so I'm willing to concede this one.

(though frankly if you're using URIs as attribute names then that 20 
or so bytes of extra blob overhead isn't going to matter much...)

> as in MIME type lists (i.e. the Accept: header format).

This is a separation-of-function issue.

RC tries very hard to be agnostic about the format of the data that it
carries, so that it can carry data from any data model.  The format
of the data carried by RC is defined by the data model, not RC.  If the 
data model wants to use a BLOB to format lists of items, that's fine 
with RC.  If the data model wants to use ASN.1/BER, that's fine with RC.
If it wants to use RFC822-style comma-separated lists, that's fine 
with RC.

RC could specify a recommended way of separting items in a list,
for use in data models that wanted to use it, but it shouldn't insist 
that lists be represented that way.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 13:22:42 -0400

> At 12:08 PM 6/24/02 -0400, Keith Moore wrote:
> Most people I hear of trying to do this kind of thing seem to be planning 
> to use HTTP -- which is architecturally sound, even if it's less 
> efficient.  Maybe the number of applications that need RESCAP-like 
> efficiency really isn't that great?

or maybe the need isn't perceived yet.   I see two things that are being 
missed:

1. using HTTP for web referrals significantly degrades response time,
   but it's the only thing available in the current architecture.
   this has ripple effects - not only does it needlessly slow down
   web access but it makes various kinds of replication and 
   content-selection more difficult to deploy.

2. for wireless/mobile hosts both bandwidth and delay issues are 
   more significant, and I expect to see a lot of wireless/mobile 
   hosts on the internet in the next few years.

so I guess I'd question whether use of HTTP for these purposes is
even architecturally sound.

still, it's difficult to sell something for which the need isn't
widely perceived, even if there is a genuine need there.

Keith

---

From: Graham Klyne <[email-masked]>
Date: Mon, 24 Jun 2002 14:48:17 +0100

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Mon, 24 Jun 2002 18:23:36 +0100

I see your point.  I wasn't fully aware of the problems, and assumed you'd 
some to some common view.

>context so its not completely re-inventing TCP and doesn't suffer from DoS

Paul Hoffman's original proposal had what I thought was an elegant 
solution:  make one attempt at using UDP, and if it fails for whatever 
reason (too large, packet loss), revert to TCP.

>names that need to be used (see XKMS as an example). So what is the

Yes, tough one that.  I'm with you on using URIs.  Can you get any benefit 
from a QName-like approach here;  assuming you have several URIs with a 
common prefix, separate then prefix from the local parts.  It depends on 
the application, of course, but I imagine that it could work quite well the 
way many XML- and URI-using applications seem to be constructed.

>as in MIME type lists (i.e. the Accept: header format).

While I could appreciate the aspirations of the BLOB approach, designed for 
rapid access into the transmitted structure, I was never completely 
convinced that this was the right trade-off.  I would have thought that, 
with modern hardware, the costs of separate serialization/deserialization 
would be acceptable cost compared with everything else that's going on.  I 
think the key areas to optimize here are round-trips and packet size.

Oh well.

#g
--

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Mon, 24 Jun 2002 18:26:47 +0100

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Michael Mealling <[email-masked]>
Date: Mon, 24 Jun 2002 14:15:41 -0400

> efficiency really isn't that great?

I think that's only valid when they're already using HTTP to interact
with the final resource. Yes, that's a large subset these days but its
not the entire network. If that were the case we'd be running DNS
over HTTP....

-MM

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 14:20:58 -0400

> some to some common view.

actually I thought we had come to a common view, it was a bit of a surprise
to find out that Michael thought there will still significant issues.
 
> reason (too large, packet loss), revert to TCP.

actually I think that's close to optimal - you have to work very hard
to do something that's even marginally better.
 
> think the key areas to optimize here are round-trips and packet size.

I'm not sure whether you're referring to the use of BLOBs to represent
lists of strings or the use of BLOBs in general.  I don't think that
BLOBs are a particularly good way to encode an attribute that will 
always be a list of strings because you always have that header 
present, but if data model authors want to use it that's their business. 
I don't think that XML is a good way to encode such things either,
but if data model authors want to use that, then that's their business.

As for using BLOBs for the RC protocol itself, I observed that for RCv1 
(which used ONC RPC) the majority of the code and the majority of the 
bugs found were related to marshalling issues, this despite using a 
canned package, and that the encoding and decoding also made a 
significant impact on the cpu time because of large numbers of function 
calls (which impact execution speed especially on processors without 
branch prediction), storage management overhead (due to excessive use 
of malloc and free), and memory-to-memory copying.  In other words, 
RC is a really simple protocol and doesn't have much else "going on",
so you really do notice the marshalling overhead when you try to make
the server handle lots of operations.

I wouldn't have bothered to invent BLOBs had ONC RPC not been such a pain.
But BLOBs are approximately as compact as ONC RPC's XDR (XDR uses 4-byte 
prefix counts rather than BLOB's 4-byte pointers, XDR doesn't have a header 
but does require that all strings be padded to 4 bytes, so it's a wash), 
significantly more compact than XML, and easier and more efficient to decode 
than XDR, XML, or anything I've seen used with ASN.1 - even if you're 
encoding and decoding the entire structure.  And the code and storage 
overhead required to encode/decode BLOBs is truly minimal.

If there's a significantly better trade-off I'd like to know what it is.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Mon, 24 Jun 2002 14:24:57 -0400

> to find out that Michael thought there will still significant issues.

It wasn't that I thought they were significant. I would still
prefer a solution more in line with my application but that's part of
the process. I posted those issues here to help illustrate that there
were issues to be discussed and that the protocol documents simply
couldn't be published 'as is'. If there is concensus (and I mean real
concensus, not just me, you and Graham) that they be published then
I've got no problem with it....

-MM

---

From: Michael Mealling <[email-masked]>
Date: Mon, 24 Jun 2002 14:38:21 -0400

> to do something that's even marginally better.

But that means that for packets over 1500 + 1 bytes I have a 10% chance of
failure (based on backbone statistics). That means 10% of the time I'll have 
a 20 some odd second timeout to contend with. Then I'll requiry with TCP.
That's unacceptable.  I could implement a client rule says if you
ever expect a large result then always query with TCP. But that seems
overkill when the odds are still in my favor that the result will be 
between 1500 and 3000 bytes. RESCAP will rarely ever have a result
that's over 3000 bytes. 

I don't think we have to 'work very hard' to do something that is marginally
better for what actually amounts to a large percentage of the protocol
traffic we'll be generating. TFTP is able to handle the problem quiet
nicely and IMHO should be a model for something like RESCAP.

> present, but if data model authors want to use it that's their business. 

Which was the 'an attribute can be a string or a blob encoded as a string'
compromise. You don't get the byte boundary alignment though. And yes,
you do waste a bunch of header stuff yet again. I was really hoping
for something in between 'string' and 'BLOB'. That's why I liked
stringarrays in the previous version of the BLOB.

> If there's a significantly better trade-off I'd like to know what it is.

I particularly like the BLOB approach. I think there are some spots that
could be tweaked to optimize for the most common types of queries and
responses...

-MM

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jun 2002 16:30:22 -0400

> That's unacceptable.  

well, I wouldn't wait more than 1 second for a response - I probably wouldn't
wait more than 500 msec.   even then I'd have to admit that having 10x 
additional delay (due to TCP setup/teardown) 10% of the time is not 
very attractive.

> I could implement a client rule says if you

hmm.  either way you have to retransmit the request after some timeout
interval.  even if you fragment at the application layer you still have
to wait something similar to your timeout interval to see whether all 
of the fragments get back before retransmitting.   (okay, you could 
assume something like that no fragment will take twice as long as the 
rtt of the first fragment received, so you revise your timeout interval
based on the rtt of the first fragement received.).

> nicely and IMHO should be a model for something like RESCAP.

Last I knew TFTP was not highly regarded in Internet Area circles.
I think that IESG folks (even for an Informational or Experimental
document) would want to make sure that whatever protocol were used
would compete fairly with TCP congestion control and not use 
excessive bandwidth.  I'm not sure that TFTP qualifies. It's been
a long time since I looked at it, but  IIRC TFTP is basically 
stop-and-wait, which means you're going to get a slow transfer.
For 1500-4500 bytes it might not matter much, but if the payloads
get bigger then you'd rather use TCP, and then you've got three 
transfer modes to worry about - UDP, TFTP, and TCP.

> compromise. 

Well, there's nothing in the current spec that prohibits an attribute value
being a blob - RC is completely transparent, and the value is opaque to RC.  
clients do have to worry about word-alignment problems, but that's not
an issue for the server since it never expects to decode the things.
in other words, RC doesn't care what the format of the value is.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Tue, 25 Jun 2002 14:46:10 -0400

On Mon, Jun 24, 2002 at 04:30:22PM -0400, Keith Moore wrote:
> interval.  

Yes.

> even if you fragment at the application layer you still have

Correct. It doesn't mitigate timeouts entirely in case of outright failure 
but it does solve the problem of optimizing the UDP packets so that their
odds of failure are smaller. I.e. if we keep UDP packet size at or 
under 512 bytes we have a high probability of success on subsequence
packets if the first one gets through. The "big packet" solution induces
higher failure rates by going directly up against the IP fragmentation
problems.

> Last I knew TFTP was not highly regarded in Internet Area circles.

As a file transfer system, yes. We're not transfering kernels here...

> stop-and-wait, which means you're going to get a slow transfer.

You don't necessarily need to do stop and wait but you can. I'm more
interested in the packet numbering and retransmission methods.

> transfer modes to worry about - UDP, TFTP, and TCP.

Nope, you just have two: 512 byte UDP packets with sequence numbers and
TCP. With a hard limit of anything over 100k being done over TCP.

> in other words, RC doesn't care what the format of the value is.

Correct. I think I personally still preferred the 'value can be a string
array' approach in the previous version of the BLOB. Both work though.
Heck, ASCII text delimited with Klingon battle symbols works. ;-)

-MM

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2002 15:37:28 -0400

> higher failure rates by going directly up against the IP fragmentation

note: 512 bytes is okay for IPv4, too small for IPv6.

> As a file transfer system, yes. We're not transfering kernels here...

actually I think it's considered "okay for LAN use, not good for WAN use"
because it doesn't perform well in those circumstances.

> interested in the packet numbering and retransmission methods.

I guess I'll have to reread the TFTP spec before getting too deeply into
this discussion, but IIRC the issue is that TFTP either has no flow control 
at all or a primitive flow control (i.e. no sliding windows, no congestion 
control, etc.)

> array' approach in the previous version of the BLOB. Both work though.

string arrays are still in BLOB, but I don't recall a version of RC that
allowed attribute values to be string arrays.  so I'm not sure what you mean
here.  RCv1 had typed data and one of those types was (IIRC) a list of 
strings, but it was never used for anything.   (and RCv1 predates BLOB)

> Heck, ASCII text delimited with Klingon battle symbols works. ;-)

which ASCII codepoint is the Klingon battle symbol?  it would come in
handy from time to time ...

Keith