Subject: RE: [NSIS] Proposed NSIS charter

From: [email-masked]
Date: Thu, 1 Nov 2001 14:08:28 +0200

Hi Weijing,

> If it is the case that NSIS is not limited to Mobile IP,  so we could
> include signaling consideration for DSL, Ethernet on last 
> mile, etc access technology?

No.  QoS signaling should be seperate from layer 2.
> 
> To simplifying the signaling protocol, we can focus on UNI 
> function, which could be independent of NNI function. For 
> service provider point of view, we see clearly need of 
> separation of  UNI signaling and NNI signaling. Maybe
> NSIS is the right platform for UNI only signaling?

I do think we should make some seperations on different
signaling scenarios, UNI, NNI should be addressed in the inital 
documents.

best regards,
John

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 1 Nov 2001 13:31:48 +0100

Hi Jussi

Please see my comments below.

[JR} I think that we have here a very fundamental 
[JR]  question related to NSIS,
[JR]  namely:

[JR]	- Do we want to create general purpose QoS signaling?

It depends, what do you mean by general purpose signaling.
I think that it would be very interesting if we somehow 
specify a flexible QoS solution that will consist of  
different QoS protocol components.
Some of these QoS protocol components will then be used for 
QoS lightweight (simple, fast and scalable) solutions, 
and other QoS protocol components will be used for more complex QoS solutions, e.g., QoS required by the wireless link.

What I mean, is that you might probably use the same 
QoS end to end protocol, that would be transparent 
for certain IP domains, while for other IP domains it would
operate as a lightweight QoS protocol and in other domains 
it would be used as a more complex QoS protocol. This usage
is depending on the characteristics and requirements of 
the IP domains.

This QoS solution might be an extended 
existing QoS protocol.

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 1 november 2001 11:51
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Proposed NSIS charter

Hello,

I think that we have here a very fundamental question related to NSIS,
namely:

	- Do we want to create general purpose QoS signaling?

An alternative is to create specialized versions targeted for certain
interfaces, tasks, etc.

Personally, I feel that we should aim for the general purpose signaling,
since the common language between QoS systems, elements, and technologies is
exactly what we need right now. It is possible to make later optimized
versions if/when really needed. Naturally, the big challenge is to create a
general purpose QoS signaling without ending with something too big,
cumbersome and heavy.

Best Regards,
Jussi 

> -----Original Message-----
> From: ext Chen, Weijing [mailto:[email-masked]]
> Sent: 31 October, 2001 18:54
> To: ''; [email-masked];
> [email-masked]
> Subject: RE: [NSIS] Proposed NSIS charter
> 
> 
> John, Georgios,

...

> function, which
> could be independent of NNI function. For service provider 
> point of view, we
> see clearly need of separation of  UNI signaling and NNI 
> signaling. Maybe
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> [email-masked]

---

From: [email-masked]
Date: Thu, 1 Nov 2001 16:42:17 +0200

Hello Georgios,

I think that flexible/extendable QoS signaling is perfectly OK as far as
there exists some kind of lightweight, basic signaling component that can be
used in all cases as a simple, common "QoS language". 

Best Regards,
Jussi

> From: ext Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 01 November, 2001 14:32
> To: [email-masked]'; [email-masked]
> and other QoS protocol components will be used for more 
> complex QoS solutions, e.g., QoS required by the wireless link.
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 1 Nov 2001 15:53:40 +0100

Hi Jussi

I agree! the basic QoS signaling component should be 
as lightweight as possible, simple, very fast, scalable, etc.,

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 1 november 2001 15:42
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] Proposed NSIS charter

Hello Georgios,

Best Regards,
Jussi

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 2 Nov 2001 10:28:22 +0100

Hi Chen

I think that IP scalability issues are related 
to IP networks that are transporting huge amount of 
traffic that is generated by a huge amount of users.
An example of such a network is a IP based radio access network.
The things become much and much tougher when such networks are expensive
and the traffic within such networks has to be transported very fast.

I agree with you that each IP domain might impose different QoS requirements
on the applied QoS solution.
Therefore, it is very important to find one or more QoS solutions
that will be able to satisfactorily support these different 
QoS requirements.

Best Regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 1 november 2001 21:06
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [NSIS] Proposed NSIS charter

To make it simple, scalable, deployable, you really have to separate UNI
(User-to-Network) from NNI (Network-to-Network). Otherwise, all the network
information weight is carried over to user end device.

From service provider perspective, we have two basic requirements:

