Subject: RE: [NSIS] RE: Independence of signalling and data path (host-edg e vs edge-edge & b/w at final hop)

From: [email-masked]
Date: Thu, 31 Jan 2002 16:51:40 -0000

I am sort of split on the differences and similarities between host-edge and
edge-edge (which don't quite equate to UNI and NNI in telephony).
 
A protocol that highlights the differences will not be popular in the IETF,
where the end-to-end model stills reigns and is seen as being something that
should still be supported. However, some of the security aspects of spoofing
to steal others bandwidth is a worry.
 
I was not quite sure what you meant by "given the 
activities going on in signalling compression, bandwidth efficiency across
the 
host to network link should not be overly emphasized." I thought that there
was a need for efficiency in the 3G radio world, and other scenarios where
"final hop" bandwidth is severely limited.
 
Dick 

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: 31 January 2002 16:10
To: [email-masked]'; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: Independence of signalling and data path 

Dick: 

  Sounds reasonable. The only small addition, which is probably obvious, is 
to be careful about the need to distinguish between host-to-edge and
edge-to-edge 
interactions. At one level of abstraction, a client-server model is
applicable, 
where the client is either a host or a network/bandwidth broker. Any
variations in 
the solution that distinguishes host-to-edge from edge-to-edge thus needs to
be 
justified against the added complexity. And, just to pursue that thought,
given the 
activities going on in signalling compression, bandwidth efficiency across
the 
host to network link should not be overly emphasized. 

 I realize that this abstract will probably break down when we get to the
point 
of looking at the specifics of each case. However, I am wondering if it is
possible 
to construct the requirements for the more general client-server model? This
could 
cut the number of requirements nearly in half, and the associated debate by
an 
order of magnitude ;^). 

 Just a thought. 

