Subject: RE: [NSIS] Automatic Discovery of QCs

From: [email-masked]
Date: Fri, 1 Mar 2002 17:07:18 -0500

Hi John:

In the interest of simplicity, allow me to turn around the blurred requirement. Can we actually say that

"NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities."

In other words, can't a host just shoot an NSIS signal towards the network (destined to a well-known IP address for example or identifiable by some field in the packet header) and the routers can forward it to appropriate QCs in their network domain.

Hemant

-----Original Message-----
From: Loughney John (NRC/Helsinki) 
Sent: Friday, March 01, 2002 3:56 PM
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] Automatic Discovery of QCs

Hi Roland,

> I would add another point to section 5.3 of draft-ietf-nsis-req-00:
> 5.3.8 Automatic discovery of QoS Controllers.
>       This will allow some degree of auto configuration which can
>       be useful in many scenarios. For instance, hosts (especially 
>       mobile ones) will be able to find out the next adjacent 

Could we blur your requirement somewhat?  My suggest is:
 
  5.3.8 Discovery of QoS Controllers

	NSIS SHOULD support a simple mechanism for discoverying
	QoS entities.

This means that, for example, on-path signaling could be one
option - meaning that as the host signals the network, the
network can eavesdrop and setup signaling to off-path 
QoS entities; or access routers could proxy the QoS 
controllers and interact with them and allow some 
sort of seamoby context transfer for mobility, etc.

For me, a key issue with this topic is how does an end user
discover QoS entities?  Does it employ a protocol like SLP,
or DNS? Does the network do it via a proxy model; is there
some pre-configured home QoS entitity that negotiates
with the visitied network... or something else?

I favor a minimal approach, which allows service providers
to implement more complex schemes - but yet still allows the
minimal approach to work.

John

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

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

---

From: Muhammad Jaseemuddin <[email-masked]>
Date: Fri, 01 Mar 2002 17:39:42 -0500

Hi Hemant:

 I like your wording. The signaling should not include the QC discovery 
as an additional step, but if the network operator wants to configure 
the host with the QC address should resort to any other means, e.g. DHCP 
etc. The implication would be the QC implementation would need DNS like 
robustness. Hence, for the network operator the more preferred way would 
be to configure access routers as either QC or proxy. Anyway, the 
following wording gives much latitude to implementation and deployment 
of QC.

- Muhammad

-- 
==================================================
Muhammad Jaseemuddin
Associate Professor
Departement of Electrical and Computer Engineering
Ryerson University
350 Victoria Street
Toronto, ON M5B 2K3
Tel: +1 416 979-5000x6073
Fax: +1 416 979-5280
Email: [email-masked]
Web: http://www.ee.ryerson.ca/~jaseem
==================================================

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Mar 2002 13:24:15 +0100

Hi Hemant,

> "NSIS SHOULD support a signaling mechanism that does not require explicit discovery of QoS entities."

Simplicity is usually fine. My proposal had also the objective for
simplification: the end-system/user shouldn't have to explicitly know/
configure the QC address. I thought that explicit discovery lets the
user/end-system decide which QC should be used subsequently and it 
might also be a good thing in mobile environments. So I'm not really
sure whether we should "exclude" explicit discovery this way. Therefore,
I like John's statement:
*| I favor a minimal approach, which allows service providers
*| to implement more complex schemes - but yet still allows the
*| minimal approach to work.

> In other words, can't a host just shoot an NSIS signal towards the
> network (destined to a well-known IP address for example or identifiable
> by some field in the packet header)
> and the routers can forward it to appropriate QCs in their network
> domain.

This sounds like using anycast address mechanisms. In my proposal, the
host can send a QC solicitation request to a well-known multicast
address. QCs send back information about themselfs. So it would be the
end-system/user that can choose between alternatives (meaning a bit more
complexity). By using "magic" forwarding, you have to accept the
network's decision. What if the host is located in the range of two
domains? Towards which domain is the request forwarded?

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097