Subject: Re: [nmrg] 12th nmrg meeting details
From: Phil Shafer <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Date: Fri, 28 Feb 2003 13:17:50 -0500
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Juergen Schoenwaelder writes:
>Let me know what is missing or needs corrections. Looking forward to
>see you folks in Colorado,

I'm plannning on attended, but have one question. How late will the
meeting run on the 23rd? I'm trying to figure out flights back home.

Thanks,
 Phil

Date: Fri, 28 Feb 2003 16:04:30 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] 12th nmrg meeting details
Sender: [email-masked]

The 12th NMRG meeting in Colorado Springs will be hosted by Intelliden
(many thanks to John Strassner for his help). We will meet on Saturday
afternoon and on Sunday (whole day). There will also be a BOF at IM
2003 with the intention to communicate more with IM 2003 participants
that might be interested or convinced to join the NMRG. ;-)

I have created a web page for this meeting which as additional
information such as the hotel information and an initial agenda. I
have already booked a room in the Adam's Mark hotel where I will stay
over the weekend before I move to the Broadmoor on Monday.

https://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2003/colorado/

Let me know what is missing or needs corrections. Looking forward to
see you folks in Colorado,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Thu, 27 Feb 2003 11:29:20 -0500
From: "Dave Sidor" <[email-masked]>
Organization: Nortel Networks
To: Juergen Schoenwaelder <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Network Management Research Group <[email-masked]>, "*List, Q 18/4" <[email-masked]>
Subject: [nmrg] Re: SG 4 re RFC 3430
Sender: [email-masked]

Juergen,

Thanks for your comments. In response I offer 2 points:

- First a minor point: I have removed 2 addresses from my email (Mrs. Mc
Grath and the IETF liaison address) and added the address of the mailing
list of Q 18/4, the group responsible for this liaison and also
Q.811/Q.812.

- Second, I wish to reiterate that Lakshmi Raman, identified as SG 4
contact in the liaison, supported by Dave Matthews, the Q 18/4
rapporteur, is the SG 4 technical lead in responding to your points,
issues, and questions.

Dave