1. UNI signaling must be independent of the network and NNI signaling.
Choice of the network and NNI signaling is transparent to user device.
Separation of UNI from NNI ensures a simple UNI signaling which helps
widespread adoption in PC, appliance, handset, set top, gateway, router,
switch, wireless, etc.
2. UNI signaling must be multiprotocol, i.e. support different transport
technology (wireless, DSL, Ethernet) with different session mechanism (IP
flow, ATM VC, Ethernet VLAN, MPLS label).

 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent:	Thursday, November 01, 2001 8:54 AM
To:	[email-masked]'; Georgios Karagiannis (ELN)
Cc:	[email-masked]'; [email-masked]'
Subject:	RE: [NSIS] Proposed NSIS charter

Hi Jussi

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 1 november 2001 15:42
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] Proposed NSIS charter

Hello Georgios,

Best Regards,
Jussi

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 2 Nov 2001 11:04:11 +0100

Hi Mehmet

I agree with you when you are saying that 
we should also consider requirements from other sources.

Best regards,
Georgios

-----Original Message-----
From: Ersue Mehmet [mailto:[email-masked]]
Sent: woensdag 31 oktober 2001 17:17
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: WG: [NSIS] Proposed NSIS charter

Hi John, Georgios, 

the results from the NSIS BOF in Minneapolis are very 
useful for this WG because of the numerous and different 
requirements. There are also other sources for lightweight 
QoS signalling requirements for access networks. 
Especially we should also consider requirements for 
mobilty environments from 3G standardization and mobile 
Internet service providers (s. MORE BOF in London), in 
addition to the already mentioned I-Ds by Georgios and 
Hemant.

If we design a protocol by considering all of these 
requirements we will get something which is probably 
too complex and not scalable.
We have also to think on a framework definition in 
parallel, e.g. with a modular, extensible protocol 
suite which has a few well-defined optional extensions 
for specific scenarios. Implementors should be able to 
choose between the full suite or optimizing the 
implementation by using only a basic subset.

Are you planning to define design teams for the signaling 
requirements and framework architecture I-Ds in Salt 
Lake City? IMO both I-Ds could be developed more stable 
if the design teams would have a somehow parallel schedule 
or could be synchronized.

Best Regards,
Mehmet Ersü

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet: Mittwoch, 31. Oktober 2001 13:48
An: [email-masked]; [email-masked]
Betreff: RE: [NSIS] Proposed NSIS charter

Hi Georgios,

> [JL] We've been asked by members of the
> [JL] IESG to consider one document as input to the discussion.
> 
> OK, but why then you have not considered the draft written 
> by Scott Bradner and Allison Mankin entitled:
> "Report of the Next Steps in Signaling BOF" and located at:      
> http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> 
> This draft presents an initial set of
> requirements for a next generation Internet signaling protocol.  
> It is actually describing several requirements (briefly) 
> presented by many people during the 50th IETF meeting.

This hasn't come up in the chartering discussion with 
our ADs (Scott & Allison). I think that they are on the
list & they can speak up , if it would be good to consider
this as part of the WG effort.

John

---

From: [email-masked]
Date: Mon, 5 Nov 2001 08:47:49 +0200

Hi Xiaoming,

> > The intention is not to define a new protocol, but to enhance or
> > modify an existing one, such as RSVP.
> 
> Could this "existing one" be interpreted as "approaches which 
> have been already presented (perhaps under development)"? 

It should be interpreted as a standards track protocol.

> > One goal is to define the architecture.  This may include signaling
> > to a proxy or to a bandwidth broker.
> 
> Do we have any "proxy" or "bandwidth broker" in existing 
> protocols? IMO the answer depends on my previous question.

This would be an area to consider.  There has some interest
in an RSVP-proxy, where instead of signaling hop-by-hop,
the QoS signaling would be handled by a proxy.  This is
one approach to investigate.

br,
John

---

From: [email-masked]
Date: Mon, 5 Nov 2001 08:51:07 +0200

Hi Ersue,

> implementation by using only a basic subset.

This is along the lines of what I was thinking.  However,
I think we need to highlight 'lightweight' and 'simple.' 

> or could be synchronized.

Right now, NSIS seems to have a fairly focused charter.
I don't see the need for a design team at present.  
I think that we should discuss at much as possible prior
to SLC & then use the meeting to address specific issues
that have been brought up.

best regards,
John

---

From: [email-masked]
Date: Mon, 5 Nov 2001 08:58:17 +0200

Hello,

