Subject: [NSIS] NSIS for end users - It's reality

From: "Christian Dickmann" <[email-masked]>
Date: Thu, 28 Sep 2006 13:14:43 +0200

Hi,

the NSIS team of the University of Goettingen is proud to announce the
release of a new development version of our NSIS package, which offers a
lot of new features. We now support Traffic Control (tc) on Linux to
really reserve resources and allow the integration of NSIS/QoS into
applications by offering a QoS NSLP API. This development version also
comes with a lot of bugfixes and updates to new draft versions of GIST
and QoS NSLP. 

However, the most exciting new feature is the support for Windows XP and
OpenWRT[1]!

The Windows XP version is a demonstration prototype, which is able to
detect the UDP port used by Skype[2] and trigger the local QoS NSLP
daemon to request resources for phone calls.

In addition, we support OpenWRT, which is a Linux distribution for
embedded devices, i.e. broadband Wireless LAN / DSL routers. On a lot of
such routers, like the Linksys WRT54G (see the OpenWRT homepage[1] for a
list of supported hardware), OpenWRT can be installed as an alternative
firmware.

All new features combined, NSIS usage in SOHO networks becomes reality! 

The Windows machine triggers the request and the DSL router reserves the
resources by the use of the Traffic Control tool.

You can find the development versions for all platforms of the NSIS
package on our beta version page. The ChangeLog which lists all changes
is also available on that page. Please see the individual README files
on how to use the packages.

http://user.informatik.uni-goettingen.de/~nsis/beta.html

We encourage anyone to try this development version and appreciate
feedback of any kind, such as installation/setup experience, bug
reports, feature requests, etc.

Christian Dickmann

On behalf of University of Goettingen NSIS team

[1] OpenWRT: http://www.openwrt.org

[2] Skype: http://www.skype.com

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>

DFrom [email-masked] Sat Sep 30 04:56:59 2006
From: Martin Stiemerling <[email-masked]>
Subject: Re: [NSIS] Responses to TRACE messages
Date: Fri, 29 Sep 2006 18:24:56 +0200
To: =?ISO-8859-1?Q?Rui_Vil=E3o?= <[email-masked]>
Cc: [email-masked]

Hi Rui,

The cited text "RESPONSE messages are responses to CREATE and REA =20
messages." has not been adapted to fit also the TRACE response case. =20
It must read

"RESPONSE messages are responses to CREATE, REA, and TRACE messages."

As Hannes has said, we are going to update the section in the new =20
revision of the draft.

Thanks

   Martin

Am 28.08.2006 um 19:37 schrieb Rui Vil=E3o:

> Hi all,
>
> I'm having doubts when generating a RESPONSE to TRACE messages. In =20
> section 3.7.6 we can find several times that we have to send a =20
> RESPONSE message, but when we read section 4.3.3, we can find =20
> "RESPONSE messages are responses to CREATE and REA messages.". So =20
> what to do when processing a TRACE message?
>
> Best regards,
>
> Rui Vil=E3o
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 29 Sep 2006 18:22:08 +0200

All NSIS-team@Goettingen,

Congrats for the good work!

   Martin

Am 28.09.2006 um 13:14 schrieb Christian Dickmann:

> Hi,
>
>
>
> the NSIS team of the University of Goettingen is proud to announce  
> the release of a new development version of our NSIS package, which  
> offers a lot of new features. We now support Traffic Control (tc)  
> on Linux to really reserve resources and allow the integration of  
> NSIS/QoS into applications by offering a QoS NSLP API. This  
> development version also comes with a lot of bugfixes and updates  
> to new draft versions of GIST and QoS NSLP.
>
>
>
> However, the most exciting new feature is the support for Windows  
> XP and OpenWRT[1]!
>
>
>
> The Windows XP version is a demonstration prototype, which is able  
> to detect the UDP port used by Skype[2] and trigger the local QoS  
> NSLP daemon to request resources for phone calls.
>
> embedded devices, i.e. broadband Wireless LAN / DSL routers. On a  
> lot of such routers, like the Linksys WRT54G (see the OpenWRT  
> homepage[1] for a list of supported hardware), OpenWRT can be  
> installed as an alternative firmware.
>
>
>
> The Windows machine triggers the request and the DSL router  
> reserves the resources by the use of the Traffic Control tool.
>
>
>
> package on our beta version page. The ChangeLog which lists all  
> changes is also available on that page. Please see the individual  
> README files on how to use the packages.
>
>
>
> Nsis_Imp mailing list
> [email-masked]
> https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp

ate: Fri, 29 Sep 2006 18:22:08 +0200
To: Christian Dickmann <[email-masked]>
Cc: [email-masked], [email-masked],
	[email-masked]
Subject: [NSIS] Re: [Nsis_imp] NSIS for end users - It's reality

