Subject: Re: Where we stand and where we are going
From: Erik Nordmark <[email-masked]>
To: Michael Mealling <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]
Date: Thu, 04 Jul 2002 14:56:19 +0200 (CEST)
List-Id: <ietf-irnss.lists.elistx.com>

> I have had two instances where the usage profile of a protocol suggests
> that 99% of the responses will be less than 2K and the interaction is
> stateless and connection-less. Inheriting the full session semantics of TCP
> isn't required. But neither is the sad state of UDP packet size limitations.

Do we know enough about security (starting at what threats need to be
considered  etc) to have any idea what security would do to the packet sizes?

> My proposed solution is to limit UDP packet sizes to 512 bytes and put
> packet sequence numbers on them. You still have a connectionless interaction
> but it a) puts the packet size into a realm with a higher probability of
> success and b) allows for a handful of those packets to get through. I'm
> not sure if you need more than that. You can still do the "well if 
> that didn't work I can always do TCP"...

512 for IPv4 might make sense, but IPv6 can handle more with its 1280 min MTU.
In practise both can handle 1k well in today's network.

If there was a way for the client to predict the size (assuming the problem is
with large replies and not large requests) then life would be better
than an error causing a TCP retry.

  Erik

Date: Wed, 03 Jul 2002 05:24:17 +0000 (UCT)
From: [email-masked]
Subject: Re: Where we stand and where we are going
To: [email-masked]
Cc: [email-masked] (Rob Austein), [email-masked]

> I have had two instances where the usage profile of a protocol suggests
> that 99% of the responses will be less than 2K and the interaction is
> stateless and connection-less. Inheriting the full session semantics of TCP
> isn't required. But neither is the sad state of UDP packet size limitations.
> 
> My proposed solution is to limit UDP packet sizes to 512 bytes and put
> packet sequence numbers on them. You still have a connectionless interaction
> but it a) puts the packet size into a realm with a higher probability of
> success and b) allows for a handful of those packets to get through. I'm
> not sure if you need more than that. You can still do the "well if 
> that didn't work I can always do TCP"...
> 
> I really would like to hear some definitive answers on this topic because
> it keeps coming up and a solution would make a heck of a lot of sense.
> 
> -MM

	Jumping in before reading the rest of the thread...
	I've seen that w/ DNSSEC, the DNS query/response
	profile shifts from short query/short response
	to short query/massive response, not unlike HTTP
	traffic profiles.  YMMV
	Two, Rob is pretty much dead on w/ where to do 
	UDP frag checking.  Or... why not 1280 instead of
	512?  :)

--bill	

Date: Mon, 01 Jul 2002 14:05:11 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: RE: Transport requirements for DNS-like protocols
To: John C Klensin <[email-masked]>, Nicolas Popp <[email-masked]>, 'Michael Mealling' <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

--On 2002-07-01 07.47 -0400 John C Klensin <[email-masked]> wrote:

> And, in this particular
> case, I think we are likely to need a more complex search than
> something that yields easily to client-side canonicalization and
> lookup, but I see almost no advantage to getting involved with
> per-client (or per-user) server state.

I agree completely!

   paf

Date: Mon, 01 Jul 2002 07:47:49 -0400
From: John C Klensin <[email-masked]>
Subject: RE: Transport requirements for DNS-like protocols
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, Nicolas Popp <[email-masked]>, 'Michael Mealling' <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

--On Monday, 01 July, 2002 08:52 +0200 Patrik F=E4ltstr=F6m
<[email-masked]> wrote:

> --On 2002-06-30 21.14 -0400 John C Klensin <[email-masked]>
> wrote:
>=20
>> Sonex/ soundex matches are fuzzy matching, but they are not
>> fuzzy search; I think that fuzzy search is going to be needed
>> here.
>=20
> True.
>=20
> I think the reason why I am arguing so strongly for client-side
> calculations is just because too many people doing services
> forget we have a CPU in the client aswell as the server side.
> Just look at the "paged result sets" in IMAP and LDAP which I
> still for my life don't understand how people can deploy. It
> will cost soo much. "We need it because we have so limited
> amount of memory and CPU in the client." is what I have heard.

I think that argument is largely bogus for desktop-class
machines(see below).  It may become relevant for kiosk-like
setups and, perhaps, for devices similar to mobile phones and
PDAs.  But, even then, I'd like to see more split-client
approaches, in which a service machine does the retrievals and
sorting and selection and keeps state (and pages out
information) to the end-system clients.  =20

> So, instead of having the client do a search+fetch from the
> server, the client also want to pass enough information to get
> the items sorted correctly (whatever that can be) + the server
> is to keep a state for the client, like a cached view.
>=20
> This imply not only that we need semantics and syntax which
> enables the client to pass sorting algorithm input to the
> server, but also that the server need to keep state. One for
> each client. What is the timeout? What happens if new records
> are added or removed to the view the client looks at?
>=20
> _Extremely_ complicated.

Yes.  But needed in some cases, although fewer, I think, than is
usually assumed by the people who keep proposing these things.
It would be, IMO, very useful to develop some coherent model or
set of advisory rules for telling the difference.

> So, of course one need cooperation between client and server,
> where the various calculations are made where it "makes
> sense". My point is that "makes sense" is not always the
> server. Much more seldom than what people in general(!) think.

I think we are in complete agreement.   And, in this particular
case, I think we are likely to need a more complex search than
something that yields easily to client-side canonicalization and
lookup, but I see almost no advantage to getting involved with
per-client (or per-user) server state.

     john

Date: Mon, 01 Jul 2002 08:52:38 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: RE: Transport requirements for DNS-like protocols
To: John C Klensin <[email-masked]>, Nicolas Popp <[email-masked]>, 'Michael Mealling' <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

--On 2002-06-30 21.14 -0400 John C Klensin <[email-masked]> wrote:

> Sonex/ soundex matches are fuzzy matching, but they are not
> fuzzy search; I think that fuzzy search is going to be needed
> here.

True.

I think the reason why I am arguing so strongly for client-side
calculations is just because too many people doing services forget we have
a CPU in the client aswell as the server side. Just look at the "paged
result sets" in IMAP and LDAP which I still for my life don't understand
how people can deploy. It will cost soo much. "We need it because we have
so limited amount of memory and CPU in the client." is what I have heard.
So, instead of having the client do a search+fetch from the server, the
client also want to pass enough information to get the items sorted
correctly (whatever that can be) + the server is to keep a state for the
client, like a cached view.

This imply not only that we need semantics and syntax which enables the
client to pass sorting algorithm input to the server, but also that the
server need to keep state. One for each client. What is the timeout? What
happens if new records are added or removed to the view the client looks at?

_Extremely_ complicated.

So, of course one need cooperation between client and server, where the
various calculations are made where it "makes sense". My point is that
"makes sense" is not always the server. Much more seldom than what people
in general(!) think.

    paf