RE: [NSIS] meeting minutes

[[e-mail]]

I could fill in a couple of gaps for you:

Tracey Sue should be Tricci So

the Someone who "had concerns with the possibility that
inter-domain signalling is out of the scope of this WG."
in the last paragraph was me (Dick Knight).

"Stig Noig?: Cannot do QoS signaling without being compatible(?) with
routing."
was me, and what I said was:
Dick Knight: At the original BOF for this group, there was a statement that
you can't ignore routing when signalling QoS requirements, therefore the
requirement for interworking with routing should be re-worded to say
"compliments" the routing.

 

regards,

Dick Knight

This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 19 December 2001 09:27
To: [e-mail]
Subject: [NSIS] meeting minutes


Hi all,

Here are some rough minutes - I would appreciate comments on them by the end
of the week.  Thanks go out to Jarno Rajahalme & Janne Rinne for taking the
minutes.

thanks,
John

NEXT STEP IN SIGNALLING WG - IETF 52

This was the first NSIS WG meeting. John Loughney/Nokia chairs this working
group. In the beginning Chairman presented the charter of this WG. No
comments were provided for the charter. 


Requirements of a QoS Solution for Mobile IP, Hemant Chaskar
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-01.
txt
============================================================================
===

This document has gone through the last call in Mobile IP WG, but Mobile IP
WG has decided not to work with QoS protocols. The QoS requirements listed
in this draft were discussed in the separate mailing list and the archives
are available. The draft divides requirements basically for the MUST, SHOULD
and MAY categories. In the "must" part, the requirements are quick setup
time in case of handovers, localization to the handover-affected segments
and releasing after handovers the QoS states. In a "should" category, there
are requirements for interoperability with mobility protocols, handling QoS
paradigm heterogeneity, having provisions to signal QoS along the different
paths. "May" part consist of the requirement to carry information relevant
for lower layers. The draft is stating also that features for QoS signalling
are scalability, security, and conversation of wireless bandwidth, low
processing, and hooks for accounting and authorization. 


Q: (Unknown): QOS paths, CAN choose one?
A: Yes

Q: Bob Braden: What do you mean by scalability?
A: That is a hard question ...

Q: Bob Braden: RSVP scales linearly
A: Quantification of these requirements hard, can -> mailing list

Q: Kwok ho chan?: Roaming between wireless/wireline?
A: Distinction not visible to the IP layer, (at least all of the MUSTS).

QoS signalling Protocol Requirements for Wired Networking, Bechet Sarikaya
http://www.ietf.org/internet-drafts/draft-sarikaya-nsis-wiredreqs-00.txt
========================================================================

Inputs to this document came from the NSIS BOF, Internet 2 Qbone documents
and the fact that Internet core is ready for end-to-end support. In this
presentation several requirements were listed. QoS signalling should support
audio and video and it needs to provide security and integrity. It was also
required that security requirements should be signalled to the relevant
parties. Signalling mechanism should be also simple and lightweight. Next
steps are to encompass all the requirements from the wired network's world.
Also there will be more specific requirements about the needed QoS
parameters. Aim for this next step is to gather the requirements to the
informational RFC. 

Q: Tracey Sue ?: Service control signaling vs. bearer control signaling
needs to be specified. 
A:  OK.

Q: (Unknown) Privacy reqt apply to the MN on the network? or Edge, Access,
or proxy nodes?
A: Good question

Q: Hemant Chaskar: Application specific info to the QoS signaling protocol
(audio/video)?
A: End-to-end signaling, so application requirement should go in there.

Q: (Unknown) Motivation for the in-band/out-of-band & interworking between
the two?
A: in-band etc.: pointer for future work.

Q: (Unknown) Is there a plan to consolidated requirements?
A: John: Yes, WG process will follow

Q: (Unknown): Stateless? Why?
A: Rather "soft state"

Q: (Unknown): What do you mean with "signaling security for packets"?
A: Sec reqts should be in the signaling protocol?

Q: (Unknown): Lightweight auth?
A: John: Will work on the security/auth.

John: Will be application independent.

QoS signalling requirements for Wireless Networks, Gergios Karagiannis
http://www.ietf.org/internet-drafts/draft-karagiannis-nsis-wireless-requirem
ents-00.txt
============================================================================
===========

This draft outlines a set of requirements for signalling QoS need in the
wired part of IP-based wireless networks. Those requirements are:

* Minimal impacts on performance. Currently RSVP is too heavy,
overprovisioning uneconomic and we need to find out what is the right
balance between those. 
* On demand resource reservation which means the careful use of the
bandwidth. Static vs. per flow management by RSVP, where is the middle
ground. 
* Unicast reservation and we need to modularize multicast parts that we can
not to use. 
* Scalability manageable and bi-directional reservations.