Gary 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: January 31, 2002 07:17 
> To: [email-masked]; [email-masked]; 
> [email-masked] 
> Cc: [email-masked] 
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> 
> I think that we are all moving to is a generic NSIS protocol that is 
> applicable to the Host-Edge and the Edge-Edge interfaces. The 
> use of it 
> within a domain (hop-hop) must always be the decision of the domain 
> operator. This is because: 
> 1. An operator of a domain will make their own decisions 
> regarding protocol 
> selection 
> 2. domain operators need a generalised QoS protocol for interconnect 
> 3. Some approaches for QoS (at least the bandwidth part) do 
> not require any 
> signalling (e.g. overprovision). 
> 
> In case 3, it seems to me this is a specialised case of 
> Edge-Edge. The two 
> edges in this case are within a single domain or technology 
> type, and the 
> NSIS signalling protocol must traverse it in order to reach 
> the next domain 
> or QoS technology type. 
> 
> Dick 
> 
> 
> -----Original Message----- 
> From: Georgios Karagiannis (ELN) 
> [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: 31 January 2002 09:03 
> To: 'Freytsis, Ilya'; [email-masked]' 
> Cc: [email-masked]' 
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Hi Ilya 
> 
> Regarding your following statement: 
> 
> [IF]>> In other words I am suggesting the following global analogy: 
> [IF]>> If you view the domain with a QoS technology as a 
> [IF]>> virtual router than NSIS 
> [IF]>> signaling used between those routers follows the same 
> [IF]>> path as data. What 
> [IF]>> happens within the router is not a NSIS business. 
> 
> I partially agree! 
> 
> I believe that the NSIS protocol when needed, 
> should be capable of operating within a QoS domain 
> (that is a QoS domain administrated by a provider). 
> However, if the QoS functionality is provided by a Bandwidth Broker 
> or the domain is overprovisioned then the signaling path and 
> user data path 
> can be independent (not the same). Of course this can be 
> chosen by the 
> provider! 
> 
> But when a provider would want to use the NSIS protocol within the 
> domain for QoS support, then it should be possible to set (activate) 
> the NSIS protocol such that the signaling path and user data 
> path use the 
> same path. 
> 
> I agree with the rest of your statement! 
> 
> Best Regards, 
> Georgios 
> 
> 
> -----Original Message----- 
> From: Freytsis, Ilya [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: dinsdag 29 januari 2002 18:45 
> To: [email-masked]' 
> Cc: [email-masked]' 
> Subject: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Marcus, 
> 
> Let me add my 2cents into this discussion: 
> 
> It looks to me that this discussion got very heated because 
> it is at the 
> very border between general QoS signaling and specific QoS 
> technology in use 
> (by the domain). The fact that you mentioned such terms as 
> "Controller" and 
> "BB" indicates to me that you have a particular technology in 
> mind that 
> based on this kind of entities. Tell me how the node at the 
> edge of the RSVP 
> or DiffServe domain can get such an idea as a BB that governs the 
> neighboring domain. On the other hand the framework advocated 
> by Georgios 
> somewhat implies the use of the hop-by-hop QoS technology 
> (and probably for 
> this reason is opposed by some people including myself) that relies on 
> signaling and data path being the same. 
> The way to resolve this conflict in my mind is something 
> along the following 
> lines: 
> 1. The general NSIS signaling being used between the host and 
> the edge and 
> between the edges of the neighboring domains (based on different QoS 
> technology) should follow the same path as data (or lay out 
> the path for the 
> data if you wish). 
> 2. It is up to the edge nodes that understand used within domain QoS 
> technology to communicate to the BB or controller and 
> translate NSIS generic 
> signaling into something specific for this domain. Obviously 
> the generic 
> NSIS signaling has to be recreated at the domain egress edge. 
> 3. In this scenario the host can be enabled with the particular QoS 
> technology and use specific signaling for communication with the first 
> domain or can use generic NSIS signaling. 
> 4. The communication between neighboring domains using the same QoS 
> technology can be done in the specific for the technology 
> fashion though 
> translation to NSIS and back will be always available if for 
> whatever reason 
> those domains prefer it. 
> 
> In other words I am suggesting the following global analogy: 
> If you view the domain with a QoS technology as a virtual 
> router than NSIS 
> signaling used between those routers follows the same path as 
> data. What 
> happens within the router is not a NSIS business. 
> 
> Ilya Freytsis 
> 
> Date: Tue, 29 Jan 2002 11:36:05 +0100 
> From: Marcus Brunner <[email-masked]> 
> Reply-To: [email-masked] 
> To: "Georgios Karagiannis (ELN)" 
> <[email-masked]> 
> Cc: [email-masked] 
> n.se> 
> Subject: [NSIS] RE: Independence of signalling and data path 
> (was RE: [NSIS] 
> Two                   kindsof  requirements) 
> 
> Georgios, 
> 
> see inline 
> 
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios 
> Karagiannis (ELN)" 
> <[email-masked]> wrote: 
> 
> > Hi Marcus 
> > 
> > 
> > [MB]>> So, I think you much in line with that req. The protocol 
> > [MB]>> from host to BB does not depend on the data path 
> > [MB}>> completly. What the constrain for the 
> > [MB]>> communication are is a different question. 
> > 
> > I will repeat what was already said in my previous e-mail: 
> > 
> > This is only true when the following CONSIDEARTIONS are 
> > fulfilled: 
> > 
> > * BB's or QoS controllers are used; 
> 
> -> QoS controllers are no BBs in our understanding, the hop by hop 
> signalling is a special case, where each hop has a QoS 
> controller and QoS 
> initiator functionality runing. 
> 
> > * the end-host should know the address of the first hop 
> Bandwidth Broker; 
> 
> An end-host needs to know quite a bit of servers/nodes 
> anyway. I even think 
> there are solutions (e.g. AAA servers), where the first hop router is 
> forwarding the signalling messages to the right place. 
> 
> > * the BBs should be aware (know) the addresses of neighboring BBs; 
> 
> Sure, you need interdoamin routing anyway. 
> 
> > * BB's or QoS controllers should be able to relate 
> >    the QoS signaling to the data path; 
> > 
> 
> yes true, I think this is the core functionality of a 
> signalling protocol. 
> Only depends on the information available in the signaling message. 
> 
> > 
> >  In GENERAL the above CONSIDERATIONS are very difficult to 
> >  fulfill. Please note that we need a NSIS protocol that can 
> >  be applied for GENERAL cases. Of course YOUR 
> >  SCENARIO, but OTHER TYPES as well will be INCLUDED. 
> > 
> 
> IMO, with the QoS initator and QoS controller framework we 
> excaclty target 
> a more general case then the hop-by-hop signalling. 
> 
> > Thus, in GENERAL the path followed by signaling 
> > messages and the path followed by user data packets (associated 
> > to these signaling messages) MUST BE THE SAME!! 
> > 
> 
> No, I do not agree. 
> 
> 
> > 
> > Solution on how signaling messages and user data 
> > packets can follow the same path: 
> > The signaling messages will 
> > follow the same path as the user data packets when for example, 
> > the IP destination address of the signaling messages is the same 
> > as the IP destination address of the user data packets. 
> 
> Not necessarly (but normally packet with the same destination 
> likely take 
> the same path) 
> 
> > Typical IP routing protocols will route both signaling messages 
> > and user data packets that have the same IP destination 
> address through 
> > the same path. RSVPv1 uses something similar (on the PATH messages 
> > and user data packets having the same flow ID); 
> > 
> > [MB]>> And whether, the 
> > [MB]>> protocol work 
> > [MB]>> between ehost, eedge, ehop, all of them can be controllers 
> > [MB]>> and initiators 
> > [MB] on the other side. So they do not require data and signalling 
> > [MB] on the same path. 
> > 
> > What do you mean, would you like to have a NSIS protocol version 
> > that starts at one hop router and terminates at the next 
> first hop router. 
> > This protocol will be very slow, very complex, and in my opinion 
> > not useful! 
> > 
> 
> You have to be more specific on slow and complex. 
> If you mean with slow the signalling delay (I think you are 
> better of not 
> performing some actions in each hop) 
> 
> The complextity in terms CPU heavily depends on the 
> complexity of the state 
> machine, which defionitly not defined yet. But you are 
> definitly right, 
> that it needs to be simple. 
> 
> Marcus 
> 
> > 
> > Best regards, 
> > Georgios 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________ 
> nsis mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 31 Jan 2002 12:03:46 -0500

Dick:
 
   Wireless is always (over) sensitive to bandwidth consumption over the
air. The issue I was raising was whether
this consideration should be explicitly be incorporated in the NSIS protocol
design, or whether normal design principles
of protocol efficiency for the internet should be used under the assumption
that additional bandwidth efficiency/overhead
reduction for wireless links be effected through packet compression.
 
  The first option with definitely result in the creation of two protocols,
with the obvious artifact that considerations of 
wireless link layer issues is one of the main distinctions between the two.
The second approach fits more into the IETF
model of link independence and end-to-end, but with the downside that an
additional compression protocol may be required 
for wireless operation.
 
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: January 31, 2002 11:52
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: Independence of signalling and data path (host-edg e
vs edge-edge & b/w at final hop)

 
 
Dick 

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: 31 January 2002 16:10
To: [email-masked]'; [email-masked];

Dick: 

 Just a thought. 

Gary