All NSIS-team@Goettingen,

Congrats for the good work!

   Martin

Am 28.09.2006 um 13:14 schrieb Christian Dickmann:

> Hi,
>
>
>
> the NSIS team of the University of Goettingen is proud to announce  
> the release of a new development version of our NSIS package, which  
> offers a lot of new features. We now support Traffic Control (tc)  
> on Linux to really reserve resources and allow the integration of  
> NSIS/QoS into applications by offering a QoS NSLP API. This  
> development version also comes with a lot of bugfixes and updates  
> to new draft versions of GIST and QoS NSLP.
>
>
>
> However, the most exciting new feature is the support for Windows  
> XP and OpenWRT[1]!
>
>
>
> The Windows XP version is a demonstration prototype, which is able  
> to detect the UDP port used by Skype[2] and trigger the local QoS  
> NSLP daemon to request resources for phone calls.
>
> embedded devices, i.e. broadband Wireless LAN / DSL routers. On a  
> lot of such routers, like the Linksys WRT54G (see the OpenWRT  
> homepage[1] for a list of supported hardware), OpenWRT can be  
> installed as an alternative firmware.
>
>
>
> The Windows machine triggers the request and the DSL router  
> reserves the resources by the use of the Traffic Control tool.
>
>
>
> package on our beta version page. The ChangeLog which lists all  
> changes is also available on that page. Please see the individual  
> README files on how to use the packages.
>
>
>
> Nsis_Imp mailing list
> [email-masked]
> https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 30 Sep 2006 10:58:14 -0500

Christian, All,
 
Congratulations on this significant accomplishment!
 
We have a question regarding QSPEC implementation.  In Section 4.3.3.1 (Reservation Failure & Error E-Flag) of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt <http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt>  we describe the dual use of the E-flag.  

We'd like your opinion and others' opinion on the NSIS implementation list RE a possible issue with the 'overloading' of the E-Flag.  As described in Section 4.3.3.1 the E-flag has a dual purpose and can mean either 'QSPEC parameter not met' or 'QSPEC parameter error'.  As described, if the E flag is set for erroneous parameters, it MUST NOT be set for parameters not met, and visa versa.  I.e., the use of the E flag is completely disjoint for the two cases.  

However, what if a QSPEC contains n parameters. The RMF parses the parameters sequentially, and the first parameter is not met and its E-Flag is raised.  The parsing continues, everything is fine.  But the nth parameter is erroneous. Its E-Flag is raised.  What we currently require is the RMF goes back to the first parameter and unsets the E-Flag.

Is this an implementation problem big enough that it would warrant an additional flag to distinguish the 2 cases?  We would prefer not to introduce another flag unless this is seen as a significant problem.

Your opinion on this would be helpful since you have already developed a prototype QSPEC implementation.

Thanks,

Jerry, Cornelia, Attila

________________________________

From: Christian Dickmann [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 7:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [NSIS] NSIS for end users - It's reality

Hi,

the NSIS team of the University of Goettingen is proud to announce the release of a new development version of our NSIS package, which offers a lot of new features. We now support Traffic Control (tc) on Linux to really reserve resources and allow the integration of NSIS/QoS into applications by offering a QoS NSLP API. This development version also comes with a lot of bugfixes and updates to new draft versions of GIST and QoS NSLP. 

However, the most exciting new feature is the support for Windows XP and OpenWRT[1]!

The Windows XP version is a demonstration prototype, which is able to detect the UDP port used by Skype[2] and trigger the local QoS NSLP daemon to request resources for phone calls.

In addition, we support OpenWRT, which is a Linux distribution for embedded devices, i.e. broadband Wireless LAN / DSL routers. On a lot of such routers, like the Linksys WRT54G (see the OpenWRT homepage[1] for a list of supported hardware), OpenWRT can be installed as an alternative firmware.

The Windows machine triggers the request and the DSL router reserves the resources by the use of the Traffic Control tool.

You can find the development versions for all platforms of the NSIS package on our beta version page. The ChangeLog which lists all changes is also available on that page. Please see the individual README files on how to use the packages.

We encourage anyone to try this development version and appreciate feedback of any kind, such as installation/setup experience, bug reports, feature requests, etc.

Christian Dickmann

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 30 Sep 2006 19:05:01 +0200

Hi Jerry and all,

:-)

I believe that this is not a big problem. Even if the RMF parses the
parameters sequentially, the whole object can be accessed any time. You
can do the manipulation on the object level or you can consider the
QSPEC as a (char-)array and the manipulation can be done on the byte-
or bit-level. And it is passed as an entire object back to the NSLP.

Bernd

Ash, Gerald R (Jerry), ALABS wrote:
> ------------------------------------------------------------------------
>