Next step is to collect mandatory and optional requirements. Then prioritize
minimal set for signalling. 
It was commented that it is good idea to consider signaling to be done per
domain. 

Q. Michael Thomas: to find middle ground, need to agree that indeed RSVP
work is too heavy. A lot of work being done
A: Less-heavy solutions needed for wireless access networks

C: Tracey Sue ?: Domain-based consideration important (in the draft?)
C: (Unknown): Per-flow mgmt too heavy and wasteful, however RSVP is a good
reference point.
C: George Tsirtsis: RSVP+everything else, why the separation between the
wireless/wired?


Requirements for QoS Signalling, Marc Greis
http://www.ietf.org/internet-drafts/draft-greis-qos-signaling-requirements-0
0.txt 	
============================================================================
=====

Purpose of the draft is collect requirements for QoS signalling (not for
provisioning). Some focus of the draft is on mobile, wireless, cellular
networks. This draft provides an opportunity re-think RSVP. It was stated in
the presentation that prioritization is necessary (must/should/may or
high/medium/low priority). Marc showed quite big list of all requirements
and he was asking from the group, which requirements are needed in addition
to simplicity as basis for future work. The term compatibility raised some
concerns and Marc said that term interoperability could be better word to be
used. It was asked what is the difference between Marc's and Hemants draft.
Hemant's draft is focusing only mobile IP case and Marc's is more general.
It was commented that one requirement for QoS signalling is to maintain the
session. Also it was said that there should be a link between the routing
system and QoS signalling.

Q: Bob Braden: Simplicity really high on the list, do we really want to get
there?

Q: (Unknown): The list of reqts more complex than RSVP?

Q: What is the difference to the Hemant's draft?
A: Mobile IP QoS solution really important

C: (Unknown): 
Signaling should be application independent, inter-domain will be much more
complex than intra-domain

A: (Unknown): Need to find out what applications need to be supported?
[multicast?]

C: (Unknown): Maintenance of the session?

C: Stig Noig?: Cannot do QoS signaling without being compatible(?) with
routing.

C: (Unknown): Is support for explicit release needed?
A: Soft state could be useful for this.


Analysis of Existing QoS solutions, Piers O'Hanlonn. 
http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-00.txt
=====================================================================

In this presentation, existing QoS mechanisms were presented, which are RSVP
for intserv, Diffserv, Dynamic Bandwidth Broker, Intserv over DiffServ,
Aggregated RSVP, QOS routing, MPLS and other kind of marking e.g., ECN. The
intention should be to have all these features combined in one mechanism. It
was also mentioned that MPLS-RSVP should be in the list as well

Q: Jim Kemph: Presentation has no info on why QoS does not work?
A: More detail in the draft?

Q: nagarazi (Sprint?): Diffserv aware RSVP?

Application of Integrated Services on Wireless Accesses - Brian Williams ´
http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issues-00.t
xt
http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-params-00.t
xt
============================================================================
==

Brian's presentation was covering also a draft-fodor-
wireless-params-00.txt. Shortly the draft "issues" is saying that
RSVP/intserv mechanism is not sufficient for some layer 2 technologies, when
draft "params" examines other information that could be useful. 

Q: Tsirtsis: L2 APIs exist?
A: Applications should use L2 independent IP API

Fundamental Questions Regarding End-to-End QoS, Kristian Nemeth
http://www.ietf.org/internet-drafts/draft-bos-mmusic-sdpqos-framework-00.txt
============================================================================

In this presentation, issue was divided to 6th pieces: Access network, Core,
end-to-end, interdomain, Congestion control and resource forecast. Access
networks are the bottlenecks and resources reservation is needed. In the
presentation assumption was to use DiffServ at the core. Inter-domain
signalling could be similar e.g., BGP. Congestion control is needed in order
to make decision which user to turn down and how (business perspective).
Resource demand forecast support was meaning that how to foresee volumes and
directions. It was mentioned that solutions are in the different levels and
according to presenter Access, end-to-end and congestion control could in
the scope of NSIS WG. Also it was proposed that signalling mechanism should
be sender oriented, it should support homogeneous multicast only and it
should be one-pass reservation mechanism. More info for this draft could be
found from the http://boomerang.ttt.bme.hu. There was a second opinion as
well, which was proposing to have core part included instead of access
network part to the WG's scope.

Q: Scope: Service control signaling vs. bearer control signaling, Urge WG
chair & Area directors to 

C: End-to-end? Should be U-N-I

John: rat hole, next presentation please

