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

[David Blacka <[e-mail]>]

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.)


> -andy
>
> On Oct 26, 2005, at 12:43 PM, Leslie Daigle wrote:
>
>
>>
>> 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:
>>
>>
>>> 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    <[e-mail]>
>>> Sr. Engineer    VeriSign Applied Research
>>> _______________________________________________
>>> Crisp mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/crisp
>>>
>>>
>>
>> _______________________________________________
>> Crisp mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/crisp
>>
>>
>
>

--
David Blacka    <[e-mail]>
Sr. Engineer    VeriSign Applied Research




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