From owner-rescap@cs.utk.edu Mon Jun 24 08:36:01 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03504 for ; Mon, 24 Jun 2002 08:36:01 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id IAA11574; Mon, 24 Jun 2002 08:35:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 08:34:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA11543; Mon, 24 Jun 2002 08:34:45 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA11418; Mon, 24 Jun 2002 08:34:02 -0400 (EDT) Received: from bailey.dscga.com (198.78.11.130 -> bailey.neonym.net) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 08:34:02 -0400 Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5OCWruK022197 for ; Mon, 24 Jun 2002 08:32:54 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5OCWrxD022196 for rescap@cs.utk.edu; Mon, 24 Jun 2002 08:32:53 -0400 (EDT) Date: Mon, 24 Jun 2002 08:32:53 -0400 From: Michael Mealling To: rescap@cs.utk.edu Subject: current status of the RESCAP working group.... Message-ID: <20020624083253.P18666@bailey.dscga.com> Reply-To: Michael Mealling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i List-Owner: List-Post: List-Unsubscribe: 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 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Mon Jun 24 09:53:55 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07016 for ; Mon, 24 Jun 2002 09:53:54 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id JAA22083; Mon, 24 Jun 2002 09:53:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 09:52:59 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA22036; Mon, 24 Jun 2002 09:52:56 -0400 (EDT) Received: from one.elistx.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA21893; Mon, 24 Jun 2002 09:51:36 -0400 (EDT) Received: from one.elistx.com (209.116.252.130 -> one.elistx.com) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 09:51:36 -0400 Received: from isdn1-20.connext.net (isdn1-20.connext.net [216.4.158.180]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GY70006LQI8QH@eListX.com> for rescap@cs.utk.edu; Mon, 24 Jun 2002 09:51:45 -0400 (EDT) Date: Mon, 24 Jun 2002 09:50:15 -0400 (EDT) From: James M Galvin Subject: Re: current status of the RESCAP working group.... In-reply-to: <20020624083253.P18666@bailey.dscga.com> To: rescap@cs.utk.edu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Unsubscribe: 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 To: rescap@cs.utk.edu Subject: current status of the RESCAP working group.... 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 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Mon Jun 24 10:45:30 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09910 for ; Mon, 24 Jun 2002 10:45:29 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id KAA01708; Mon, 24 Jun 2002 10:44:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 10:44:50 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA01688; Mon, 24 Jun 2002 10:44:50 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA01449; Mon, 24 Jun 2002 10:44:12 -0400 (EDT) Received: from bailey.dscga.com (198.78.11.130 -> bailey.neonym.net) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 10:44:12 -0400 Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5OEh2uK022635; Mon, 24 Jun 2002 10:43:02 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5OEh2ha022634; Mon, 24 Jun 2002 10:43:02 -0400 (EDT) Date: Mon, 24 Jun 2002 10:43:01 -0400 From: Michael Mealling To: Graham Klyne Cc: Michael Mealling , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... Message-ID: <20020624104301.A22435@bailey.dscga.com> Reply-To: Michael Mealling References: <20020624083253.P18666@bailey.dscga.com> <5.1.0.14.2.20020624144521.038659d0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020624144521.038659d0@joy.songbird.com> User-Agent: Mutt/1.3.22.1i List-Owner: List-Post: List-Unsubscribe: On Mon, Jun 24, 2002 at 02:48:17PM +0100, Graham Klyne wrote: > At 08:32 AM 6/24/02 -0400, you wrote: > > 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. > > 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 -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Mon Jun 24 12:11:01 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14842 for ; Mon, 24 Jun 2002 12:11:00 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id MAA16069; Mon, 24 Jun 2002 12:10:19 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 12:10:18 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA16049; Mon, 24 Jun 2002 12:10:17 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA16033; Mon, 24 Jun 2002 12:10:16 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 12:10:16 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OG8s221377; Mon, 24 Jun 2002 12:08:54 -0400 (EDT) Message-Id: <200206241608.g5OG8s221377@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: James M Galvin cc: rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... In-reply-to: (Your message of "Mon, 24 Jun 2002 09:50:15 EDT.") Date: Mon, 24 Jun 2002 12:08:54 -0400 Sender: moore@cs.utk.edu List-Owner: List-Post: List-Unsubscribe: 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 > Subject: Re: current status of the RESCAP working group.... > In-reply-to: <20020624083253.P18666@bailey.dscga.com> > To: rescap@cs.utk.edu > > 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 From owner-rescap@cs.utk.edu Mon Jun 24 12:39:19 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16447 for ; Mon, 24 Jun 2002 12:39:18 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id MAA20378; Mon, 24 Jun 2002 12:38:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 12:38:54 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA20358; Mon, 24 Jun 2002 12:38:53 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA20342; Mon, 24 Jun 2002 12:38:51 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 12:38:51 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OGbS225195; Mon, 24 Jun 2002 12:37:28 -0400 (EDT) Message-Id: <200206241637.g5OGbS225195@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Mealling cc: Graham Klyne , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... In-reply-to: (Your message of "Mon, 24 Jun 2002 10:43:01 EDT.") <20020624104301.A22435@bailey.dscga.com> Date: Mon, 24 Jun 2002 12:37:28 -0400 Sender: moore@cs.utk.edu List-Owner: List-Post: List-Unsubscribe: > 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) 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. > 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? 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. > 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 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...) > 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). 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 owner-rescap@cs.utk.edu Mon Jun 24 13:24:48 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19121 for ; Mon, 24 Jun 2002 13:24:48 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id NAA29622; Mon, 24 Jun 2002 13:23:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 13:23:44 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA29572; Mon, 24 Jun 2002 13:23:40 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA29522; Mon, 24 Jun 2002 13:23:25 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 13:23:25 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OHMg201858; Mon, 24 Jun 2002 13:22:42 -0400 (EDT) Message-Id: <200206241722.g5OHMg201858@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Graham Klyne cc: Keith Moore , James M Galvin , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... In-reply-to: (Your message of "Mon, 24 Jun 2002 18:26:47 BST.") <5.1.0.14.2.20020624182405.03d42ec0@joy.songbird.com> Date: Mon, 24 Jun 2002 13:22:42 -0400 Sender: moore@cs.utk.edu List-Owner: List-Post: List-Unsubscribe: > At 12:08 PM 6/24/02 -0400, Keith Moore wrote: > >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. > > 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 owner-rescap@cs.utk.edu Mon Jun 24 13:25:36 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16446 for ; Mon, 24 Jun 2002 12:39:18 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id MAA20318; Mon, 24 Jun 2002 12:38:38 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 12:38:29 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA20270; Mon, 24 Jun 2002 12:38:24 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 12:38:24 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id g5OGcNe25485 for dist-rescap@cs.utk.edu; Mon, 24 Jun 2002 12:38:23 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 10:02:25 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA23836; Mon, 24 Jun 2002 10:02:25 -0400 (EDT) Received: from jay.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA23719; Mon, 24 Jun 2002 10:01:44 -0400 (EDT) Received: from jay.songbird.com (208.184.79.253 -> 208.184.79.253.songbird.com) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 10:01:44 -0400 Received: from GK-VAIO.ninebynine.org ([212.159.36.163]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g5OE09429029; Mon, 24 Jun 2002 07:00:10 -0700 Message-Id: <5.1.0.14.2.20020624144521.038659d0@joy.songbird.com> X-Sender: gk-bulk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Jun 2002 14:48:17 +0100 To: Michael Mealling From: Graham Klyne Subject: Re: current status of the RESCAP working group.... Cc: rescap@cs.utk.edu In-Reply-To: <20020624083253.P18666@bailey.dscga.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Owner: List-Post: List-Unsubscribe: At 08:32 AM 6/24/02 -0400, you wrote: > 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. 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. #g ------------------- Graham Klyne From owner-rescap@cs.utk.edu Mon Jun 24 13:40:21 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20216 for ; Mon, 24 Jun 2002 13:40:19 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id NAA02789; Mon, 24 Jun 2002 13:39:38 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 13:39:29 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA02717; Mon, 24 Jun 2002 13:39:23 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 13:39:23 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id g5OHdHM02837 for dist-rescap@cs.utk.edu; Mon, 24 Jun 2002 13:39:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 13:16:33 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA27788; Mon, 24 Jun 2002 13:16:31 -0400 (EDT) Received: from jay.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA27486; Mon, 24 Jun 2002 13:15:41 -0400 (EDT) Received: from jay.songbird.com (208.184.79.253 -> 208.184.79.253.songbird.com) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 13:15:42 -0400 Received: from GK-VAIO.NineByNine.org (dyn39-32.sftm-212-159.plus.net [212.159.32.39]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g5OHE4429282; Mon, 24 Jun 2002 10:14:05 -0700 Message-Id: <5.1.0.14.2.20020624181231.03d40110@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Jun 2002 18:23:36 +0100 To: Michael Mealling From: Graham Klyne Subject: Re: current status of the RESCAP working group.... Cc: rescap@cs.utk.edu In-Reply-To: <20020624104301.A22435@bailey.dscga.com> References: <5.1.0.14.2.20020624144521.038659d0@joy.songbird.com> <20020624083253.P18666@bailey.dscga.com> <5.1.0.14.2.20020624144521.038659d0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Owner: List-Post: List-Unsubscribe: I see your point. I wasn't fully aware of the problems, and assumed you'd some to some common view. At 10:43 AM 6/24/02 -0400, Michael Mealling wrote: >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) 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. >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? 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. >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). 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 From owner-rescap@cs.utk.edu Mon Jun 24 13:46:45 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20604 for ; Mon, 24 Jun 2002 13:46:44 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id NAA04587; Mon, 24 Jun 2002 13:46:03 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 13:45:57 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA04521; Mon, 24 Jun 2002 13:45:56 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 13:45:56 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id g5OHjul02993 for dist-rescap@cs.utk.edu; Mon, 24 Jun 2002 13:45:56 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 13:16:33 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA27789; Mon, 24 Jun 2002 13:16:32 -0400 (EDT) Received: from jay.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA27485; Mon, 24 Jun 2002 13:15:41 -0400 (EDT) Received: from jay.songbird.com (208.184.79.253 -> 208.184.79.253.songbird.com) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 13:15:42 -0400 Received: from GK-VAIO.ninebynine.org (dyn39-32.sftm-212-159.plus.net [212.159.32.39]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g5OHE2429278; Mon, 24 Jun 2002 10:14:02 -0700 Message-Id: <5.1.0.14.2.20020624182405.03d42ec0@joy.songbird.com> X-Sender: gk-bulk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Jun 2002 18:26:47 +0100 To: Keith Moore From: Graham Klyne Subject: Re: current status of the RESCAP working group.... Cc: James M Galvin , rescap@cs.utk.edu In-Reply-To: <200206241608.g5OG8s221377@astro.cs.utk.edu> References: <(Your message of "Mon, 24 Jun 2002 09:50:15 EDT.") Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Owner: List-Post: List-Unsubscribe: At 12:08 PM 6/24/02 -0400, Keith Moore wrote: >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. 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? #g ------------------- Graham Klyne From owner-rescap@cs.utk.edu Mon Jun 24 14:19:43 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22285 for ; Mon, 24 Jun 2002 14:19:42 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id OAA11707; Mon, 24 Jun 2002 14:19:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 14:18:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA11519; Mon, 24 Jun 2002 14:17:45 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA11361; Mon, 24 Jun 2002 14:16:50 -0400 (EDT) Received: from bailey.dscga.com (198.78.11.130 -> bailey.neonym.net) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 14:16:51 -0400 Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5OIFguK023430; Mon, 24 Jun 2002 14:15:42 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5OIFfas023429; Mon, 24 Jun 2002 14:15:41 -0400 (EDT) Date: Mon, 24 Jun 2002 14:15:41 -0400 From: Michael Mealling To: Graham Klyne Cc: Keith Moore , James M Galvin , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... Message-ID: <20020624141541.J22435@bailey.dscga.com> Reply-To: Michael Mealling References: <(Your <5.1.0.14.2.20020624182405.03d42ec0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020624182405.03d42ec0@joy.songbird.com> User-Agent: Mutt/1.3.22.1i List-Owner: List-Post: List-Unsubscribe: On Mon, Jun 24, 2002 at 06:26:47PM +0100, Graham Klyne wrote: > At 12:08 PM 6/24/02 -0400, Keith Moore wrote: > >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. > > 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? 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 -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Mon Jun 24 14:23:02 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22468 for ; Mon, 24 Jun 2002 14:23:00 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id OAA12634; Mon, 24 Jun 2002 14:22:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 14:22:20 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA12613; Mon, 24 Jun 2002 14:22:19 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA12581; Mon, 24 Jun 2002 14:22:14 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 14:22:14 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OIKw203187; Mon, 24 Jun 2002 14:20:58 -0400 (EDT) Message-Id: <200206241820.g5OIKw203187@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Graham Klyne cc: Michael Mealling , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... In-reply-to: (Your message of "Mon, 24 Jun 2002 18:23:36 BST.") <5.1.0.14.2.20020624181231.03d40110@joy.songbird.com> Date: Mon, 24 Jun 2002 14:20:58 -0400 Sender: moore@cs.utk.edu List-Owner: List-Post: List-Unsubscribe: > I see your point. I wasn't fully aware of the problems, and assumed you'd > 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. > At 10:43 AM 6/24/02 -0400, Michael Mealling wrote: > >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) > > 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. actually I think that's close to optimal - you have to work very hard to do something that's even marginally better. > >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). > > 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. 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 owner-rescap@cs.utk.edu Mon Jun 24 14:27:42 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22767 for ; Mon, 24 Jun 2002 14:27:42 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id OAA13761; Mon, 24 Jun 2002 14:26:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 14:26:49 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA13729; Mon, 24 Jun 2002 14:26:46 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA13618; Mon, 24 Jun 2002 14:26:06 -0400 (EDT) Received: from bailey.dscga.com (198.78.11.130 -> bailey.neonym.net) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 14:26:07 -0400 Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5OIOwuK023470; Mon, 24 Jun 2002 14:24:58 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5OIOvme023469; Mon, 24 Jun 2002 14:24:57 -0400 (EDT) Date: Mon, 24 Jun 2002 14:24:57 -0400 From: Michael Mealling To: Keith Moore Cc: Graham Klyne , Michael Mealling , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... Message-ID: <20020624142457.K22435@bailey.dscga.com> Reply-To: Michael Mealling References: <5.1.0.14.2.20020624181231.03d40110@joy.songbird.com> <200206241820.g5OIKw203187@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206241820.g5OIKw203187@astro.cs.utk.edu> User-Agent: Mutt/1.3.22.1i List-Owner: List-Post: List-Unsubscribe: On Mon, Jun 24, 2002 at 02:20:58PM -0400, Keith Moore wrote: > > I see your point. I wasn't fully aware of the problems, and assumed you'd > > 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. 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 -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Mon Jun 24 14:40:59 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23659 for ; Mon, 24 Jun 2002 14:40:58 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id OAA16174; Mon, 24 Jun 2002 14:40:19 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 14:40:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA16129; Mon, 24 Jun 2002 14:40:11 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA15816; Mon, 24 Jun 2002 14:39:30 -0400 (EDT) Received: from bailey.dscga.com (198.78.11.130 -> bailey.neonym.net) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 14:39:31 -0400 Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5OIcLuK023529; Mon, 24 Jun 2002 14:38:22 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5OIcLDU023528; Mon, 24 Jun 2002 14:38:21 -0400 (EDT) Date: Mon, 24 Jun 2002 14:38:21 -0400 From: Michael Mealling To: Keith Moore Cc: Graham Klyne , Michael Mealling , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... Message-ID: <20020624143820.L22435@bailey.dscga.com> Reply-To: Michael Mealling References: <5.1.0.14.2.20020624181231.03d40110@joy.songbird.com> <200206241820.g5OIKw203187@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206241820.g5OIKw203187@astro.cs.utk.edu> User-Agent: Mutt/1.3.22.1i List-Owner: List-Post: List-Unsubscribe: On Mon, Jun 24, 2002 at 02:20:58PM -0400, Keith Moore wrote: > > At 10:43 AM 6/24/02 -0400, Michael Mealling wrote: > > >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) > > > > 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. > > actually I think that's close to optimal - you have to work very hard > 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. > > >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). > > > > 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. > > 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. 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. > 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. 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 -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Mon Jun 24 16:32:52 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28804 for ; Mon, 24 Jun 2002 16:32:51 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id QAA07768; Mon, 24 Jun 2002 16:31:49 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Mon, 24 Jun 2002 16:31:37 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA07613; Mon, 24 Jun 2002 16:31:34 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA07455; Mon, 24 Jun 2002 16:30:58 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jun 2002 16:30:59 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5OKUM203332; Mon, 24 Jun 2002 16:30:22 -0400 (EDT) Message-Id: <200206242030.g5OKUM203332@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Mealling cc: Keith Moore , Graham Klyne , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... In-reply-to: (Your message of "Mon, 24 Jun 2002 14:38:21 EDT.") <20020624143820.L22435@bailey.dscga.com> Date: Mon, 24 Jun 2002 16:30:22 -0400 Sender: moore@cs.utk.edu List-Owner: List-Post: List-Unsubscribe: > > > 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. > > > > actually I think that's close to optimal - you have to work very hard > > 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. 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 > 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. 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.). > 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. 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. > > 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. > > Which was the 'an attribute can be a string or a blob encoded as a string' > 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 owner-rescap@cs.utk.edu Tue Jun 25 14:49:26 2002 Received: from cs.utk.edu ([160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22362 for ; Tue, 25 Jun 2002 14:49:25 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id OAA17986; Tue, 25 Jun 2002 14:48:34 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Tue, 25 Jun 2002 14:48:14 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA17951; Tue, 25 Jun 2002 14:48:14 -0400 (EDT) Received: from bailey.dscga.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA17826; Tue, 25 Jun 2002 14:47:26 -0400 (EDT) Received: from bailey.dscga.com (198.78.11.130 -> bailey.neonym.net) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jun 2002 14:47:28 -0400 Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5PIkBuK027195; Tue, 25 Jun 2002 14:46:11 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5PIkAGx027194; Tue, 25 Jun 2002 14:46:10 -0400 (EDT) Date: Tue, 25 Jun 2002 14:46:10 -0400 From: Michael Mealling To: Keith Moore Cc: Michael Mealling , Graham Klyne , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... Message-ID: <20020625144610.K24592@bailey.dscga.com> Reply-To: Michael Mealling References: <20020624143820.L22435@bailey.dscga.com> <200206242030.g5OKUM203332@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206242030.g5OKUM203332@astro.cs.utk.edu> User-Agent: Mutt/1.3.22.1i List-Owner: List-Post: List-Unsubscribe: On Mon, Jun 24, 2002 at 04:30:22PM -0400, Keith Moore wrote: > > > > 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. > > > > > > actually I think that's close to optimal - you have to work very hard > > > 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. > > 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 > > 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. > > hmm. either way you have to retransmit the request after some timeout > interval. Yes. > 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.). 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. > > 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. > > Last I knew TFTP was not highly regarded in Internet Area circles. As a file transfer system, yes. We're not transfering kernels here... > 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. You don't necessarily need to do stop and wait but you can. I'm more interested in the packet numbering and retransmission methods. > 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. 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. > > > 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. > > > > Which was the 'an attribute can be a string or a blob encoded as a string' > > 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. 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 -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net From owner-rescap@cs.utk.edu Tue Jun 25 15:36:53 2002 Received: from cs.utk.edu (cs.utk.edu [160.36.56.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24621 for ; Tue, 25 Jun 2002 15:36:52 -0400 (EDT) Received: by cs.utk.edu (cf v2.9s-UTK) id PAA29238; Tue, 25 Jun 2002 15:37:34 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.16); Tue, 25 Jun 2002 15:37:33 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA29210; Tue, 25 Jun 2002 15:37:32 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA29190; Tue, 25 Jun 2002 15:37:30 -0400 (EDT) Received: from astro.cs.utk.edu (160.36.58.43 -> astro.cs.utk.edu) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jun 2002 15:37:30 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5PJbS203912; Tue, 25 Jun 2002 15:37:28 -0400 (EDT) Message-Id: <200206251937.g5PJbS203912@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Mealling cc: Keith Moore , Graham Klyne , rescap@cs.utk.edu Subject: Re: current status of the RESCAP working group.... In-reply-to: (Your message of "Tue, 25 Jun 2002 14:46:10 EDT.") <20020625144610.K24592@bailey.dscga.com> Date: Tue, 25 Jun 2002 15:37:28 -0400 Sender: moore@cs.utk.edu List-Owner: List-Post: List-Unsubscribe: > > 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.). > > 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. note: 512 bytes is okay for IPv4, too small for IPv6. > > Last I knew TFTP was not highly regarded in Internet Area circles. > > 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. > You don't necessarily need to do stop and wait but you can. I'm more > 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.) > > 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. > > 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. 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