Features of Ipv6 Signalling, Jun Kyun Choi
http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-00.txt
====================================================================

This draft is dealing with the Ipv6 features and especially with the flow
label field. It was mentioned that label switching for QoS and TE is needed
and Flow Label information should be distributed. Also one target was to
improve scalability using aggregations. Next header field is used to
identify signalling for entities and separation of signalling from user data
traffic, make use of Ipv6 extension header (routing option, hop-by-hop
option header).

Chair commented that Ipv6 WG is working with the flow label and not here in
NSIS.

Michael Thomas: Flow Label as the flow spec.
Scott Bradner: Don't know if flow label is going to be a useful tool for
QoS.

C: Jim Kempf: Access Networks: IP vs. ATM

Q: ??: Access & QoS (SG16): Priority of services useful

Q: Marcus: Discussion points to the list. Scenarios and use cases important.

Q: Ping Pan: WG scope (second the opinion on scenarios)

D: Tsirtsis: How to manage the process forward. Will be difficult task.

C: (Unknown) Scope needs to be defined before requirements?

Scott Bradner: Scope and requirements together, presentations were non-WG
docs

Thomas: Long on desirables, short on analysis

?: Can we start narrowing down the scope now?

Ping Pan: Inter-domain out of question
C: Service control out of scope, focus on the bearer control

C: Focus on the bearer, not the service level aspects

C: (Service Provider) Focus on the bearer control

C: QoS signaling for the media path (in IETF language), service provider
needs to get paid, need to work over multiple domains for the accounting

Stig Nai?: Option or tool for inter-domain could be available
John: especially roaming should be addressed

Scott Bradner: Internet is multiple domains of technology, would like to
(later on) to tease out what people mean with "setting up bearer service"

Thomas: "Bearer" and "Trunk" out-of-scope

C: Separate or common reqts for wired and wireless
John: L2 issues, one document about L3 reqts

Scott Bradner: Explicitly NOT to focus on one or the other, both.

C: These are individual, presentations, would be wrong to focus on setting
up a "channel" or "path", RSVP works on the path...

A Network Model using Per-Session signalling, Ping Pan
http://www.ietf.org/internet-drafts/draft-pan-signal-req-00.txt
===============================================================

Issues listed in the presentation:
What kind of network (end-to-end, network-to-network. UNI)?
Why admission control? What about the over-provisioning?
What about backbone and inter-domain?
What about security and DOS?
Why/how lightweight? (processing scaling now and future)
Can we use existing RSVPv1? (it is working, deployed...per flow, soft-state,
multicast, shared reservation, receiver initiated reservation, two pass
reservation and the applications)
What to do from here? 
This should be done and urgently. It was asked to take these issues into a
consideration in this WG.

It was asked what is the difference between this and RSVP-Diffserv RFC?
Chair encourages reading it. 

Q: Lightweight protocol scaling?
A: Scaling: state, CPU, BW, manageability. Only processing scaling important

Q: Looks very much like RFC 2998?
A: 

A framework for end-to-end user perceived QoS negotiation, Suresh Leroy
(Alcatel)
http://www.ietf.org/internet-drafts/draft-bos-mmusic-sdpqos-framework-00.txt
============================================================================

This presentation introduced another view for signalling and intention was
to use session layer in signalling QoS end-to-end. General requirements
were:
* Service access provider may be involved in the negotiation process
* Independent of QoS provisioning mechanism used
* Independent on signalling protocol
* Re-use of existing protocols
* Flexibility to specify the QoS in session

Q: Michael Thomas: signaling path the same as the data path?
A: No, totally independent?

Kemph: End-to-end QoS is really expensive, those that want to give the "busy
signal". Should investigate if it can be made cheaper, but not likely.

Hemant: What is missing in SIP?
A: SDP now specifies only the codec, but no QoS parameters (delay, error
rate)?

Discussion:
===========

It was commented that we should work with signalling in the access networks
too. Next step should be to define requirements and scope for the NSIS work.
It was mentioned that requirement list is coming to the email list soon.
Also scenarios and use cases should be considered. Somebody disagree that we
need to define requirements before the scope. AD said that scope is part of
the requirements. It was commented that service control type of signalling
should be out of the scope of this WG. Chair clarified that we are not going
to define any authorization mechanisms here in this WG, but we could provide
hooks for authorization purpose implemented by using some mechanism or
protocol defined by IETF. Someone ? had concerns with the possibility that
inter-domain signalling is out of the scope of this WG. It was said that we
might need to consider that at some level. AD asked some clarification how
bearer setup is done in the transport networks (an issue for mailing list).
Modular solution is needed in order to suit all QoS mechanisms.

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

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