Juergen Schoenwaelder wrote:
> 
> >>>>> Dave Sidor writes:
> 
> Dave> Below and attached as a Word file is a SG 4 liaison regarding
> Dave> RFC 3430.  Please forward it to the appropriate IETF persons and
> Dave> WGs. As you suggested, I have also copied Juergen as the author
> Dave> of that RFC.
> 
> Thanks for sharing the information. I will respond to the comments
> below inline (and keep the rest of the text so that others can follow
> what is going on). Note that I have added the NMRG to the CC: list.
> 
> Dave> Based on email discussions with the Operations and Management
> Dave> Area Directors, we are incorporating a reference to RFC 3430 in
> Dave> the revision of Q.812 in progress.
> 
> Dave> In addition, at the ITU-T Study Group 4 meeting in February
> Dave> 2003, we received a contribution on the implementation
> Dave> experience of running SNMP over TCP and SNMP over UDP. This
> Dave> experience may prove useful to the IETF in its evaluation of
> Dave> RFC3430 and its potential evolution. We would appreciate if the
> Dave> IETF make a similar call for implementation report of RFC 3430
> Dave> and share the results with us.
> 
> Dave> In response to the email suggestion from one of the Area
> Dave> Directors, we offer the following summary of one implementation
> Dave> experience. In the event the IETF does offer an official call at
> Dave> a later date, we would be pleased to provide any additional
> Dave> information required.
> 
> Dave> In general, we would be grateful if you would keep us informed
> Dave> of your progress on this topic.
> 
> Dave> Implementation Experience --------------------------
> 
> Dave> MII/BUPT TMN R&D Center (Beijing, China) has developed an SNMP
> Dave> (v2) over TCP implementation. The combined SNMP over TCP/UDP
> Dave> approach provided in this work is still under development.
> 
> Dave> Workstations: one SNMP manager runs on a Sun Sparc Ultra2 WS,
> Dave> one SNMP agent runs on a Sun Sparc Ultra1 WS.  Operation System:
> Dave> Sun Solaris 2.6 (Unix) Software platforms: some parts of
> Dave> SNMP(v2) PDU APIs are based on SNMP++, while the transport
> Dave> protocol control module, and the SNMP agent and manager toolkit
> Dave> are developed by MII/BUPT.  The max SNMP message over UDP is
> Dave> allowed: 4096 Bytes The max SNMP message over TCP that is sent
> Dave> during test: 64K Bytes
> 
> Dave> Network environment: The SNMP manager and the SNMP agent are
> Dave> located in separate workstations in different Ethernet LANs,
> Dave> which are connected via a radio network bridge. Both the manager
> Dave> and the agent are simulators, and no real network devices are
> Dave> actually managed by the manager or the agent during the
> Dave> experiments.
> 
> Dave> MII/BUPT have compared the transfer efficiency for SNMP over TCP
> Dave> and SNMP over UDP. MII/BUPT captured all the packets between
> Dave> these two SNMP entities, and calculated the transfer efficiency
> Dave> for different sizes of SNMP messages to be transferred over the
> Dave> two different transport protocols. When no packet is lost, and
> Dave> the amount of data to be transferred is less than 64K, the SNMP
> Dave> over UDP is more efficient.  Otherwise TCP is more
> Dave> efficient. Details can be provided if desired.
> 
> It looks like they measured efficiency of individual messages, which
> is to some extend missing the point. SNMP over TCP allows to
> 
> (a) stream flows of SNMP messages while taking advantage of TCP's flow
>     control and congestion avoidance mechanisms
> 
> (b) significantly reduce the number of request/response interactions
>     due to larger message sizes without causing fragmentation
>     (assuming TCP does proper MTU path discovery, which most
>     implementations do these days)
> 
> So in order to measure the benefits, it is crucial to look at larger
> transactions such as the complete retrieval of a potentially large
> table. Note that there was a paper at a previous IM or NOMS which
> showed some measured numbers (although the intention of the paper was
> to look at SNMP over TLS over TCP efficiency compared to other
> security approaches.
> 
> Dave> Deltas from RFC3430 -------------------
> 
> Dave> The main part of the research is similar to what has been
> Dave> described in RFC 3430. But there are still some differences that
> Dave> may need consideration.
> 
> Dave> 1) It was noticed that RFC 3430 does not provide a default
> Dave> policy for closing a TCP connection. One proposal for the
> Dave> default behaviour is that:
> 
> Dave> The SNMP engine maintains a predefined number of TCP connections
> Dave> even if some of the connections have not been used for a period
> Dave> of time. The normal trigger point to close a connection is when
> Dave> a new connection establishment is requested, but no free
> Dave> resource is available for this connection. LRU(Least Recent
> Dave> Usage) is considered as the rule for closing inactive TCP
> Dave> connections. This proposal is also to avoid the extra costs for
> Dave> connection establishment.
> 
> While the described strategy makes sense in some environments, I do
> not think it is wise to require such an implementation strategy. I can
> very well consider situations where other factors might be strong
> reasons to close TCP connections at other points in time.
> 
> Dave> 2) A combined SNMP over TCP/UDP schema is proposed in the
> Dave> research. This requires that SNMP engine provides both SNMP over
> Dave> TCP and UDP implementations at the same time, and RFC 3430 also
> Dave> indicates this. The default policy used is for the originator to
> Dave> choose transport according to the size of the SNMP message. For
> Dave> both efficiency and convenience considerations, when an SNMP
> Dave> message is larger than a predefined size, then the SNMP engine
> Dave> chooses TCP as the transport protocol, otherwise it chooses
> Dave> UDP. (The predefined size is 4096 in the experiment, which is
> Dave> the max size allowed over UDP in the experiment, but this value
> Dave> may be adjusted.) This proposal tries to make use of the
> Dave> benefits of TCP and UDP in different situations.
> 
> If you look at getbulk, then the manager often does not know what the
> size of the response will be. Again, I believe that the transport
> selection must be controlled by the application since only the
> application understands the trade-offs. I personally would not
> implement an automatic transport selection scheme.
> 
> Dave> 3) The minimum for the size of an SNMP message over TCP defined
> Dave> in RFC 3430 seems relatively small. It is suggested that the
> Dave> SNMP over TCP engine should support the size of at least 64K or
> Dave> 32K bytes. The larger the size of an SNMP message is, the more
> Dave> benefit SNMP over TCP may provide.
> 
> RFC 3430 requires that every engine supports 8K and encourages engines
> to support bigger message sizes. I believe this basically OK and with
> SNMPv3, you have the fields in the messages to communicate the size
> limitations to peers. The trade-off is that you need to have a buffer
> for each TCP endpoint supported by an engine. Increasing the minimum
> required size to say 64K implies that you need to have 640K buffer
> space to support TCP concurrent connections, which might be hard in
> some environments. I guess that in memory constraint environments,
> implementations might actually adjust buffer sizes based on the number
> of open connections (and this might lead to reasons to close idle
> connections, which brings us nicely back to the comments above).
> 
> /js
> 
> --
> Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Thu, 27 Feb 2003 13:43:50 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Network Management Research Group <[email-masked]>
Subject: [nmrg] Re: SG 4 re RFC 3430
Sender: [email-masked]