It looks to me, that we can not expect one single QoS mechanisms to be
deployed everywhere in the near future (here I refer to the actual
mechanisms, not signaling). For example, some operators may stick to Best
Effort + overprovisioning, while others go for different kind of DiffServ
schemes or perhaps IntServ. 

If we have completely separate UNI and NNI signaling, what happens if the
access ISP simply does not support UNI. Does potentially useful QoS
information just disappear to dev/null. Or what happens if one operator
makes a mistake and the QoS information is distorted.

That is why I prefer some end-to-end component that is basically common for
UNI and NNI interfaces and that stays untouched through the whole path over
various networks. There can naturally be some other components that are
specific to UNI and NNI. 

Best Regards,
Jussi

> Sent: 02 November, 2001 11:28
> To: 'Chen, Weijing'; [email-masked]'

---

From: [email-masked]
Date: Mon, 5 Nov 2001 11:40:45 +0200

Hi all,

My general comment is that we need to analyze how and where
NSIS is used.  Prescribing UNI vs. NNI uses is premature,
in my opinion.

br,
John

> It looks to me, that we can not expect one single QoS 
> mechanisms to be deployed everywhere in the near future (here 
> I refer to the actual mechanisms, not signaling). For 
> example, some operators may stick to Best Effort + 
> overprovisioning, while others go for different kind of 
> DiffServ schemes or perhaps IntServ. 
> 
> If we have completely separate UNI and NNI signaling, what 
> happens if the access ISP simply does not support UNI. Does 
> potentially useful QoS information just disappear to 
> dev/null. Or what happens if one operator makes a mistake and 
> the QoS information is distorted.
> 
> That is why I prefer some end-to-end component that is 
> basically common for UNI and NNI interfaces and that stays 
> untouched through the whole path over various networks. There 
> can naturally be some other components that are specific to 
> UNI and NNI. 
> 
> Best Regards,
> Jussi
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 5 Nov 2001 12:08:18 +0100

Hi John

[JL] It should be interpreted as a standards track protocol.

Could you give some examples?

[JL] This would be an area to consider.  There has some interest
[JL] in an RSVP-proxy, where instead of signaling hop-by-hop,
[JL] the QoS signaling would be handled by a proxy.  This is
[JL] one approach to investigate.

Do you mean that the QoS signalling will not be an end to end QoS 
protocol but somehow an edge to edge protocol?

Best Regards,
Georgios

---

From: [email-masked]
Date: Mon, 5 Nov 2001 13:13:37 +0200

Hi Georgios,

> Could you give some examples?

RSVP as the signaling protocol for IntServ.

What we should do in NSIS is consider, for example, what would
be needed (and what would not be needed) from RSVP for QoS
signaling.  Additionally, we should define a framework 
architecture (more about this below).

> protocol but somehow an edge to edge protocol?

This is to be determined in the framework architecture.  There
have been many suggestions - user to network, end-to-end, edge-to-
edge.  I think we should at least study these in this wg.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 5 Nov 2001 12:17:42 +0100

Hi John

[JL] RSVP as the signaling protocol for IntServ.

Why only RSVP?

[JL] This is to be determined in the framework architecture.  There
[JL] have been many suggestions - user to network, end-to-end, edge-to-
[JL] edge.  I think we should at least study these in this wg.

Agree!

Best regards,
Georgios

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 5 Nov 2001 12:20:58 +0100

Hi John

[JL] This is along the lines of what I was thinking.  However,
[JL] I think we need to highlight 'lightweight' and 'simple.' 

I agree!

[JL] Right now, NSIS seems to have a fairly focused charter.

Do you know when the updated version of the charter 
will be ready?

Best Regards,
Georgios

---

From: [email-masked]
Date: Mon, 5 Nov 2001 13:26:56 +0200

Hi Georgios,

> [JL] RSVP as the signaling protocol for IntServ.

Because this is the acknowledged signaling protocol in the IETF.
Do you have other suggestions?

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 5 Nov 2001 12:36:25 +0100

Hi John

[GK] Why only RSVP?

[JL] Because this is the acknowledged signaling protocol in the IETF.
[JL] Do you have other suggestions?

Maybe it will be good if we first discuss the different 
QoS requirements proposals and then 
decide about the QoS protocol choice?

Best Regards,
Georgios

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 5 Nov 2001 12:52:20 +0100

Hi Jussi,

I think that I will agree with John,
i.e., we need to analyze how and where NSIS is used.  

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 5 november 2001 7:58
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] Proposed NSIS charter

Hello,

Best Regards,
Jussi