Subject: [Crisp] Last call comments for iris-lwz

From: David Blacka <[email-masked]>
Date: Wed, 26 Oct 2005 12:08:42 -0400

Overall, I like the idea and I like the document.  However, from my  
perspective, the document is missing discussion about how clients and  
servers are supposed to interact using this protocol.

When doing some implementation work with this, I kept wondering to  
myself if clients were supposed to negotiate with servers to  
determine mutual support of compression and maximum UDP size.  I was  
also wondering how a client that supported lwz and xpc (and/or BEEP)  
would make a decision to try lwz.  I was wondering what the "message  
pattern" was, basically.  And I was specifically wondering how  
clients are expected to behave.

In an offline conversation with Andy, I got some fairly clear answers  
to these questions, which I think should be in the document.  The  
intent (as expressed by Andy, not by the draft) is for there to be no  
explicit negotiation between client and server.  Instead, the client  
attempts to use lwz, and either gets back and answer or an error.  If  
it gets an error, the client moves on to the next transport (or just  
fails, if none).

So, then the question remains about how clients decided to use lwz,  
and, if the clients does use lwz, how it decided to use compression  
or not.  Again, in this offline conversation, the solution was to  
recommend a size to make these decisions around.  That is, specify a  
minimum size (in octets) that a server SHOULD accept.  This size  
would also be the maximum size that a client SHOULD attempt to send  
via LWZ.  So the client's decision tree might be (given the presence  
of an iris-lwz service):

  1. Is my request less than size x, uncompressed?
     Yes -- send it.
     No  -- compress it.
  2. Is my request less than size x, compressed?
     Yes -- send it.
     No -- move on to next transport, or send it anyway.

I don't envision this sort of discussion actually precluding other  
message patterns or decision trees, actually.  But I think that it is  
very helpful to implementers (or potential implementers) to get an  
idea of what the baseline or typical lwz interaction would be.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

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

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 26 Oct 2005 12:43:56 -0400

I think one of the additional answers to "when to use lwz"
is application specific.  That is, there are some applications
of IRIS for which lwz is the right choice, or the right first
choice, or whatever.

That could be mentioned in the document.

Leslie.

David Blacka wrote:
> myself if clients were supposed to negotiate with servers to  determine 
> mutual support of compression and maximum UDP size.  I was  also 
> wondering how a client that supported lwz and xpc (and/or BEEP)  would 
> make a decision to try lwz.  I was wondering what the "message  pattern" 
> was, basically.  And I was specifically wondering how  clients are 
> expected to behave.
> 
> and, if the clients does use lwz, how it decided to use compression  or 
> not.  Again, in this offline conversation, the solution was to  
> minimum size (in octets) that a server SHOULD accept.  This size  would 
> also be the maximum size that a client SHOULD attempt to send  via LWZ.  
> So the client's decision tree might be (given the presence  of an 
> iris-lwz service):
> 
> very helpful to implementers (or potential implementers) to get an  idea 
> of what the baseline or typical lwz interaction would be.
> 
> --

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Oct 2005 13:31:51 -0400

I agree on all counts.

As for draft mechanics, I think this general text should be placed in  
an appendix except for the MUST/SHOULD language on the maximum size.

Does anybody have a problem with 4k being that maximum size?

-andy

On Oct 26, 2005, at 12:43 PM, Leslie Daigle wrote:

>> Overall, I like the idea and I like the document.  However, from  
>> my  perspective, the document is missing discussion about how  
>> clients and  servers are supposed to interact using this protocol.
>> When doing some implementation work with this, I kept wondering  
>> to  myself if clients were supposed to negotiate with servers to   
>> determine mutual support of compression and maximum UDP size.  I  
>> was  also wondering how a client that supported lwz and xpc (and/ 
>> or BEEP)  would make a decision to try lwz.  I was wondering what  
>> the "message  pattern" was, basically.  And I was specifically  
>> wondering how  clients are expected to behave.
>> In an offline conversation with Andy, I got some fairly clear  
>> answers  to these questions, which I think should be in the  
>> document.  The  intent (as expressed by Andy, not by the draft) is  
>> for there to be no  explicit negotiation between client and  
>> server.  Instead, the client  attempts to use lwz, and either gets  
>> back and answer or an error.  If  it gets an error, the client  
>> moves on to the next transport (or just  fails, if none).
>> So, then the question remains about how clients decided to use  
>> lwz,  and, if the clients does use lwz, how it decided to use  
>> compression  or not.  Again, in this offline conversation, the  
>> solution was to  recommend a size to make these decisions around.   
>> That is, specify a  minimum size (in octets) that a server SHOULD  
>> accept.  This size  would also be the maximum size that a client  
>> SHOULD attempt to send  via LWZ.  So the client's decision tree  
>> might be (given the presence  of an iris-lwz service):
>> I don't envision this sort of discussion actually precluding  
>> other  message patterns or decision trees, actually.  But I think  
>> that it is  very helpful to implementers (or potential  
>> implementers) to get an  idea of what the baseline or typical lwz  
>> interaction would be.
>> --

---

From: David Blacka <[email-masked]>
Date: Wed, 26 Oct 2005 16:24:26 -0400

On Oct 26, 2005, at 1:31 PM, Andrew Newton wrote:

> I agree on all counts.
>
> As for draft mechanics, I think this general text should be placed  
> in an appendix except for the MUST/SHOULD language on the maximum  
> size.

Egads! An appendix! Does anybody actually *read* appendices? ;)

> Does anybody have a problem with 4k being that maximum size?

Note that this is a maximum from the client perspective (i.e., the  
client will send requests no larger than this), and a minimum from  
the server perspective (i.e., the server should accept requests of at  
least this size).

The idea here is to provide a metric that is likely to work across  
most providers and networks so that clients can be efficient.  That  
is, not try lwz when lwz is unlikely to work. (Clients, also, when  
given a choice between transports, might also like to forgo lwz when  
it would expect the response to be large, as well. But I don't think  
that this needs to be said in the document.)

>>> document.  The  intent (as expressed by Andy, not by the draft)  
>>> is for there to be no  explicit negotiation between client and  
>>> server.  Instead, the client  attempts to use lwz, and either  
>>> gets back and answer or an error.  If  it gets an error, the  
>>> client moves on to the next transport (or just  fails, if none).
>>> solution was to  recommend a size to make these decisions  
>>> around.  That is, specify a  minimum size (in octets) that a  
>>> server SHOULD accept.  This size  would also be the maximum size  
>>> that a client SHOULD attempt to send  via LWZ.  So the client's  
>>> decision tree might be (given the presence  of an iris-lwz service):