>>>>> Dave Sidor writes:

Dave> Below and attached as a Word file is a SG 4 liaison regarding
Dave> RFC 3430.  Please forward it to the appropriate IETF persons and
Dave> WGs. As you suggested, I have also copied Juergen as the author
Dave> of that RFC.

Thanks for sharing the information. I will respond to the comments
below inline (and keep the rest of the text so that others can follow
what is going on). Note that I have added the NMRG to the CC: list.

Dave> Based on email discussions with the Operations and Management
Dave> Area Directors, we are incorporating a reference to RFC 3430 in
Dave> the revision of Q.812 in progress.

Dave> In addition, at the ITU-T Study Group 4 meeting in February
Dave> 2003, we received a contribution on the implementation
Dave> experience of running SNMP over TCP and SNMP over UDP. This
Dave> experience may prove useful to the IETF in its evaluation of
Dave> RFC3430 and its potential evolution. We would appreciate if the
Dave> IETF make a similar call for implementation report of RFC 3430
Dave> and share the results with us.

Dave> In response to the email suggestion from one of the Area
Dave> Directors, we offer the following summary of one implementation
Dave> experience. In the event the IETF does offer an official call at
Dave> a later date, we would be pleased to provide any additional
Dave> information required.

Dave> In general, we would be grateful if you would keep us informed
Dave> of your progress on this topic.

Dave> Implementation Experience --------------------------

Dave> MII/BUPT TMN R&D Center (Beijing, China) has developed an SNMP
Dave> (v2) over TCP implementation. The combined SNMP over TCP/UDP
Dave> approach provided in this work is still under development.

Dave> Workstations: one SNMP manager runs on a Sun Sparc Ultra2 WS,
Dave> one SNMP agent runs on a Sun Sparc Ultra1 WS.  Operation System:
Dave> Sun Solaris 2.6 (Unix) Software platforms: some parts of
Dave> SNMP(v2) PDU APIs are based on SNMP++, while the transport
Dave> protocol control module, and the SNMP agent and manager toolkit
Dave> are developed by MII/BUPT.  The max SNMP message over UDP is
Dave> allowed: 4096 Bytes The max SNMP message over TCP that is sent
Dave> during test: 64K Bytes

Dave> Network environment: The SNMP manager and the SNMP agent are
Dave> located in separate workstations in different Ethernet LANs,
Dave> which are connected via a radio network bridge. Both the manager
Dave> and the agent are simulators, and no real network devices are
Dave> actually managed by the manager or the agent during the
Dave> experiments.

Dave> MII/BUPT have compared the transfer efficiency for SNMP over TCP
Dave> and SNMP over UDP. MII/BUPT captured all the packets between
Dave> these two SNMP entities, and calculated the transfer efficiency
Dave> for different sizes of SNMP messages to be transferred over the
Dave> two different transport protocols. When no packet is lost, and
Dave> the amount of data to be transferred is less than 64K, the SNMP
Dave> over UDP is more efficient.  Otherwise TCP is more
Dave> efficient. Details can be provided if desired.

It looks like they measured efficiency of individual messages, which
is to some extend missing the point. SNMP over TCP allows to 
   
(a) stream flows of SNMP messages while taking advantage of TCP's flow
    control and congestion avoidance mechanisms

(b) significantly reduce the number of request/response interactions
    due to larger message sizes without causing fragmentation
    (assuming TCP does proper MTU path discovery, which most
    implementations do these days)

So in order to measure the benefits, it is crucial to look at larger
transactions such as the complete retrieval of a potentially large
table. Note that there was a paper at a previous IM or NOMS which
showed some measured numbers (although the intention of the paper was
to look at SNMP over TLS over TCP efficiency compared to other
security approaches.

Dave> Deltas from RFC3430 -------------------

Dave> The main part of the research is similar to what has been
Dave> described in RFC 3430. But there are still some differences that
Dave> may need consideration.

Dave> 1) It was noticed that RFC 3430 does not provide a default
Dave> policy for closing a TCP connection. One proposal for the
Dave> default behaviour is that:

