Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA18619 for nmrg-outgoing; Thu, 29 Jul 1999 13:19:48 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA18614; Thu, 29 Jul 1999 13:19:44 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA24061; Thu, 29 Jul 1999 13:19:44 +0200 Date: Thu, 29 Jul 1999 13:19:44 +0200 Message-Id: <199907291119.NAA24061@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Erik.Huizer@sec.nl CC: Network Management Research Group Subject: [nmrg] welcome on the NMRG mailing list Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I have added you to the NMRG mailing list since you are soon our official IRTF chair. Welcome aboard. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA26937 for nmrg-outgoing; Mon, 26 Jul 1999 16:25:58 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA26933; Mon, 26 Jul 1999 16:25:55 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA27382; Mon, 26 Jul 1999 16:25:54 +0200 Date: Mon, 26 Jul 1999 16:25:54 +0200 Message-Id: <199907261425.QAA27382@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: pras@ctit.utwente.nl CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <379C67B3.28029968@ctit.utwente.nl> (message from Aiko Pras on Mon, 26 Jul 1999 15:50:43 +0200) Subject: Re: [nmrg] compression in SNMPv1 References: <199907200107.SAA03897@dthaler.microsoft.com> <199907200757.JAA14021@henkell.ibr.cs.tu-bs.de> <37958537.7A5BEC43@ctit.utwente.nl> <199907210855.KAA22850@henkell.ibr.cs.tu-bs.de> <379C67B3.28029968@ctit.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Aiko Pras writes: Aiko> This is exactly what I wanted to say. We can save on the number Aiko> of round-trip delays (our goal) by packing the data into fewer Aiko> responses (the mechanism to achieve the goal). Aiko> The point I wanted to make is that a see compression primarily Aiko> useful for reducing the number of round-trip Aiko> delays. Particularly with Get-Next and Get-Bulk we can gain a Aiko> lot; with Get-Tree we will not gain as much since we have at Aiko> SNMP level only a single request which results into multiple Aiko> responses. Therefore Get-Tree requires a smaller number of Aiko> round-trips. YES, I do agree that compression is also useful to Aiko> save on bandwidth. Unfortunately, this doesn't come for free: Aiko> we have to introduce extra complexity at the two end systems Aiko> (the manager and agent). However, since the growth in bandwidth Aiko> is MUCH (!!!) higher than the growth in CPU power and memory Aiko> speed, we should be reluctant to further complicate the end Aiko> systems. We shouldn't make the classical mistake to justify Aiko> design decisions for the future on the bandwidth / CPU ratio of Aiko> today! In my opinion the savings on bandwidth do not Aiko> sufficiently justify the additional complexity of compression; Aiko> the gain on delay however does justify compression. I think it really depends on your environment. Compression as we discussed it so far is indeed an optional feature and people who are living in an environment where it makes sense to use compression can enable this feature. The complexity of compression is really small implementationwise. However, the runtime impact can be significant (both, in terms of CPU usage as well as bandwidth savings ;-). Note that it does not cost anything if you choose to ignore compression. Aiko> I agree that the receiver can detect from the incoming data that Aiko> it must be compressed. However, I assume that the same is true Aiko> for encryption (the receiver can detect from the incoming data Aiko> that the data is encrypted). Why is it that there is still a Aiko> flag for privacy? SNMPv3 does not ship encrypted data in its own PDU type. Hence they need a bit which tells the receiver that the payload is encrypted. Juergen Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA25280 for nmrg-outgoing; Mon, 26 Jul 1999 15:51:02 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA25270; Mon, 26 Jul 1999 15:50:57 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.16.21]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with ESMTP id PAA02713; Mon, 26 Jul 1999 15:50:55 +0200 (MET DST) Message-ID: <379C67B3.28029968@ctit.utwente.nl> Date: Mon, 26 Jul 1999 15:50:43 +0200 From: Aiko Pras X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder , Jean-Philippe Martin-Flatin CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] compression in SNMPv1 References: <199907200107.SAA03897@dthaler.microsoft.com> <199907200757.JAA14021@henkell.ibr.cs.tu-bs.de> <37958537.7A5BEC43@ctit.utwente.nl> <199907210855.KAA22850@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi >From the reactions of Juergen and Jean-Philippe I must conclude that I failed to formulate my ideas well. > Aiko> 1) Our main goal is probably not saving on the number of bits > Aiko> that need to be transported, but saving on the number of > Aiko> round-trips (= time) that are currently needed (since we only > Aiko> have GetNext and GetBulk) to fetch large amounts of data. >Juergen> You are missing the fact that compression allows to put much >Juergen> more data into a response. This can drastically reduce the >Juergen> number of round-trips you need with GetBulk (and GetTree). This is exactly what I wanted to say. We can save on the number of round-trip delays (our goal) by packing the data into fewer responses (the mechanism to achieve the goal). The point I wanted to make is that a see compression primarily useful for reducing the number of round-trip delays. Particularly with Get-Next and Get-Bulk we can gain a lot; with Get-Tree we will not gain as much since we have at SNMP level only a single request which results into multiple responses. Therefore Get-Tree requires a smaller number of round-trips. YES, I do agree that compression is also useful to save on bandwidth. Unfortunately, this doesn't come for free: we have to introduce extra complexity at the two end systems (the manager and agent). However, since the growth in bandwidth is MUCH (!!!) higher than the growth in CPU power and memory speed, we should be reluctant to further complicate the end systems. We shouldn't make the classical mistake to justify design decisions for the future on the bandwidth / CPU ratio of today! In my opinion the savings on bandwidth do not sufficiently justify the additional complexity of compression; the gain on delay however does justify compression. > Aiko> 5) With respect to SNMPv3, the most promising approach I see now > Aiko> is using two of the message flags. >Juergen> Make that 1 message flag and the CompressedPDU and I agree. I agree that the receiver can detect from the incoming data that it must be compressed. However, I assume that the same is true for encryption (the receiver can detect from the incoming data that the data is encrypted). Why is it that there is still a flag for privacy? > Aiko> 6) In that case I propose we choose ONE compression algorithm > Aiko> for ever. >JP> I'm strongly opposed to that. Even the Java folks, who like to >JP> casteverything in Java iron, supported 2 compression schemes >JP> from day 1: gzip (to please the Unix world) and zip (to please >JP> the Windows world). Tomorrow, a Unisys-like patent issue might >JP> cause contempt for the compression algorithm you selected >JP> "forever". We don't want to be exposed to such design problems. OK, You're right. I guess I over-simplified things Bye Aiko Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA22959 for nmrg-outgoing; Mon, 26 Jul 1999 14:51:41 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA22955 for ; Mon, 26 Jul 1999 14:51:39 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.16.21]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with ESMTP id OAA01708; Mon, 26 Jul 1999 14:51:35 +0200 (MET DST) Message-ID: <379C59D6.37ACE9D2@ctit.utwente.nl> Date: Mon, 26 Jul 1999 14:51:34 +0200 From: Aiko Pras X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "nmrg@ibr.cs.tu-bs.de" CC: TSS management group Subject: [nmrg] Another SNMP over TCP implementation available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi all Based on the UCD SNMP package version 3.6.2, also the UT has made an experimental implementation of SNMP over TCP. Everyone can test the agent, which runs on port 8081 on the heisenberg.cs.utwente.nl. The community string is public. If the agent does not respond, please send an email and we will restart the agent. Not only the agent, but also the manager role has been implemented and tested (on solaris, linux, and Windows-NT (apart from the agent)). If you want to get the code, please let us know. Bye Aiko Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA20816 for nmrg-outgoing; Fri, 23 Jul 1999 09:12:20 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA20812; Fri, 23 Jul 1999 09:12:17 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA15059; Fri, 23 Jul 1999 09:12:16 +0200 Date: Fri, 23 Jul 1999 09:12:16 +0200 Message-Id: <199907230712.JAA15059@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: martin-flatin@epfl.ch CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <199907221653.SAA15860@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] compression in SNMPv1 References: <199907221653.SAA15860@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: JP> I'm glad to read that Juergen now wants 3 different RFCs for these JP> 3 features; he wanted just one a few weeks ago, which I wasn't JP> happy with. I probably did not express myself very well: I always had in mind to work out three independent specifications. What I was talking about in Boston is that I have a strong preference to publish all three documents together as a single deliverable of the NMRG. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id XAA06794 for nmrg-outgoing; Thu, 22 Jul 1999 23:32:02 +0200 (MET DST) Received: from dinkel.civ.utwente.nl (dinkel.civ.utwente.nl [130.89.1.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with SMTP id XAA06790 for ; Thu, 22 Jul 1999 23:32:00 +0200 (MET DST) Received: from cs.utwente.nl (ut198100.inbel.utwente.nl) by dinkel.civ.utwente.nl with SMTP id AA18201 (5.67b/IDA-1.5 for ); Thu, 22 Jul 1999 23:31:56 +0200 Message-Id: <37978E10.C1981B98@cs.utwente.nl> Date: Thu, 22 Jul 1999 23:33:04 +0200 From: Ron Sprenkels X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: martin-flatin@epfl.ch Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] compression in SNMPv1 References: <199907221653.SAA15860@icasun1.epfl.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi Folks, > > 1) Our main goal is probably not saving on the number of bits that > > need to be transported, but saving on the number of round-trips > > (= time) that are currently needed (since we only have GetNext > > and GetBulk) to fetch large amounts of data. > > I disagree. The overall goal is to keep both the latency and the > network overhead low. I agree that those are two goals we want to achieve. If we would want to rank the two, I'd say the most important one is to get latency down, and then to reduce the number of bytes sent over the wire. My reason for this is that right here and now, If I retrieve a lot of MIB data with get-nexts, in one thread (so in order), it is in my LAN case not the lack of bandwidth that is slowing things down, but the number of round trip times I need. But yes, we want to address _both_ issues. > By compressing data, you decrease the number > of messages (-> less overhead at the end hosts and at the routers) > and you increase the payload-to-header ratio ("more buck to the byte"). This is true IFF the implementation manages to fill up the messages close to maxmessagesize. If an implementation choses to fill up a message (close) to maxmessagesize, and then compresses it and sends it over the wire, you just save bytes over the wire, but the number of messages (and needed rtts) stays the same. So I guess we should/SHOULD explicitly encourage implementers to fill up those messages to the limit. > Everybody expects the amount of management data to move about to > increase in tomorrow's networks, and no network administrator wants > to tell his boss that the proportion of the link capacity used up by > management overhead is increasing. That indeed does sound as harmful to the guy's carreer :-) > The best solution to satisfy these > two opposite constraints is compression. Compression, if done right, improves latency (by reducing # rtts) and reduces # bytes sent over the wire. Also the latter goal can be missed, when e.g. gzipping single short varbind requests/responses. In that case, they get bigger! So like always, some common sense must be applied to the whole process. > > 2) If we have a GetTree over TCP, we need only one round trip to fetch > > the complete MIB! In that case, compression doesn't save much time. > This is wrong, as Juergen pointed out. With an 8K message size, most > tables will require several TCP messages. Even with 64K, many tables > wouldn't fit in a single message. I believe that in common cases putting GetSubtree over TCP _could_ move the bottleneck from the system from rtt-bound to bandwidth-bound. Rtt in the getsubtree over tcp scenario is only the bottleneck iff the agent manages to send linked responses at such a high rate that it has to wait for the manager's side TCP stack to ack the reception of n-times ago sent chunck of data. In other words, if the TCP protocol runs out of its windowsize. Now, I am not really sure here, but as far as I know, this occurs only in very high rtt-latencey-times-bandwidth cases. > > 3) Intermediate conclusion: compression can be a useful, but not an > > essential feature (I consider TCP and GetTree more important). > > I don't want to rank them, because their usefulness is site specific. > There are really independent. I'm glad to read that Juergen now wants > 3 different RFCs for these 3 features; he wanted just one a few weeks > ago, which I wasn't happy with. Getting them in some order of importance is difficult, if not impossible. And as JP says, depends on the situation at hand. So looking at them independantly is probably best. On LANs I could imagine that compression is not as important as reducing the number of individual chuncks of data to be processed. In a wireless/WAN environment raw bandwidth might be the most precious thing, so you would want compression first. So it depends. > > 6) In that case I propose we choose ONE compression algorithm for ever. > > I'm strongly opposed to that. Even the Java folks, who like to cast > everything in Java iron, supported 2 compression schemes from day 1: > gzip (to please the Unix world) and zip (to please the Windows world). I'll go along with this motivation a long way. One mechanism that probably _reduces_ the number of algorithms you want is have the mechanism where things are compressed only if the result is actually smaller than the original. So try, and if bigger, forget it. If you have that, the need for different algorithms, depending on if you are going to compress alot or just a single varbind, goes away a bit. I am not sure if it would be reduced to just a single algorithm. > Tomorrow, a Unisys-like patent issue might cause contempt for the > compression algorithm you selected "forever". We don't want to be > exposed to such design problems. Now this would be a bad thing. Which makes a good reason to support different algorithms. If possible. Ron. Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA28129 for nmrg-outgoing; Thu, 22 Jul 1999 18:53:17 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA28124 for ; Thu, 22 Jul 1999 18:53:14 +0200 (MET DST) Received: from tcomhp31.epfl.ch (tcomhp31.epfl.ch [128.178.151.22]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id SAA15860; Thu, 22 Jul 1999 18:53:13 +0200 (MET DST) Message-Id: <199907221653.SAA15860@icasun1.epfl.ch> X-Mailer: exmh version 2.0.2 2/24/98 From: "J.P. Martin-Flatin" To: nmrg@ibr.cs.tu-bs.de Cc: martin-flatin@epfl.ch Reply-To: martin-flatin@epfl.ch Subject: Re: [nmrg] compression in SNMPv1 In-reply-to: Your message of "Wed, 21 Jul 1999 10:30:47 METDST." <37958537.7A5BEC43@ctit.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Jul 1999 18:53:13 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi, On Wed, 21 Jul 1999 10:30:47 +0200, Aiko Pras wrote: > > 1) Our main goal is probably not saving on the number of bits that > need to be transported, but saving on the number of round-trips > (= time) that are currently needed (since we only have GetNext > and GetBulk) to fetch large amounts of data. I disagree. The overall goal is to keep both the latency and the network overhead low. By compressing data, you decrease the number of messages (-> less overhead at the end hosts and at the routers) and you increase the payload-to-header ratio ("more buck to the byte"). Everybody expects the amount of management data to move about to increase in tomorrow's networks, and no network administrator wants to tell his boss that the proportion of the link capacity used up by management overhead is increasing. The best solution to satisfy these two opposite constraints is compression. > 2) If we have a GetTree over TCP, we need only one round trip to fetch > the complete MIB! In that case, compression doesn't save much time. This is wrong, as Juergen pointed out. With an 8K message size, most tables will require several TCP messages. Even with 64K, many tables wouldn't fit in a single message. > 3) Intermediate conclusion: compression can be a useful, but not an > essential feature (I consider TCP and GetTree more important). I don't want to rank them, because their usefulness is site specific. There are really independent. I'm glad to read that Juergen now wants 3 different RFCs for these 3 features; he wanted just one a few weeks ago, which I wasn't happy with. > 6) In that case I propose we choose ONE compression algorithm for ever. I'm strongly opposed to that. Even the Java folks, who like to cast everything in Java iron, supported 2 compression schemes from day 1: gzip (to please the Unix world) and zip (to please the Windows world). Tomorrow, a Unisys-like patent issue might cause contempt for the compression algorithm you selected "forever". We don't want to be exposed to such design problems. Jean-Philippe ____________________________________________________________________ Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland Email: martin-flatin@epfl.ch Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA07123 for nmrg-outgoing; Wed, 21 Jul 1999 10:55:29 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA07119; Wed, 21 Jul 1999 10:55:24 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA22850; Wed, 21 Jul 1999 10:55:24 +0200 Date: Wed, 21 Jul 1999 10:55:24 +0200 Message-Id: <199907210855.KAA22850@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: pras@ctit.utwente.nl CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <37958537.7A5BEC43@ctit.utwente.nl> (message from Aiko Pras on Wed, 21 Jul 1999 10:30:47 +0200) Subject: Re: [nmrg] compression in SNMPv1 References: <199907200107.SAA03897@dthaler.microsoft.com> <199907200757.JAA14021@henkell.ibr.cs.tu-bs.de> <37958537.7A5BEC43@ctit.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Aiko Pras writes: Aiko> Probably we need two flags: one indicating that the current Aiko> message / PDU is compressed, and to other indicating that the Aiko> response should (preferably) be compressed. After that we still Aiko> have three flag bits left ... The first bit is not needed since we have to introduce a compressed PDU anyway in order to express things well in ASN.1. Hence you get the bit from the PDU tag. Aiko> After thinking a while over the issue, I've currently the Aiko> following feelings: Aiko> 1) Our main goal is probably not saving on the number of bits Aiko> that need to be transported, but saving on the number of Aiko> round-trips (= time) that are currently needed (since we only Aiko> have GetNext and GetBulk) to fetch large amounts of data. You are missing the fact that compression allows to put much more data into a response. This can drastically reduce the number of round-trips you need with GetBulk (and GetTree). Aiko> 2) If we have a GetTree over TCP, we need only one round trip to Aiko> fetch the complete MIB! In that case, compression doesn't save Aiko> much time. You are missing the fact that even with GetTree, we end up having multiple response due to buffer size constraints. Furthermore, reducing the overall size of the response(s) will result in fewer round trips in the TCP layer. Aiko> 3) Intermediate conclusion: compression can be a useful, but not Aiko> an essential feature (I consider TCP and GetTree more Aiko> important). I agree as long as the data sizes are sufficiently small. If I take your accounting data example, then compression may make a big difference. Of course, this depends on the available bandwidth, the CPU power you have and so on. Aiko> 4) Therefore it would be unwise to come up with a solution for Aiko> compression that would violate SNMPs architecture too much. Aiko> SNMPv3 is already difficult to understand (because the problem Aiko> it is solving is difficult), and making it more complex to Aiko> introduce a useful, but not essential feature may not be a good Aiko> idea. I generally agree that we should not violate the architecture. You are right that compression is a feature. And that is why we put the three things (SNMP over TCP, Compression, GetTree) into seperate specs that can be implemented and used independently. Aiko> 5) With respect to SNMPv3, the most promising approach I see now Aiko> is using two of the message flags. Make that 1 message flag and the CompressedPDU and I agree. Aiko> 6) In that case I propose we choose ONE compression algorithm Aiko> for ever. My motivation is one of "architectural symmetry" Aiko> (isn't that a nice term?). Let me explain. The message flags are Aiko> currently used for authentication & encryption (plus report Aiko> generation). The choice which authetication / encryption Aiko> algorithms to use, is determined by the msgsecuritymodel Aiko> parameter, immediately after the msgflags field. For the purpose Aiko> of choosing between different compression algorithms we can not Aiko> introduce a new field 'msgcompressionmodel'. Therefore I Aiko> suggest to choose a single compression algorithm. I disagree. What we learned in Oslo is that compression algorithms really behave quite different and I have doubts that its possible to find a one-size-fits-all algorithm. Furthermore, your analogy wrt. authentication and encryption algorithms in SNMPv3 is wrong. The msgSecurityModel only identifies the security model (e.g. USM). Within the USM security model, you identify the algorithm to be used by looking into the usmUserTable, which is bound to the msgUserName of the UsmSecurityParameters. If we bind the compression algorithm to the engineID, then we do not need to introduce any new fields in the message header. And we are basically doing the same trick that USM is already using. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA06476 for nmrg-outgoing; Wed, 21 Jul 1999 10:31:09 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA06469; Wed, 21 Jul 1999 10:31:05 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.16.21]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with ESMTP id KAA20893; Wed, 21 Jul 1999 10:30:49 +0200 (MET DST) Message-ID: <37958537.7A5BEC43@ctit.utwente.nl> Date: Wed, 21 Jul 1999 10:30:47 +0200 From: Aiko Pras X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de CC: Juergen Schoenwaelder , dthaler@dthaler.microsoft.com Subject: Re: [nmrg] compression in SNMPv1 References: <199907200107.SAA03897@dthaler.microsoft.com> <199907200757.JAA14021@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi all > Dave> Just to add another possibility to the list... > Dave> [skip] > Juergen> I think the issue was to find a bit which could be allocated so that Juergen> a) an agent supporting compression can apply compression at its own Juergen> discretion and b) an existing agent not supporting compression will Juergen> process the message as usual. This is possible in SNMPv3 by allocating Juergen> one of the unused msgFlags. Probably we need two flags: one indicating that the current message / PDU is compressed, and to other indicating that the response should (preferably) be compressed. After that we still have three flag bits left ... After thinking a while over the issue, I've currently the following feelings: 1) Our main goal is probably not saving on the number of bits that need to be transported, but saving on the number of round-trips (= time) that are currently needed (since we only have GetNext and GetBulk) to fetch large amounts of data. 2) If we have a GetTree over TCP, we need only one round trip to fetch the complete MIB! In that case, compression doesn't save much time. 3) Intermediate conclusion: compression can be a useful, but not an essential feature (I consider TCP and GetTree more important). 4) Therefore it would be unwise to come up with a solution for compression that would violate SNMPs architecture too much. SNMPv3 is already difficult to understand (because the problem it is solving is difficult), and making it more complex to introduce a useful, but not essential feature may not be a good idea. 5) With respect to SNMPv3, the most promising approach I see now is using two of the message flags. 6) In that case I propose we choose ONE compression algorithm for ever. My motivation is one of "architectural symmetry" (isn't that a nice term?). Let me explain. The message flags are currently used for authentication & encryption (plus report generation). The choice which authetication / encryption algorithms to use, is determined by the msgsecuritymodel parameter, immediately after the msgflags field. For the purpose of choosing between different compression algorithms we can not introduce a new field 'msgcompressionmodel'. Therefore I suggest to choose a single compression algorithm. > I more or less came to the conclusion that > this is not possible in SNMPv1/SNMPv2c. All the solutions discussed so > far (including the new port number proposal) fail to support a) and b) > wrt. SNMPv1/SNMPv2c. In SNMPv1/SNMPv2c it is possible to introduce a separate varbind to indicate that the response should be compressed. While this has the nice feature that would be transparent to existing SNMPv1/SNMPv2c implementations (they behave exactly as expected), it is not architectural clean. Given the reasoning above, we should probably not take this solution. Bye Aiko Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA01218 for nmrg-outgoing; Tue, 20 Jul 1999 10:00:49 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA01087; Tue, 20 Jul 1999 09:57:23 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA14021; Tue, 20 Jul 1999 09:57:23 +0200 Date: Tue, 20 Jul 1999 09:57:23 +0200 Message-Id: <199907200757.JAA14021@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dthaler@dthaler.microsoft.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <199907200107.SAA03897@dthaler.microsoft.com> (message from Dave Thaler on Mon, 19 Jul 1999 18:07:16 -0700 (PDT)) Subject: Re: [nmrg] compression in SNMPv1 References: <199907200107.SAA03897@dthaler.microsoft.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Dave Thaler writes: Dave> Just to add another possibility to the list... Dave> The context of this email is the discussion last Thursday of how Dave> a manager could specify in SNMPv1 that a compressed response Dave> would be preferred (with the assumption that only one Dave> compression type is supported for SNMPv1), and you need to find Dave> a bit somewhere. Dave> An alternative that hasn't been mentioned yet is to allow the Dave> agent to listen on a separate well-known port number. A request Dave> on 161 is then always normal (no compression), and a request Dave> sent to another well-known port means compression is requested. I think the issue was to find a bit which could be allocated so that a) an agent supporting compression can apply compression at its own discretion and b) an existing agent not supporting compression will process the message as usual. This is possible in SNMPv3 by allocating one of the unused msgFlags. I more or less came to the conclusion that this is not possible in SNMPv1/SNMPv2c. All the solutions discussed so far (including the new port number proposal) fail to support a) and b) wrt. SNMPv1/SNMPv2c. My conclusion therefore is the following: In SNMPv1/SNMPv2c, the receiving SNMP engine is only allowed to do compression when it received a compressed request. This means that uncompressed requests leading to compressed responses are only possible in SNMPv3, while SNMPv1/SNMPv2c only support compressed requests leading to compressed responses. I think this is a fair and clean solution (and it gives some motivation to move to SNMPv3). Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id BAA19530 for nmrg-outgoing; Tue, 20 Jul 1999 01:26:42 +0200 (MET DST) Received: from dthaler.microsoft.com ([131.107.1.30]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id BAA19526 for ; Tue, 20 Jul 1999 01:26:40 +0200 (MET DST) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id SAA03897 for nmrg@ibr.cs.tu-bs.de; Mon, 19 Jul 1999 18:07:16 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907200107.SAA03897@dthaler.microsoft.com> Subject: [nmrg] compression in SNMPv1 To: nmrg@ibr.cs.tu-bs.de Date: Mon, 19 Jul 1999 18:07:16 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Just to add another possibility to the list... The context of this email is the discussion last Thursday of how a manager could specify in SNMPv1 that a compressed response would be preferred (with the assumption that only one compression type is supported for SNMPv1), and you need to find a bit somewhere. An alternative that hasn't been mentioned yet is to allow the agent to listen on a separate well-known port number. A request on 161 is then always normal (no compression), and a request sent to another well-known port means compression is requested. -Dave Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id BAA19481 for nmrg-outgoing; Tue, 20 Jul 1999 01:20:28 +0200 (MET DST) Received: from dthaler.microsoft.com ([131.107.1.30]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id BAA19476 for ; Tue, 20 Jul 1999 01:20:23 +0200 (MET DST) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id SAA03879; Mon, 19 Jul 1999 18:01:02 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199907200101.SAA03879@dthaler.microsoft.com> Subject: [nmrg] GET-SUBTREE-MIB To: nmrg@ibr.cs.tu-bs.de Date: Mon, 19 Jul 1999 18:01:02 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I brought this up on Sunday, and we decided that it needed more thought/discussion, so to generate some discussion, here's a strawman MIB which would allow get-subtree operations without changing SNMP. (Discussion continued after the mib, below...) GET-SUBTREE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32 FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; getSubtreeMIB MODULE-IDENTITY LAST-UPDATED "9907161200Z" ORGANIZATION "IRTF Network Management Research Group" CONTACT-INFO " Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: dthaler@dthaler.microsoft.com" DESCRIPTION "This MIB module provides the ability to retrieve an arbitary subtree of OIDs by receiving traps." ::= { XXX } getSubtreeMIBObjects OBJECT IDENTIFIER ::= { getSubtreeMIB 1 } getSubtree OBJECT IDENTIFIER ::= { getSubtreeMIBObjects 1 } getSubtreeTraps OBJECT IDENTIFIER ::= { getSubtreeMIBObjects 2 } getSubtreeTable OBJECT-TYPE SYNTAX SEQUENCE OF GetSubtreeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on GET-SUBTREE operations in progress." ::= { getSubtree 1 } getSubtreeEntry OBJECT-TYPE SYNTAX GetSubtreeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular GET-SUBTREE operation in progress." INDEX { getSubtreeIndex } ::= { getSubtreeTable 1 } GetSubtreeEntry ::= SEQUENCE { getSubtreeIndex Unsigned32, getSubtreeTargetAddrName SnmpAdminString, getSubtreeRootOid OBJECT IDENTIFIER, getSubtreeSequenceNumber Counter32, getSubtreeDone TruthValue, getSubtreeStatus RowStatus } getSubtreeIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer uniquely identifying the GET-SUBTREE operation in progress. This value should be randomly generated by a manager before attempting to create the row." ::= { getSubtreeEntry 1 } getSubtreeTargetAddrName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This object selects a management target defined in the snmpTargetAddrTable (in the SNMP-TARGET-MIB). The selected target is defined by an entry in the snmpTargetAddrTable whose index value (snmpTargetAddrName) is equal to this object." ::= { getSubtreeEntry 2 } getSubtreeRootOid OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OID of the subtree to be sent." ::= { getSubtreeEntry 3 } getSubtreeSequenceNumber OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of trap responses previously sent for this request." ::= { getSubtreeEntry 4 } getSubtreeDone OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This is set to true in the last trap sent, and is set to false otherwise." ::= { getSubtreeEntry 5 } getSubtreeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new entries may be created, or old entries deleted from this table. Once created, the row may be deleted, but other objects in the row may not be modified. A row will be deleted automatically by the agent once the operation has completed." ::= { getSubtreeEntry 6 } -- traps getSubtreeTrapPrefix OBJECT IDENTIFIER ::= { getSubtreeTraps 0 } getSubtreeResponse NOTIFICATION-TYPE OBJECTS { getSubtreeSequenceNumber, getSubtreeDone } STATUS current DESCRIPTION "In addition to the two objects above, this trap also contains a series of varbinds containing the next chunk of the subtree. The generating entity will append, in order, as many variables to the variable-bindings field as it can without exceeding the maximum message size, and without going beyond the subtree of OIDs requested. A series of such traps will be generated until the end of the subtree is reached." ::= { getSubtreeTrapPrefix 1 } -- conformance information getSubtreeMIBConformance OBJECT IDENTIFIER ::= { getSubtreeMIB 2 } getSubtreeMIBCompliances OBJECT IDENTIFIER ::= { getSubtreeMIBConformance 1 } getSubtreeMIBGroups OBJECT IDENTIFIER ::= { getSubtreeMIBConformance 2 } -- compliance statements getSubtreeMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the GetSubtree MIB." MODULE -- this module MANDATORY-GROUPS { getSubtreeObjectGroup, getSubtreeNotificationGroup } ::= { getSubtreeMIBCompliances 1 } -- units of conformance getSubtreeObjectGroup OBJECT-GROUP OBJECTS { getSubtreeTargetAddrName, getSubtreeRootOid, getSubtreeSequenceNumber, getSubtreeDone, getSubtreeStatus } STATUS current DESCRIPTION "A collection of objects to support requests for subtree retrieval operations." ::= { getSubtreeMIBGroups 1 } getSubtreeNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { getSubtreeResponse } STATUS current DESCRIPTION "The notification which an entity is required to implement." ::= { getSubtreeMIBGroups 2 } END As discussed last week, the interesting issue is how to get the information back to the application that issued the "request". As you will see above, I tentatively put in an SnmpAdminString object which provides an index into the SNMP-TARGET-MIB. HOWEVER, it would be nice to be able to initiate a get-subtree with a single SET from an arbitrary application. Another (perhaps more desirable) possibility would be to either add a columnar TAddress object that would also create a temporary row in the SNMP-TARGET-MIB, or perhaps it could be created automatically based on the source address/port of the SET? It's interesting to note that this would make it possible to have the traps sent back to a port other than 162, such as the port the app sends the SET from, so that the response to the SET, and the traps, all go back to the same port. -Dave Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA27963 for nmrg-outgoing; Fri, 16 Jul 1999 10:58:33 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA27958; Fri, 16 Jul 1999 10:58:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA01698; Fri, 16 Jul 1999 10:58:15 +0200 Date: Fri, 16 Jul 1999 10:58:15 +0200 Message-Id: <199907160858.KAA01698@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wjhardaker@ucdavis.edu CC: nmrg@ibr.cs.tu-bs.de, schoenfr@gaertner.de In-reply-to: (message from Wes Hardaker on 15 Jul 1999 10:33:51 -0700) Subject: Re: [nmrg] first Oslo meeting results References: <199907121240.OAA17226@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Wes Hardaker writes: Wes> The one thing that I think would be necessary would be to Wes> indicate the compression algorithm in the message sent, rather Wes> than by a previous "set" or "configuration" or "default" of the Wes> engine you're talking to. That will cause problems with multiple Wes> entities talking to the same engine and they each want to use a Wes> different compression function. Yes. We had some discussion about this and other issues yesterday once we had the first prototype running. I hope to be able to send out an updated version of the proposal when I am back home. Wes> How about a table of supported compressions and then have the Wes> compression type indicated in the beginning of the octet string? Wes> Most compression algorithms (I think) have a magic X number of Wes> bytes in the beginning of the string don't they? The question is whether you want to rely on these bytes (which are not under central control). Anyway, I believe that there will be few compression algorithms in practice and I also expect that you will not change compressions algorithms regularily. So the question is whether it really makes sense to indicate the algorithm in every message. BTW, you do not find an indication of the encryption or authentication algorithm in SNMPv3 either. Wes> Though, I'll leave the CompressionType definition up to future Wes> debate... An OID is too long, but anything else would be more of Wes> a registration pain. Yes. And hence a MIB object might be a cheap way out. A manager can retrieve this object before starting a bulk retrieval. This also has the advantage that the manager knows whether the agent supports compression at all. And in the notification originator case, you need to have local configuration information in order to determine whether you can use compression. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id UAA06856 for nmrg-outgoing; Thu, 15 Jul 1999 20:06:25 +0200 (MET DST) Received: from oakdale.ucdavis.edu (oakdale.ucdavis.edu [169.237.210.82]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id UAA06851; Thu, 15 Jul 1999 20:06:13 +0200 (MET DST) Received: (from hardaker@localhost) by oakdale.ucdavis.edu (8.9.3/8.9.3) id KAA15097; Thu, 15 Jul 1999 10:33:51 -0700 (PDT) To: Juergen Schoenwaelder Cc: Network Management Research Group , schoenfr@gaertner.de Subject: Re: [nmrg] first Oslo meeting results References: <199907121240.OAA17226@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 15 Jul 1999 10:33:51 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Mon, 12 Jul 1999 14:40:25 +0200" Message-ID: Lines: 68 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta13) (Demeter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On Mon, 12 Jul 1999 14:40:25 +0200, Juergen Schoenwaelder said: Juergen> Below is some stuff I wrote down this morning. I'll try for a longer response next week, when I have more time, but... Juergen> NMRG-SNMP-COMPRESSED-PDU DEFINITIONS ::= BEGIN Juergen> CompressedPDU ::= -- contains a compressed PDU Juergen> [9] IMPLICIT Juergen> OCTET STRING Juergen> END ... Juergen> o I propose to bind the compression algorithm to the SNMP engine Juergen> rather than a securityName within an SNMP engine. Agreed, though... Juergen> snmpEngineCompProtocol OBJECT-TYPE Juergen> SYNTAX AutonomousType Juergen> MAX-ACCESS read-write Juergen> STATUS current Juergen> DESCRIPTION Juergen> "The compression protocol used by the SNMP engine. The value Juergen> zeroDotZero indicates that the SNMP engine does not support Juergen> SNMP compression. The value of this object may be changed Juergen> to select a different compression protocol. Attempts to set Juergen> this object to a compression algorithm not supported by the Juergen> SNMP engine will result in an inconsistentValue error." Juergen> DEFVAL { zeroDotZero } Juergen> ::= { snmpCompObjects 1 } The one thing that I think would be necessary would be to indicate the compression algorithm in the message sent, rather than by a previous "set" or "configuration" or "default" of the engine you're talking to. That will cause problems with multiple entities talking to the same engine and they each want to use a different compression function. How about a table of supported compressions and then have the compression type indicated in the beginning of the octet string? Most compression algorithms (I think) have a magic X number of bytes in the beginning of the string don't they? Or, actually have the CompressedPDU be more like: CompressedPDU ::= -- contains a compressed PDU [9] IMPLICIT SEQUENCE { compression-type CompressionType, compressed-pdu OCTET STRING } END Though, I'll leave the CompressionType definition up to future debate... An OID is too long, but anything else would be more of a registration pain. -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA17851 for nmrg-outgoing; Wed, 14 Jul 1999 18:26:23 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA17844; Wed, 14 Jul 1999 18:26:20 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA22788; Wed, 14 Jul 1999 18:26:20 +0200 Date: Wed, 14 Jul 1999 18:26:20 +0200 Message-Id: <199907141626.SAA22788@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: martin-flatin@epfl.ch CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <199907141121.NAA15562@icasun1.epfl.ch> (martin-flatin@epfl.ch) Subject: Re: [nmrg] Conserving memory References: <199907141121.NAA15562@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: JP> I find our discussion about buffer sizes slightly JP> anachronistic. People in the JINI world are now taking for granted JP> that we have a JVM and a significant amount of software embedded JP> in all the devices that we find in our day-to-day life: that's JP> what it takes to implement a universal plug and play (automatic JP> configuration) that isn't bound to Windows and that doesn't cost JP> as much as CORBA. Many device vendors have signed in the JINI JP> concept. The memory requirements of such a scenario render our JP> discussion obsolete. Lets talk about this when we are a few years older. Perhaps it turns out that vendors signing in into JINI was the anachronistic action. ;-) Juergen Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA11065 for nmrg-outgoing; Wed, 14 Jul 1999 15:38:19 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA11060 for ; Wed, 14 Jul 1999 15:38:18 +0200 (MET DST) Received: from myrtilos.cs.utwente.nl (myrtilos.cs.utwente.nl [130.89.16.9]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with SMTP id PAA16345 for ; Wed, 14 Jul 1999 15:38:15 +0200 (MET DST) Received: from shannon.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id PAA13641; Wed, 14 Jul 1999 15:38:15 +0200 Received: by shannon.cs.utwente.nl (SMI-8.6/SMI-SVR4) id PAA09050; Wed, 14 Jul 1999 15:38:14 +0200 Date: Wed, 14 Jul 1999 15:38:14 +0200 From: beijnum@cs.utwente.nl (Bert-Jan van Beijnum) Message-Id: <199907141338.PAA09050@shannon.cs.utwente.nl> To: nmrg@ibr.cs.tu-bs.de Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Oslo Minutes (11 July, 1999) ============================ Present: Juergen Schoenwalder (JS), University of Braunscheig Aiko Pras (AP), University of Twente Ron Sprenkel (RS) University of Twente Bert Wijnen (BW) IBM Bert-Jan van Beijnum (BJ) University of Twente Eric Schoenfelder(E) Dave Thaler (D) Microsoft Agenda: ======= 1. discuss any open issues w.r.t. the SNMP over TCP document 2. discuss and select an approach for SNMP payload compression 3. work out the details of the GetSubTree protocol operation 4. (if time is left) discuss the SMIng specification 5. discuss other topics such as meta-level discussions on NMRG. We started the meeting outside: the wether was nice and the door was closed so we couldn’t get in. 1 SNMP over TCP document ======================== *About closing TCP connection: what when connections gets lost/closes? option1: do not specify. motivation: it aligns with the UDP case option2:do specify. TCP i.e. a request is send and agent received it. motivtion: with UDP: you dont’n know of a request arrives, with tcp you do know. Discussion ---------- example: if you do a bulkset, you want to know wether it succeeded (arrival is nice, but you don’t know if it succeeded when the tcp connection is broken). observation: you could do either a confirmed or an unconfirmed set- opeeration. After we went in, Bert-Jan made some coffee, which we all appreciated! The fundamental issue is: what are the consequences for the application. traps & inform: transport gets confirmed. with sets: confirms tell you that they have been transported and processed. BW: not specify behavior when TCP closes/breaks JS: one way shut down should be specified as legal. EOF only when all packets have been processed. BW: make a note about closing connection in one direction in the document. AP: poors us a cup of coffee. Include notes about ‘half closing a connection’ (about what to assume and what not in this case); The manager should not assume anything except what can be based on responses. Include explanation about implementation choices whether or not to process arrived packets. Explain about the meaning of responses/replies/informs received (authentication and encryption has taken place). Harald’s email: the message was about how to explain things. Conclusion: There is (rough) consensus about not include such detialed levels of info in the document. The AD takes care of getting the next round of coffee. Conclusions: ------------ - put in text that processing outstanding packets after closing is up to the implementer. - the sending entity should not assume anything about processing or not, but rely on normal SNMP operation. - wording to include about half closed connections. 2. SNMP payload compression =========================== The options are: 1. another encryption algorithm 2. use msgFlag bits to signal compression 3. define a new PDUtype 4. (added) (Wes H.) introduce a new security model. 5. (added) (RS) overload the security name: whether compression is used or not. This has a simiilar disadvantage as in 1. and it is not an architectural clean thing to do (easy to implement though) Discussion: ----------- BW: the better it fits in v3 the better it is JS: the better is fits in v1 the better it is BW: the PDU solution might be a problem. JS: but if one has to be done (getSubTreePDU), two can be done as well!? BW: can live with a new PDU provided that a new PDU for get SubTree is needed. Some procedural proposal: - select a solution - propose a compression method - include option for other compression methods If you preconfigure compression, you don’t need a new PDU type. After discussion, the following came out - First choice: new PDU tpye, - Second choice msgFlag, - Third choice encryption or option 5 or option 4. First and second choice remain to be chosen from. All agree with one, under the following consideration: if a new PDU is being introduced, then introduce a new PDU type for compression! Implementation issues: - no prescription about how to do the compression from the PDU contructed or under construction, this is left to the implementation. 3.getSubTree SNMP operation =========================== BW: suggestion - give a consideration to trick the getBULK, to avoid new PDU type discussions. BW has to leave the meeting. Dave attends the meeting. Dave: Include in the document the option to use IPsec for compression. Question: what if there are multiple subtrees? AP: subtrees can be very large, that should be allowed. This calls for multiple replies (to limit buffer size). Observation: after a single reply the manager could be noted that there is more, it is the manager that asks for the next portion. This is another possible scenario. Advantage is that in case of single threaded agents, it won’t be blocked during the getSubTree operation. Disadvantage is relative large RTT’s. Everybody agrees that in getSubTree we assume that TCP is being used. It is not mandatory to return a consistent response to a getSubTree. Sending multiple responses: set timer for inter packet timeout, a flag for the last response. It should be possible to use getSubTree over UDP. Question: In case of request retransmission a new request ID should be used, or should the same be used? Solution: current specs recommend (should) to use a new ID for retransmissions. Options: specify MUST, because it’s a new PDU. Or SHOULD with an explanation why. Qs: send multiple responses: TCP is in sequence, UDP we don’t know. How to indentify the last response, what about error situations. Question - If an error occurs: should or must be the last response? Solution: MUST seem to be the appropriate solution. Quetion: Is it useful that the manager can stop a getSubTree? Solution: Using TCP you can simply close the connection. Dave: What about a set for row creation to specify the subtree and the agent responds with a bunch of traps contain the subtree? Conclusion: This is a very good suggestion, which will be studied further at a later stage. Qs: multiple responses over UDP, i.e. sequence numbers number be used, where to have them in the PDU? Possible solutions: - An option is to use the error-status (which is unused in this case). - Put a verbind in each PDU. - Build a special respond message. There is preference for the first option Question: how to code the last PDU? Possible solution: - use highest bit of the error status - .or introduce a new error code option 2 portentially influences documents such as 190X, Question: what’s going to happen when there are holes in a/the subtree? JS proposes an algorithm to solve this problem (which can be used also in the set/trap ‘solution’) and can be easily done by the agent: just return ‘noSuchInstance’ for te holes. Intermezzo: (I really had concentrationproblems here, so the minutes do not make sense to me ;-)))). Make an association between oid and ? this has many advantages and really adds something (it is really different from the getBULK). MIB Bowsing: getSubTree(1), you do not get tables as table. To get tables as table you need to get each column individually. There is preference for non-repeating repeater. JS: is it useful to have a timestamp on each ‘fragment’ (i.e. a side question made by BJ pops up again ;-)))). For some variables it could be useful. End of intermezzo (I think I’m back again). About sequence numbering: Use of row-numbers could be helpful for UDP, however we expect things to use TCP, therefore there is no need or it. Asymmetric Compession can be useful in getSubTree: an uncompressed get request and a compressed reply. How to continue: - implementing & writing an ID should go hand-in-hand. Next Meeting ============ - We arrange another meeting for later this week to discuss things further - next meeting is: Thursday July 15, 1999 13:00-15:00. --- BJ. Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id NAA04174 for nmrg-outgoing; Wed, 14 Jul 1999 13:21:40 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA04154 for ; Wed, 14 Jul 1999 13:21:35 +0200 (MET DST) Received: from tcomhp31.epfl.ch (tcomhp31.epfl.ch [128.178.151.22]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id NAA15562; Wed, 14 Jul 1999 13:21:34 +0200 (MET DST) Message-Id: <199907141121.NAA15562@icasun1.epfl.ch> X-Mailer: exmh version 2.0.2 2/24/98 From: "J.P. Martin-Flatin" To: nmrg@ibr.cs.tu-bs.de Cc: martin-flatin@epfl.ch Reply-To: martin-flatin@epfl.ch Subject: [nmrg] Conserving memory In-reply-to: Your message of "Fri, 09 Jul 1999 17:35:55 METDST." <199907091535.RAA26579@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 13:21:33 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk On Fri, 9 Jul 1999 17:35:55 +0200, Juergen Schoenwaelder wrote: > > Jean-Philippe argued for 64K and I said no way. We then started > lengthy discussions and finally we tried to find a compromise. I > started with "lets go with 2K" and we finally ended up with 8K. This > is after all an arbitrary choice. However, the fact that someone is > going to support the TCP transport mapping probably means that he > should have at least some memory available for it. So I still think > its reasonable (even though I would have preferred a smaller number). My rationale is that a vendor will not add support for SNMP over TCP to a box that doesn't have enough memory. If you're tight on memory, you keep using UDP, even for large transfers. We debated what we mean by "enough" memory. Because many UDP implementations use a max of 1.5K, I argued that a max of 2K for TCP was too low: the small gain wasn't worth the work required for adding support for TCP. I still believe that we should have picked 64K, which is standard in the TCP realm; but I'm happy with 8K as a compromise. For years, the SNMP community had a problem with bottom-of-the-range boxes and optional SNMP features: the smallest boxes made the rule because all features had to be supported everywhere. Now that SNMPv3 has broken the deadlock and made optional features a de facto situation (no one expects all cheap boxes to implement SNMPv3 compression and security), things may progress now. The concern for small boxes is valid, but shouldn't prevent us from doing things that make sense in top-of-the-range boxes. If you want to transfer large amounts of mgmt data (say 200K), it makes sense to use large TCP buffers (64K). I find our discussion about buffer sizes slightly anachronistic. People in the JINI world are now taking for granted that we have a JVM and a significant amount of software embedded in all the devices that we find in our day-to-day life: that's what it takes to implement a universal plug and play (automatic configuration) that isn't bound to Windows and that doesn't cost as much as CORBA. Many device vendors have signed in the JINI concept. The memory requirements of such a scenario render our discussion obsolete. > The good thing is that we do not write standards. We can pick a number > which we think is a reasonable choice to get prototype implementations > running. We can always change the number if there are people who can > really convince us that this is a problem for them. Agreed Jean-Philippe ____________________________________________________________________ Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland Email: martin-flatin@epfl.ch Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA19889 for nmrg-outgoing; Mon, 12 Jul 1999 14:40:31 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA19879; Mon, 12 Jul 1999 14:40:25 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA17226; Mon, 12 Jul 1999 14:40:25 +0200 Date: Mon, 12 Jul 1999 14:40:25 +0200 Message-Id: <199907121240.OAA17226@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group CC: schoenfr@gaertner.de Subject: [nmrg] first Oslo meeting results Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Below is some stuff I wrote down this morning. I was trying to put some of the things we have discussed on Sunday into formal ASN.1 and MIB definitions. This may serve as input for additional ad-hoc discussions here in Oslo and it allows others on this list to see some of our results. Members not at the meeting may probably not understand all the details and reasonings. If you have questions, just ask or wait until we get the minutes out on this list. o How do we allocate PDU tags? We should not play with the numbers used below because these are the number you want to use in standards and not in experiments. So which number space can we use? o Need to check whether the tag assignements are legal ASN.1 and do what I want them to do. o This is the proposed ASN.1 definition for the compressed PDU: NMRG-SNMP-COMPRESSED-PDU DEFINITIONS ::= BEGIN CompressedPDU ::= -- contains a compressed PDU [9] IMPLICIT OCTET STRING END o This is a first sketch of a MIB for configuration of the compression algorithm. o I propose to bind the compression algorithm to the SNMP engine rather than a securityName within an SNMP engine. First, I am not convinced that it does make sense to support different compression algorithms for different users. Furthermore, binding it to the securityName (or to the community string and the user name) leads to multiple MIB lookups to negotiate the compression algorithm. I really would like to be able to do that with a single get request. NMRG-SNMP-COMPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, zeroDotZero, experimental FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpCompMIB MODULE-IDENTITY LAST-UPDATED "9907121100Z" ORGANIZATION "IRTF Network Management Research Group" CONTACT-INFO "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 Email: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This MIB module defines the SNMP compression MIB." ::= { experimental nmrg(91) 2 } snmpCompObjects OBJECT IDENTIFIER ::= { snmpCompMIB 1 } snmpCompConformance OBJECT IDENTIFIER ::= { snmpCompMIB 2 } snmpCompProtocols OBJECT IDENTIFIER ::= { snmpCompMIB 3 } snmpCompCompliances OBJECT IDENTIFIER ::= { snmpCompConformance 1 } snmpCompGroups OBJECT IDENTIFIER ::= { snmpCompConformance 2 } snmpCompNone OBJECT-IDENTITY STATUS current DESCRIPTION "The trivial no compression protocol." ::= { snmpCompProtocols 1 } snmpCompDeflate OBJECT-IDENTITY STATUS current DESCRIPTION "Deflate compression protocol as defined in RFC 1951." ::= { snmpCompProtocols 2 } snmpEngineCompProtocol OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-write STATUS current DESCRIPTION "The compression protocol used by the SNMP engine. The value zeroDotZero indicates that the SNMP engine does not support SNMP compression. The value of this object may be changed to select a different compression protocol. Attempts to set this object to a compression algorithm not supported by the SNMP engine will result in an inconsistentValue error." DEFVAL { zeroDotZero } ::= { snmpCompObjects 1 } snmpCompCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "" MODULE -- this module MANDATORY-GROUPS { snmpCompGroup } OBJECT snmpEngineCompProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { snmpCompCompliances 1 } nmpCompGroup OBJECT-GROUP OBJECTS { snmpEngineCompProtocol } STATUS current DESCRIPTION "" ::= { snmpCompGroups 1 } END o This is a the proposed ASN.1 definition of the getsubtree PDU and a linked response PDU. o I decided to define a LinkedResponse-PDU as a PDU with a special tag. This way, we can use the tag to mark the end of linked responses: You receive a stream of LinkedResponse-PDUs and finally exactly one Response-PDU. This allows to detect the end of the linked responses without having to define a new error-status value and without having to play dirty games with the error-index field. NMRG-SNMP-GETSUBTREE-PDU DEFINITIONS ::= BEGIN IMPORTS PDU, VarBindList, max-bindings FROM SNMPv2-PDU; GetSubtree-PDU ::= [10] IMPLICIT GetSubtreePDU LinkedResponse-PDU ::= [11] IMPLICIT PDU GetSubtreePDU ::= -- identical in structure to PDU SEQUENCE { request-id INTEGER (-2147483648..2147483647), non-repeaters INTEGER (0..max-bindings), unused -- currently ignored INTEGER (0..max-bindings), variable-bindings -- values are ignored VarBindList } END o The example below shows how the "hole algorithm" should work. I think we should have additional examples (one with a more complex table indexing example and one which shows what happens if you send strange requests. getsubtree(ifIndex, ifDescr) next(ifIndex, ifDescr) -> ifIndex.1 ifDescr.1 -> use 1 response(ifIndex.1 = 1, ifDescr.1 = "eth0") next(ifIndex.1, ifDescr.1) -> ifIndex.2 ifDescr.4 -> use 2 response (ifIndex.2 = 2, ifDescr.2 = "NULL") next(ifIndex.2, ifDescr.2) -> ifIndex.3 ifDescr.4 -> use 3 response (ifIndex.3 = 3, ifDescr.3 = "NULL") next(ifIndex.3, ifDescr.3) -> ifIndex.4 ifDescr.4 -> use 4 response (ifIndex.4 = 4, ifDescr.4 = "eth3") Thats it for now. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA19364 for nmrg-outgoing; Fri, 9 Jul 1999 18:20:07 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA19359; Fri, 9 Jul 1999 18:20:02 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA28007; Fri, 9 Jul 1999 18:20:02 +0200 Date: Fri, 9 Jul 1999 18:20:02 +0200 Message-Id: <199907091620.SAA28007@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: sprenkel@cs.utwente.nl CC: nmrg@ibr.cs.tu-bs.de, helthuis@cs.utwente.nl In-reply-to: <3784BBC5.C4B2B3C0@cs.utwente.nl> (message from Ron Sprenkels on Thu, 08 Jul 1999 16:55:01 +0200) Subject: Re: [nmrg] Work on another implementation of SNMP over TCP References: <3784BBC5.C4B2B3C0@cs.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Ron Sprenkels writes: Ron> Juergen, is your SNMP over TCP agent on 134.169.34.127 port 161 Ron> still running? We did a telnet to it, but got no response. If it Ron> is not, is it possible for you to start it again? I managed to get the TCP code for the CMU Linux agent running again. The agent is currently running on xxxx.ibr.cs.tu-bs.de port 161. The agent also does compression of the PDU. The way I do it right now is not clean (you can't describe it in ASN.1) but I think it is a helpful prototype for getting numbers how efficient compression really is. The next step would be to hack compression into the scotty code so that I can get a better feeling how much savings you get when using some more complex management tools rather than just plain SNMP get/getnext operations. Juergen Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA18565 for nmrg-outgoing; Fri, 9 Jul 1999 18:00:26 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA18501; Fri, 9 Jul 1999 17:59:52 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA27415; Fri, 9 Jul 1999 17:59:52 +0200 Date: Fri, 9 Jul 1999 17:59:52 +0200 Message-Id: <199907091559.RAA27415@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wjhardaker@ucdavis.edu CC: nmrg@ibr.cs.tu-bs.de In-reply-to: (message from Wes Hardaker on 09 Jul 1999 07:23:55 -0700) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-compression-00.txt References: <199906220858.KAA28925@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Wes Hardaker writes: [...] Wes> The last clause in this sentence confuses me. How is compression Wes> "especially useful" when encryption is used? I don't see any Wes> benefits for encryption when compression is used. What I was thinking (and not really writing) was that compression is especially useful if you use encryption which will make compression algorithms in the protocol layers below less effective. Juergen> If both compression and encryption are required, compression Juergen> MUST be applied before encryption. Wes> Well I agree that it would be less useful to perform compression Wes> first, I'm not sure that the word "MUST" is appropriate here. I Wes> think that using the lowercase version of the word would be a Wes> better choice. I agree. Juergen> 2.2. Indicating Compression in the msgFlags Wes> One important detail that is missing from this section is and how Wes> to select a compression algorithm? Certainly, this information is Wes> not stored in the flags. So it must be stored somewhere else in Wes> the packet? In there is no place to do that, unless it is stored Wes> at the beginning of the compressed data. Either way, it should be Wes> noted (even though we're not defining the definition, its a Wes> designing point). I agree. We need to sort this out. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA18253 for nmrg-outgoing; Fri, 9 Jul 1999 17:52:29 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA18224; Fri, 9 Jul 1999 17:52:11 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA27237; Fri, 9 Jul 1999 17:52:11 +0200 Date: Fri, 9 Jul 1999 17:52:11 +0200 Message-Id: <199907091552.RAA27237@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wjhardaker@ucdavis.edu CC: nmrg@ibr.cs.tu-bs.de In-reply-to: (message from Wes Hardaker on 09 Jul 1999 07:09:07 -0700) Subject: Re: [nmrg] Re: Closing connections - II References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> <3785FCA2.842DDB36@ctit.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Wes Hardaker writes: Wes> Does anyone know of a mib node whose definition defines that it Wes> should change values upon retrieval of its current value? I Wes> wouldn't be surprised if something like this existed somewhere. Things like this exist. Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA17688 for nmrg-outgoing; Fri, 9 Jul 1999 17:36:05 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA17680; Fri, 9 Jul 1999 17:35:56 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA26579; Fri, 9 Jul 1999 17:35:55 +0200 Date: Fri, 9 Jul 1999 17:35:55 +0200 Message-Id: <199907091535.RAA26579@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wjhardaker@ucdavis.edu CC: wjhardaker@ucdavis.edu, nmrg@ibr.cs.tu-bs.de In-reply-to: (message from Wes Hardaker on 09 Jul 1999 07:13:30 -0700) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview) References: <199906111513.RAA29887@henkell.ibr.cs.tu-bs.de> <199907090953.LAA16575@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Wes Hardaker writes: Juergen> Since I am not that much interested to start this discussion Juergen> again, I suggest to keep 8192 until we receive serious Juergen> complaints from people who really can't implement 8k buffer Juergen> and who believe that they need to support SNMP over Juergen> TCP. (BTW, my scotty code currently uses 2k buffers and I Juergen> have to increase them as well.) Wes> I assume this is the decision that came out of the last heated Wes> debate? Jean-Philippe argued for 64K and I said no way. We then started lengthy discussions and finally we tried to find a compromise. I started with "lets go with 2K" and we finally ended up with 8K. This is after all an arbitrary choice. However, the fact that someone is going to support the TCP transport mapping probably means that he should have at least some memory available for it. So I still think its reasonable (even though I would have preferred a smaller number). The good thing is that we do not write standards. We can pick a number which we think is a reasonable choice to get prototype implementations running. We can always change the number if there are people who can really convince us that this is a problem for them. I think its better to move on now rather than spending even more time on this constant. [But if you want to have this discussion, you have to talk with Jean-Philippe. ;-] Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA14915 for nmrg-outgoing; Fri, 9 Jul 1999 16:36:25 +0200 (MET DST) Received: from homestyle.dcn.davis.ca.us (IDENT:hardaker@homestyle.dcn.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA14910 for ; Fri, 9 Jul 1999 16:36:18 +0200 (MET DST) Received: (from hardaker@localhost) by homestyle.dcn.davis.ca.us (8.9.3/8.9.3) id HAA27242; Fri, 9 Jul 1999 07:36:15 -0700 To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] New compression idea. References: <199906220858.KAA28925@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 09 Jul 1999 07:36:09 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Tue, 22 Jun 1999 10:58:12 +0200" Message-ID: Lines: 49 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta8) (Artemis) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I just realized I sent the last note to internet-drafts as well (sigh). Sorry about that. You know, this really isn't an easy problem is it? Another thought I came up with last night, which I'm not sure I like much better (but its a though): We could define a new security model which would essentially be nothing but an compression wrapper around a lower security model. In this sense, the msgSecurityParamaters would be replaced by a sequence who's last entry was the security parameters sequence of the lower security module. IE, something like: compressSecurityParameters ::= SEQUNCE { compressionType OBJECT IDENTIFIER CHOICE { UsmSecurityParameters, Other... } } Similarly, the ScopedPduData would be the encryptedPDU choice which would then be handed to the lower security model after uncompression. It's actually much more complex than that described above, as you have to insert something into the lower security model's EoP because of the need to auth then compress then encrypt. This would be hard to describe generically without referencing the SM in question itself. + compliant with the current SNMPv3 specifications (but causes problems in that an exact EoP is not possible to describe). + combination of M compression and N encryption algorithms possible without having to define N*M algorithms. + compression can be used with or without encryption or authentication + compression of the complete scopedPDU. - does not work with older versions of SNMP (snmpv1, snmpv2c). And: + You could even encrypt the second Security Models securityParameters if you wanted. -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA14345 for nmrg-outgoing; Fri, 9 Jul 1999 16:24:11 +0200 (MET DST) Received: from homestyle.dcn.davis.ca.us (IDENT:hardaker@homestyle.dcn.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA14336; Fri, 9 Jul 1999 16:24:05 +0200 (MET DST) Received: (from hardaker@localhost) by homestyle.dcn.davis.ca.us (8.9.3/8.9.3) id HAA27188; Fri, 9 Jul 1999 07:23:58 -0700 To: Juergen Schoenwaelder Cc: internet-drafts@ietf.org, Network Management Research Group Subject: Re: [nmrg] draft-irtf-nmrg-snmp-compression-00.txt References: <199906220858.KAA28925@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 09 Jul 1999 07:23:55 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Tue, 22 Jun 1999 10:58:12 +0200" Message-ID: Lines: 29 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta8) (Artemis) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Juergen> Compression is especially useful when retrieving large Juergen> amounts of data or when SNMP encryption is used. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The last clause in this sentence confuses me. How is compression "especially useful" when encryption is used? I don't see any benefits for encryption when compression is used. Juergen> If both compression and encryption are required, compression Juergen> MUST be applied before encryption. Well I agree that it would be less useful to perform compression first, I'm not sure that the word "MUST" is appropriate here. I think that using the lowercase version of the word would be a better choice. Juergen> 2.2. Indicating Compression in the msgFlags One important detail that is missing from this section is and how to select a compression algorithm? Certainly, this information is not stored in the flags. So it must be stored somewhere else in the packet? In there is no place to do that, unless it is stored at the beginning of the compressed data. Either way, it should be noted (even though we're not defining the definition, its a designing point). -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA13924 for nmrg-outgoing; Fri, 9 Jul 1999 16:13:41 +0200 (MET DST) Received: from homestyle.dcn.davis.ca.us (IDENT:hardaker@homestyle.dcn.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA13914; Fri, 9 Jul 1999 16:13:36 +0200 (MET DST) Received: (from hardaker@localhost) by homestyle.dcn.davis.ca.us (8.9.3/8.9.3) id HAA27134; Fri, 9 Jul 1999 07:13:34 -0700 To: Juergen Schoenwaelder Cc: wjhardaker@ucdavis.edu, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview) References: <199906111513.RAA29887@henkell.ibr.cs.tu-bs.de> <199907090953.LAA16575@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 09 Jul 1999 07:13:30 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Fri, 9 Jul 1999 11:53:29 +0200" Message-ID: Lines: 31 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta8) (Artemis) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On Fri, 9 Jul 1999 11:53:29 +0200, Juergen Schoenwaelder said: Juergen> Aiko, Jean-Philippe and I have had heated discussion about this in Juergen> Boston and I understand your point. However, even UCD SNMP defines Juergen> #define PACKET_LENGTH 8000 I would comment that this is a recent definition. Previously to the version 3.6 we were using CMU's original definition which was somewhere near 1500 bytes. Juergen> (taken from the 3.6.2 distribution) and that is not too far away from Juergen> 8192. My point was that even though I would be willing to implement it, I don't like mandating this choice to everybody else. I could see someone in a very small box not wanting to use such a large value. Juergen> Since I am not that much interested to start this discussion Juergen> again, I suggest to keep 8192 until we receive serious Juergen> complaints from people who really can't implement 8k buffer Juergen> and who believe that they need to support SNMP over Juergen> TCP. (BTW, my scotty code currently uses 2k buffers and I Juergen> have to increase them as well.) I assume this is the decision that came out of the last heated debate? -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA13772 for nmrg-outgoing; Fri, 9 Jul 1999 16:10:14 +0200 (MET DST) Received: from homestyle.dcn.davis.ca.us (IDENT:hardaker@homestyle.dcn.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA13764 for ; Fri, 9 Jul 1999 16:10:03 +0200 (MET DST) Received: (from hardaker@localhost) by homestyle.dcn.davis.ca.us (8.9.3/8.9.3) id HAA27108; Fri, 9 Jul 1999 07:09:11 -0700 To: Aiko Pras Cc: "nmrg@ibr.cs.tu-bs.de" , Wes Hardaker Subject: [nmrg] Re: Closing connections - II References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> <3785FCA2.842DDB36@ctit.utwente.nl> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 09 Jul 1999 07:09:07 -0700 In-Reply-To: Aiko Pras's message of "Fri, 09 Jul 1999 15:44:02 +0200" Message-ID: Lines: 30 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta8) (Artemis) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On Fri, 09 Jul 1999 15:44:02 +0200, Aiko Pras said: Aiko> First I believe you are right that it may be unclear what the agent Aiko> should do when it finds, while performing a SET, that the underlying Aiko> connection gets closed. The agent may decide: Aiko> 1) to go on, but `forget' those parts of the SNMP protocol that Aiko> specify that the agent should send a RESPONSE. Aiko> 2) to stop processing the SET We should probably write down what Aiko> kind of agent behaviour we want. My vote would be to propose something that matched the other protocol's usage as closely as possible. Therefore, I would suggest that we mandate that an agent MUST finish processing all requests received over a socket even if it has already been closed. However, on the other hand, this is not really necessary for get and getnext requests (information gathering). It's really only necessary for set and trap/inform requests (information modifications). Actually, because an agent might have to include a counter indicating the number of get requests it has received, it may indeed need to process a information gathering request. Does anyone know of a mib node whose definition defines that it should change values upon retrieval of its current value? I wouldn't be surprised if something like this existed somewhere. -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA13209 for nmrg-outgoing; Fri, 9 Jul 1999 15:59:16 +0200 (MET DST) Received: from solaris.tecsiel.it ([195.103.245.71]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA13199 for ; Fri, 9 Jul 1999 15:59:13 +0200 (MET DST) Received: from tecsiel.it (solaris [193.43.104.7]) by solaris.tecsiel.it (8.9.1b+Sun/8.9.1) with ESMTP id PAA01283; Fri, 9 Jul 1999 15:57:26 +0200 (MET DST) Message-ID: <3785FFC6.CC53DD1E@tecsiel.it> Date: Fri, 09 Jul 1999 15:57:26 +0200 From: Luca Deri Reply-To: l.deri@tecsiel.it Organization: Finsiel S.p.A. X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Aiko Pras CC: "nmrg@ibr.cs.tu-bs.de" , Wes Hardaker Subject: Re: [nmrg] Re: Closing connections - II References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> <3785FCA2.842DDB36@ctit.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi all, > > However, the sentence that I think will cause the most problems is > > "SNMP engines should not process any outstanding requests if the > > underlying has closed." This is the sentence that I think is > > wrong. The one case where I see this causing a really large problem is > > when an agent is in the middle of processing a set and the agent > > notices that the TCP connection has been closed, and never performs > > the function of the set. This would be a change in behavior from how I agree. > First I believe you are right that it may be unclear what the agent > should do when it finds, while performing a SET, that the underlying > connection gets closed. The agent may decide: > 1) to go on, but `forget' those parts of the SNMP protocol that > specify that the agent should send a RESPONSE. > 2) to stop processing the SET > We should probably write down what kind of agent behaviour we want. I agree too. IMHO, you should define some sort of agent behaviour without being too strict. I could have a SNMP agent that's anynchronous: - a thread receives nw requests and returns responses - another thread dequeues requets and queues responses that will be handled by the first thread In this case SET-rollback/cancel or SET-stop might be difficult. So my suggestion is: - incomplete requests (i.e. the connection has been closed while receiving a PDU) are not (obviously) processed - valid requests are processed regardless of the link state. At worst, the response/error is not returned to the manager. Cheers, Luca. -- Luca Deri Finsiel S.p.A. Via Matteucci 34/B 56124 Pisa, Italy. Ph. +39/050/968.639 Fax. +39/050/968.626 Email: l.deri@tecsiel.it WWW: http://www.tlcpi.finsiel.it/~deri/ Software is about stuff, about getting hands dirty - Jim Coplien Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA12282 for nmrg-outgoing; Fri, 9 Jul 1999 15:44:55 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA12272 for ; Fri, 9 Jul 1999 15:44:54 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.16.21]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with ESMTP id PAA11585; Fri, 9 Jul 1999 15:44:52 +0200 (MET DST) Message-ID: <3785FCA9.D80C5F3F@ctit.utwente.nl> Date: Fri, 09 Jul 1999 15:44:09 +0200 From: Aiko Pras X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de, Wes Hardaker CC: Aiko Pras Subject: [nmrg] Re: Closing connections - I References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi all Wes Hardaker wrote: > I think I agree with Harald's points. You still need to understand and > be able to control the layer below you. The advantage of the layering > scheme is that you don't have to understand all of these layers. Only > the ones directly below you. I do think we need to more carefully > consider exactly how SNMP interacts with the TCP layer below it. My first reaction was that we shouldn't go into the details of the TCP protocol. However, after thinking about this for a while, I realised that I was probably to much influenced by my old OSI background, where we didn't need to map on the underlying protocol, since we had a service for that purpose (the socket interface can be seen as the implementation of one end of the service). My current feeling is: a) the socket interface should probably not be regarded as the general abstraction of the TCP protocol layer, since there may be other ways to access TCP) b) in theory we should specify how we map on the underlying layer. Since we do not have a nice service specification, we should map on the underlying protocol. To get a better feeling on this issue, I decided to take a look at the specification of other protocols on top of TCP to check how they specify the mapping on TCP. I took a look at HTTP1.0 and 1.1 (RFC1945 & 2616), and found that they DIDN'T specify the mapping on the underlying TCP packets. If they don't, we should we? You see, I'm still not sure what we should do Bye Aiko Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA12256 for nmrg-outgoing; Fri, 9 Jul 1999 15:44:49 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA12251 for ; Fri, 9 Jul 1999 15:44:48 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.16.21]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with ESMTP id PAA11582; Fri, 9 Jul 1999 15:44:46 +0200 (MET DST) Message-ID: <3785FCA2.842DDB36@ctit.utwente.nl> Date: Fri, 09 Jul 1999 15:44:02 +0200 From: Aiko Pras X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "nmrg@ibr.cs.tu-bs.de" , Wes Hardaker CC: Aiko Pras Subject: [nmrg] Re: Closing connections - II References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Wes Hardaker wrote: > However, the sentence that I think will cause the most problems is > "SNMP engines should not process any outstanding requests if the > underlying has closed." This is the sentence that I think is > wrong. The one case where I see this causing a really large problem is > when an agent is in the middle of processing a set and the agent > notices that the TCP connection has been closed, and never performs > the function of the set. This would be a change in behavior from how > sets are performed now. Specifically, a manager can issue a set > without waiting for the response. While this is unwise, it can happen > in practice. It is still expected that the agent will have completed > the set. The case you mention is interesting; there are several aspects we can discuss. First I believe you are right that it may be unclear what the agent should do when it finds, while performing a SET, that the underlying connection gets closed. The agent may decide: 1) to go on, but `forget' those parts of the SNMP protocol that specify that the agent should send a RESPONSE. 2) to stop processing the SET We should probably write down what kind of agent behaviour we want. The second aspect relates to the manager behaviour after receiving the SET RESPONSE. To my knowledge, after processing the response, the manager is free to do whatever he likes. In fact he may ignore the response (although this may not in general be wise). If this is already possible with the current SNMP, why shouldn't we allow managers to close the connection immediately after sending the SET? Aiko Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA25926 for nmrg-outgoing; Fri, 9 Jul 1999 11:53:49 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA25912; Fri, 9 Jul 1999 11:53:29 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA16575; Fri, 9 Jul 1999 11:53:29 +0200 Date: Fri, 9 Jul 1999 11:53:29 +0200 Message-Id: <199907090953.LAA16575@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wjhardaker@ucdavis.edu CC: nmrg@ibr.cs.tu-bs.de In-reply-to: (message from Wes Hardaker on 08 Jul 1999 22:04:40 -0700) Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview) References: <199906111513.RAA29887@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Wes Hardaker writes: Wes> That having been said, but I think it would be nice to allow an Wes> entity to provide service for SNMP over TCP without changing the Wes> underlying nature of its implementation, which includes its Wes> buffer sizes. Granted, they will not reap the best of the Wes> benefits from utilizing TCP, but should we force them to use this Wes> larger packet size? Aiko, Jean-Philippe and I have had heated discussion about this in Boston and I understand your point. However, even UCD SNMP defines #define PACKET_LENGTH 8000 (taken from the 3.6.2 distribution) and that is not too far away from 8192. ;-) Since I am not that much interested to start this discussion again, I suggest to keep 8192 until we receive serious complaints from people who really can't implement 8k buffer and who believe that they need to support SNMP over TCP. (BTW, my scotty code currently uses 2k buffers and I have to increase them as well.) Juergen -- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id HAA04022 for nmrg-outgoing; Fri, 9 Jul 1999 07:04:50 +0200 (MET DST) Received: from homestyle.dcn.davis.ca.us (IDENT:hardaker@homestyle.dcn.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id HAA04011; Fri, 9 Jul 1999 07:04:47 +0200 (MET DST) Received: (from hardaker@localhost) by homestyle.dcn.davis.ca.us (8.9.3/8.9.3) id WAA24395; Thu, 8 Jul 1999 22:04:44 -0700 To: Juergen Schoenwaelder Cc: Network Management Research Group Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview) References: <199906111513.RAA29887@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 08 Jul 1999 22:04:40 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Fri, 11 Jun 1999 17:13:22 +0200" Message-ID: Lines: 19 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta8) (Artemis) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Juergen> When an SNMP entity uses the TCP transport mapping, it MUST be Juergen> capable of accepting messages that are at least 8192 octets in size. Juergen> Implementation of larger values is encouraged whenever possible. I really don't like imposing this limit upon an implementation. I think, however, this has been discussed here already and I may have missed the discussion. I'm sorry if that is the case. That having been said, but I think it would be nice to allow an entity to provide service for SNMP over TCP without changing the underlying nature of its implementation, which includes its buffer sizes. Granted, they will not reap the best of the benefits from utilizing TCP, but should we force them to use this larger packet size? -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id HAA03810 for nmrg-outgoing; Fri, 9 Jul 1999 07:00:58 +0200 (MET DST) Received: from homestyle.dcn.davis.ca.us (IDENT:hardaker@homestyle.dcn.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id HAA03801; Fri, 9 Jul 1999 07:00:55 +0200 (MET DST) Received: (from hardaker@localhost) by homestyle.dcn.davis.ca.us (8.9.3/8.9.3) id WAA24329; Thu, 8 Jul 1999 22:00:51 -0700 To: Juergen Schoenwaelder Cc: Harald@Alvestrand.no, nmrg@ibr.cs.tu-bs.de Subject: Re: Closing connections (Re: [nmrg] draft-irtf-nmrg-snmp-tcp-01.txt (preview)) References: <4.2.0.56.19990615162646.00bce9d0@dokka.maxware.no> <199906161515.RAA23654@henkell.ibr.cs.tu-bs.de> X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: U.C.Davis, Information Technology - D.C.A.S. X-URL: http://dcas.ucdavis.edu/~hardaker From: Wes Hardaker Date: 08 Jul 1999 22:00:49 -0700 In-Reply-To: Juergen Schoenwaelder's message of "Wed, 16 Jun 1999 17:15:40 +0200" Message-ID: Lines: 37 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta8) (Artemis) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On Wed, 16 Jun 1999 17:15:40 +0200, Juergen Schoenwaelder said: Harald> I'm a bit worried about the apparent simplicity of the Harald> paragraphs on closing connections: Juergen> There are some interesting points. However, I do not think we Juergen> have to deal with them. I expect that the average Juergen> SNMP-over-TCP implementation will be using TCP Juergen> sockets. Hence, the internal state of the TCP protocol engine Juergen> is to a large extend invisible. And I think this perfectly Juergen> reflects reasonable layering. Let me start off by saying that I am sorry I am responding to these notes so late. At least, I'm finally getting to them. I think I agree with Harald's points. You still need to understand and be able to control the layer below you. The advantage of the layering scheme is that you don't have to understand all of these layers. Only the ones directly below you. I do think we need to more carefully consider exactly how SNMP interacts with the TCP layer below it. However, the sentence that I think will cause the most problems is "SNMP engines should not process any outstanding requests if the underlying has closed." This is the sentence that I think is wrong. The one case where I see this causing a really large problem is when an agent is in the middle of processing a set and the agent notices that the TCP connection has been closed, and never performs the function of the set. This would be a change in behavior from how sets are performed now. Specifically, a manager can issue a set without waiting for the response. While this is unwise, it can happen in practice. It is still expected that the agent will have completed the set. -- Wes Hardaker Distributed Computing Analysis and Support University of California at Davis Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA06002 for nmrg-outgoing; Thu, 8 Jul 1999 17:31:41 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA05995; Thu, 8 Jul 1999 17:31:35 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA16076; Thu, 8 Jul 1999 17:31:35 +0200 Date: Thu, 8 Jul 1999 17:31:35 +0200 Message-Id: <199907081531.RAA16076@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: sprenkel@cs.utwente.nl CC: nmrg@ibr.cs.tu-bs.de, helthuis@cs.utwente.nl In-reply-to: <3784BBC5.C4B2B3C0@cs.utwente.nl> (message from Ron Sprenkels on Thu, 08 Jul 1999 16:55:01 +0200) Subject: Re: [nmrg] Work on another implementation of SNMP over TCP References: <3784BBC5.C4B2B3C0@cs.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Ron Sprenkels writes: [...] Ron> Juergen, is your SNMP over TCP agent on 134.169.34.127 port 161 Ron> still running? We did a telnet to it, but got no response. If it Ron> is not, is it possible for you to start it again? I can't find it anymore at the moment. It might take a while until I have something running again. Juergen Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA04200 for nmrg-outgoing; Thu, 8 Jul 1999 16:55:06 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA04194 for ; Thu, 8 Jul 1999 16:55:04 +0200 (MET DST) Received: from myrtilos.cs.utwente.nl (myrtilos.cs.utwente.nl [130.89.16.9]) by utrhcs.cs.utwente.nl (8.9.1/8.9.1) with SMTP id QAA25931 for ; Thu, 8 Jul 1999 16:55:02 +0200 (MET DST) Received: from cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id QAA14705; Thu, 8 Jul 1999 16:55:02 +0200 Message-ID: <3784BBC5.C4B2B3C0@cs.utwente.nl> Date: Thu, 08 Jul 1999 16:55:01 +0200 From: Ron Sprenkels Organization: University of Twente X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Network Management Research Group CC: Bert Helthuis Subject: [nmrg] Work on another implementation of SNMP over TCP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi everybody, Our management group here in twente has recently been extended with a technician, Bert Helthuis. He is working on an implementation of draft-irtf-nmrg-snmp-tcp-00.txt, and is in a stage where he could test against a TCP capable agent. Juergen, is your SNMP over TCP agent on 134.169.34.127 port 161 still running? We did a telnet to it, but got no response. If it is not, is it possible for you to start it again? thanks, Ron. -------------------------------------------------------------------------- Ron Sprenkels sprenkel@cs.utwente.nl http://www.cs.utwente.nl/~sprenkel University of Twente, Department of Computer Science, TSS Management group P.O. Box 217, 7500 AE Enschede, The Netherlands. (Tel. +31 53 489 4663)