From david at mantara.com Mon Dec 18 06:29:25 2006 From: david at mantara.com (David Arnold) Date: Mon Dec 18 06:50:15 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Fri, 15 Dec 2006 20:41:33 +1030." <4A8EB585-EFEF-4009-B9F5-173AA3A3EB17@mattp.name> Message-ID: -->"Matt" == Matthew Phillips writes: Matt> Hi guys, quick suggestion: how does Matt> "Transport.TCP.Coalesce-Delay" sound as the name of the Matt> connection option to set the TCP coalesce delay option? a few comments: there's no need for the "Transport" on the front: the names of protocol modules are ok as top-level namespace elements. TCP is fine, good, and matches existing practice. "Coalesce-Delay" is the hard part :-) here's a summary of the thinking thus far: TCP.No-Delay Pro: basically matches the name of the socket option, so it will have some familiarity for those who have TCP experience. Con: the value is a negative (ie. No-Delay, not Do-Delay), which makes it constantly painful to figure out whether you want its value to be 1 or 0 TCP.Enable-Nagle Pro: includes name of algorithm, which makes finding explanations of what it does Google-friendly. Con: any Googled reference to "nagle" will only talk about the theory, and TCP_NODELAY, which isn't useful in deciding whether you want it 1 or 0. Con: it's a bit of an obscure, hairy-unix-hacker name, that many people who know what TCP_NODELAY does won't even recognise. TCP.Coalesce-Delay Pro: matches current deployed systems, almost Con: difficult to know what the hell it might mean Con: does not really make sense. The option doesn't coalesce delays, it introduces a small delay while coalescing packets. Con: not clear if it should be 1 or 0, again. on balance, i'm still leaning towards a new name, trying to reflect what actually happens. something shorter than TCP.Wait-A-Short-Time-In-Attempt-To-Merge-Small-Outgoing-Packets might be good. maybe ... TCP.Wait-To-Coalesce-Packets TCP.Try-To-Coalesce-Packets TCP.Try-To-Merge-Packets or TCP.Minimize-Latency-At-Cost-Of-Bandwith TCP.Minimize-Latency or TCP.Send-Packets-Immediately TCP.Send-Immediately TCP.Send-ASAP i'm almost liking the last group best ... thoughts? d From matt at mattp.name Tue Dec 19 03:56:05 2006 From: matt at mattp.name (Matthew Phillips) Date: Tue Dec 19 04:51:39 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: Message-ID: <737AF9DD-8DBA-4FAF-AE64-622DD01FBBE0@mattp.name> On 18/12/2006, at 10:59 PM, David Arnold wrote: > -->"Matt" == Matthew Phillips writes: > > Matt> Hi guys, quick suggestion: how does > Matt> "Transport.TCP.Coalesce-Delay" sound as the name of the > Matt> connection option to set the TCP coalesce delay option? > > a few comments: > > there's no need for the "Transport" on the front: the names of > protocol modules are ok as top-level namespace elements. > > TCP is fine, good, and matches existing practice. Seems reasonable. > "Coalesce-Delay" is the hard part :-) > > here's a summary of the thinking thus far: > > TCP.No-Delay > Pro: basically matches the name of the socket option, so it will > have > some familiarity for those who have TCP experience. > Con: the value is a negative (ie. No-Delay, not Do-Delay), which > makes > it constantly painful to figure out whether you want its > value to > be 1 or 0 Agreed, negative options are painful. > TCP.Enable-Nagle > Pro: includes name of algorithm, which makes finding explanations of > what it does Google-friendly. > Con: any Googled reference to "nagle" will only talk about the > theory, > and TCP_NODELAY, which isn't useful in deciding whether you > want > it 1 or 0. > Con: it's a bit of an obscure, hairy-unix-hacker name, that many > people who know what TCP_NODELAY does won't even recognise. Agreed, esp re hairy-unix-hacker issue ;) > TCP.Coalesce-Delay > Pro: matches current deployed systems, almost > Con: difficult to know what the hell it might mean > Con: does not really make sense. The option doesn't coalesce > delays, > it introduces a small delay while coalescing packets. > Con: not clear if it should be 1 or 0, again. Yes, I guess it only makes sense to me because I've already internalised it. > TCP.Send-Packets-Immediately > TCP.Send-Immediately > TCP.Send-ASAP I like TCP.Send-Packets-Immediately the best of those. Or perhaps, using "positive" forms (i.e. the reverse of TCP.Send-Packets- Immediately, but not put as a negative): TCP.Queue-Packets TCP.Coalesce-Packets I'm happy with any of the TCP.Send* ones or the ones above really. btw I'm planning to allow defaults for all of the connection options to be set in the Avis config file. e.g. "Receive-Queue.Drop- Policy=fail". I'm also going to make the matching case-independent. Sound like a sane thing to do? Matt. From davida at pobox.com Thu Dec 21 15:08:16 2006 From: davida at pobox.com (David Arnold) Date: Thu Dec 21 15:08:26 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: Your message of "Tue, 19 Dec 2006 20:26:05 +1030." <737AF9DD-8DBA-4FAF-AE64-622DD01FBBE0@mattp.name> Message-ID: <20816.1166735296@d.0x1.org> -->"Matt" == Matthew Phillips writes: >> TCP.Send-Packets-Immediately TCP.Send-Immediately TCP.Send-ASAP Matt> I like TCP.Send-Packets-Immediately the best of those. Or Matt> perhaps, using "positive" forms (i.e. the reverse of Matt> TCP.Send-Packets- Immediately, but not put as a negative): Matt> TCP.Queue-Packets TCP.Coalesce-Packets Matt> I'm happy with any of the TCP.Send* ones or the ones above Matt> really. I *think* I prefer that we use a name that allows a positive change away from the default. The default behaviour is TCP's default, that is, to try to coalesce data by waiting a fraction of a second. To escape that default, I think I'd prefer to turn something _on_, rather than _off_. So, while I like both of Matt> TCP.Queue-Packets TCP.Coalesce-Packets too, I think I prefer >> TCP.Send-Packets-Immediately because it's something you can turn _on_. Anyone else want to step in before this is finalised? Matt> I'm planning to allow defaults for all of the connection options Matt> to be set in the Avis config file. e.g. "Receive-Queue.Drop- Matt> Policy=fail". I'm also going to make the matching Matt> case-independent. Sound like a sane thing to do? I think that's sane. It's also, handily, Java's default properties file semantics, isn't it? :-) d From matt at mattp.name Thu Dec 21 18:00:59 2006 From: matt at mattp.name (Matthew Phillips) Date: Thu Dec 21 18:01:01 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <20816.1166735296@d.0x1.org> References: <20816.1166735296@d.0x1.org> Message-ID: <5B685403-7E37-4A00-A4BC-1434E431D3E3@mattp.name> On 22/12/2006, at 7:38 AM, David Arnold wrote: > -->"Matt" == Matthew Phillips writes: > So, while I like both of > > Matt> TCP.Queue-Packets TCP.Coalesce-Packets > > too, I think I prefer > >>> TCP.Send-Packets-Immediately > > because it's something you can turn _on_. It is marginally nicer I'd agree. But since all the options will be specified in the template config file (or GUI), I'd say that understandability would be the primary aim. But I can live with TCP.Send-Packets-Immediately quite happily. > Anyone else want to step in before this is finalised? > > Matt> I'm planning to allow defaults for all of the connection > options > Matt> to be set in the Avis config file. e.g. "Receive-Queue.Drop- > Matt> Policy=fail". I'm also going to make the matching > Matt> case-independent. Sound like a sane thing to do? > > I think that's sane. > > It's also, handily, Java's default properties file semantics, isn't > it? :-) You seem to have seen right through to my pragmatic core ;) Unfortunately however, Java's property system is case-sensitive. I'm using the built-in properties file parser, but I needed to add case- independent matching myself. Cheers, Matt. From david at mantara.com Wed Dec 27 16:58:55 2006 From: david at mantara.com (David Arnold) Date: Wed Dec 27 18:49:53 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: References: <20816.1166735296@d.0x1.org> Message-ID: <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> On 22/12/2006, at 10:48 AM, Ian Lister wrote: >> too, I think I prefer >> >> >> TCP.Send-Packets-Immediately >> >> because it's something you can turn _on_. > > Likewise, but I think it's a little unnecessarily verbose, and it > could be "TCP.Send-Immediately" or "TCP.Immediate-Send" without any > loss of meaning. ok, so: any objections to the option named TCP.Send-Immediately being set true to mean that Nagle's algorithm should be disabled for a connection (overriding the default which SHOULD be false)? d From matt at mattp.name Wed Dec 27 21:50:34 2006 From: matt at mattp.name (Matthew Phillips) Date: Wed Dec 27 21:50:32 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> References: <20816.1166735296@d.0x1.org> <283BBE0E-1115-4F58-B889-01BAAEA13762@mantara.com> Message-ID: On 28/12/2006, at 9:28 AM, David Arnold wrote: > On 22/12/2006, at 10:48 AM, Ian Lister wrote: > >>> too, I think I prefer >>> >>> >> TCP.Send-Packets-Immediately >>> >>> because it's something you can turn _on_. >> >> Likewise, but I think it's a little unnecessarily verbose, and it >> could be "TCP.Send-Immediately" or "TCP.Immediate-Send" without >> any loss of meaning. > > ok, so: any objections to the option named > > TCP.Send-Immediately > > being set true to mean that Nagle's algorithm should be disabled > for a connection (overriding the default which SHOULD be false)? Fine by me. Are there any other planned changes to the spec? Actually, now I think about it, one minor thing that I would like to add is a "not implemented" NACK code for use by implementations that do a subset of the spec. Or perhaps a way to indicate that via connection options, similar to "Supported-Key-Schemes". e.g. "Supported-Protocol-Subsets: A, B". Matt. From ilister at mantara.com Thu Dec 21 17:48:53 2006 From: ilister at mantara.com (Ian Lister) Date: Sun Dec 31 19:10:25 2006 Subject: [elvin-discuss] Re: Elvin spec In-Reply-To: <20816.1166735296@d.0x1.org> References: <20816.1166735296@d.0x1.org> Message-ID: On Fri, 22 Dec 2006, David Arnold wrote: > I *think* I prefer that we use a name that allows a positive change away > from the default. My initial reaction is that that's less important than just having the option expressed in a positive sense (i.e. if it's on by default, that's fine), but I think that probably comes from a GUI perspective where you can have all the possible options presented and some enabled by default, which isn't quite the same as a properties table in which options need to be set explicitly. > So, while I like both of > > Matt> TCP.Queue-Packets TCP.Coalesce-Packets > > too, I think I prefer > > >> TCP.Send-Packets-Immediately > > because it's something you can turn _on_. Likewise, but I think it's a little unnecessarily verbose, and it could be "TCP.Send-Immediately" or "TCP.Immediate-Send" without any loss of meaning. > Matt> I'm planning to allow defaults for all of the connection options > Matt> to be set in the Avis config file. e.g. "Receive-Queue.Drop- > Matt> Policy=fail". I'm also going to make the matching > Matt> case-independent. Sound like a sane thing to do? > > I think that's sane. > > It's also, handily, Java's default properties file semantics, isn't it? :-) How sensible of Java... ;-) Ian