Dave> The SNMP engine maintains a predefined number of TCP connections
Dave> even if some of the connections have not been used for a period
Dave> of time. The normal trigger point to close a connection is when
Dave> a new connection establishment is requested, but no free
Dave> resource is available for this connection. LRU(Least Recent
Dave> Usage) is considered as the rule for closing inactive TCP
Dave> connections. This proposal is also to avoid the extra costs for
Dave> connection establishment.

While the described strategy makes sense in some environments, I do
not think it is wise to require such an implementation strategy. I can
very well consider situations where other factors might be strong
reasons to close TCP connections at other points in time.

Dave> 2) A combined SNMP over TCP/UDP schema is proposed in the
Dave> research. This requires that SNMP engine provides both SNMP over
Dave> TCP and UDP implementations at the same time, and RFC 3430 also
Dave> indicates this. The default policy used is for the originator to
Dave> choose transport according to the size of the SNMP message. For
Dave> both efficiency and convenience considerations, when an SNMP
Dave> message is larger than a predefined size, then the SNMP engine
Dave> chooses TCP as the transport protocol, otherwise it chooses
Dave> UDP. (The predefined size is 4096 in the experiment, which is
Dave> the max size allowed over UDP in the experiment, but this value
Dave> may be adjusted.) This proposal tries to make use of the
Dave> benefits of TCP and UDP in different situations.

If you look at getbulk, then the manager often does not know what the
size of the response will be. Again, I believe that the transport
selection must be controlled by the application since only the
application understands the trade-offs. I personally would not
implement an automatic transport selection scheme.

Dave> 3) The minimum for the size of an SNMP message over TCP defined
Dave> in RFC 3430 seems relatively small. It is suggested that the
Dave> SNMP over TCP engine should support the size of at least 64K or
Dave> 32K bytes. The larger the size of an SNMP message is, the more
Dave> benefit SNMP over TCP may provide.

RFC 3430 requires that every engine supports 8K and encourages engines
to support bigger message sizes. I believe this basically OK and with
SNMPv3, you have the fields in the messages to communicate the size
limitations to peers. The trade-off is that you need to have a buffer
for each TCP endpoint supported by an engine. Increasing the minimum
required size to say 64K implies that you need to have 640K buffer
space to support TCP concurrent connections, which might be hard in
some environments. I guess that in memory constraint environments,
implementations might actually adjust buffer sizes based on the number
of open connections (and this might lead to reasons to close idle
connections, which brings us nicely back to the comments above).

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 25 Feb 2003 19:15:07 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] please check out draft-iab-research-funding-00.txt
Sender: [email-masked]

The IAB just posted a document which I think deserves some attention:

:         Title           : IAB Concerns & Recommendations Regarding
:		            Internet Research & Evolution
:         Author(s)       : R. Atkinson, S. Floyd
:         Filename        : draft-iab-research-funding-00.txt,.ps
:         Pages           : 20
:         Date            : 2003-2-20
: 
: This document discusses IAB concerns that ongoing research is needed
: to further the evolution of the Internet infrastructure, and that
: consistent, sufficient non-commercial funding is needed to enable
: 
: http://www.ietf.org/internet-drafts/draft-iab-research-funding-00.txt

Please send comments either to this list or directly to the IAB.
Perhaps we might also want to suggest specific changes/additions
regarding the network management portions of the document.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Mon, 17 Feb 2003 10:13:52 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Margaret Wasserman <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] XMLCONF Proposal
Sender: [email-masked]

Hi All,

We have a proposal available for a new configuration protocol
that may be of interest to folks on these lists.  The proposal
has been published an an I-D, and can be found at:

http://www.ietf.org/internet-drafts/draft-enns-xmlconf-spec-00.txt

We believe that this proposal addresses many of the operator
and vendor requirements for a configuration protocol that have
been gathered and analyzed over the past couple of years.

We will be requesting a BOF to discuss this proposal in San
Francisco, but before a BOF can be scheduled, we will need to
demonstrate sufficient community interest in this proposal.

So, if you believe that this proposal warrants further work
within the IETF, please send your feedback ASAP to
[email-masked].

Please DO NOT cross-post replies to all of the groups cc:ed
on this message.

Thanks,
Margaret