Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt

From: [email-masked]
Date: Thu, 2 May 2002 20:49:10 +0300

Hi Marcus,

> The question is what are we doing with the requirement?
> Both you and John favour
>   SHOULD support sender initiated
>   MAY support reciever initiated
> 
> I would completly remove any requirements regarding initation.

If we include requirements for initiation, I favor the above.  However,
I am not bothered if this is left out.

John

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 3 May 2002 15:38:59 +0200

Hi Xiaoming

Thank you for your comments!
Please note that we do not exclude receiver initiated approaches,
but agree with the proposal of John Loughney:

	SHOULD support sender initiated
	MAY support receiver initiated

	MUST support unicast
	MAY support multicast.

Best regards,
Georgios

-----Original Message-----
From: Xiaoming Fu [mailto:[email-masked]]
Sent: vrijdag 3 mei 2002 15:18
To: Georgios Karagiannis (ELN)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [NSIS] comments Issue (2) included
indraft-ietf-nsis-req-01. txt

Hi Georgios,

The question is how far the requirement to be other than a solution?

My comments inline:

"Georgios Karagiannis (ELN)" wrote:
> 
> Hi Xiaoming
> 
> Regarding the need of having a sender initiated approach
> please look into draft:  "draft-partain-nsis-requirements-00.txt"

Thanks. 
Although I agree that it is advantegous to have a uniformed 
model for e2e NSIS protocol, I am not sure about whether it 
is appropriate for NSIS limited to sender-initiated. In your draft section 4:

 "- While there are possible scenarios where the receiver 
initiates the signalling, such as a web QoS scenario, this 
should be solved at the application layer for unicast flows."

This assumption indicates you have to introduce additional
NSIS modules (which may be complex if bi-directional is 
supported - as you proposed - as an unavailability of resources 
for one directional setup would bring difficulty in admission 
control, for instance) or more complex in application (which may 
differ from one app to another app).

> 
> There are scenarios that require a sender initiated approach.
> Therefore, I am in favour of keeping it (as proposed by John);
> 
> Regarding the bi-directional reservation I do not understand your
> argument regarding multicast.
> Bi-directional reservations are useful in certain unicast (not multicast)
> scenarios!

Do you mean the multi-sender, one-receiver scenarios? Following RSVPv1, 
unicast usually doesn't equal to one-to-one, but I am not clear
whether "unicast" in NSIS would follow this definition...

Regards

Xiaoming
> 
> Best regards,
> Georgios
> 
> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]]
> Sent: vrijdag 3 mei 2002 10:25
> To: [email-masked]
> Cc: Georgios Karagiannis (ELN); [email-masked]; [email-masked]
> Subject: Re: [NSIS] comments Issue (2) included
> indraft-ietf-nsis-req-01. txt
> 
> Hi Marcus,
> 
> I would favor your idea, i.e., removing requirement on sender- or receiver-
> initiation at all. Accounting may care, but this is much of an administrative
> problem.
> 
> Another related issue is bi-directional session. Since unicast have been
> agreed as a must (while multicast is not), there is no special reason to keep
> bi-directional support for sessions. Moreover, (if I understand correctly,)
> current provisioning techniques (e.g., IntServ, DiffServ) only support
> uni-directional setup.
> 
> Xiaoming
> 
> Marcus Brunner wrote:
> >
> > Sure, I know.
> > Marcus
> > --On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)"
> > <[email-masked]> wrote:
> >
> > > Hi Marcus
> > >
> > > The sender initiated and receiver initiated terms
> > > that I was referring to are included in the terminology of
> > > the draft!!
> > >
> > > Best regards,
> > > Georgios
> > > -----Original Message-----
> > > From: Marcus Brunner [mailto:[email-masked]]
> > > Sent: donderdag 2 mei 2002 15:55
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [NSIS] comments Issue (2) included in
> > > draft-ietf-nsis-req-01.txt
> > >
> > >
> > > Georgios, John,
> > >
> > > What is your rational behind the sender/receiver initiated reservations?
> > > What about 3rd parties? What does initation imply? On a high level
> > > perspective I don't see a reason for requiring the one or the other.
> > > Unfortunatly, this comes back to data path vs signaling path issues.
> > >
> > > The implications I see are:
> > > - an entity initating or triggering an initiation needs to be known
> > > (authentication process) or needs to pass money immediately
> > > - In practice, the initiator is the paying party (in real life this is
> > > the  case in most scenarios, where one party wants to have a service from
> > > another party. Or at least the assurance that a 3rd party will pay needs
> > > to  be given.
> > > - There is a tied relation to uni-directional vs bi-directional
> > > reservations
> > >
> > > Marcus
> > >
> > > --On Monday, April 22, 2002 4:34 PM +0300 [email-masked] wrote:
> > >
> > >> Hi Marcus & Georgios,
> > >>
> > >>> Please receive my comments on Issue (2) included in the
> > >>> NSIS WG draft: draft-ietf-nsis-req-01.txt
> > >>>
> > >>> Comment on Issue (2):
> > >>>
> > >>>
> > >>> > 2) (OPEN) Sender/receiver initiation
> > >>> >    What is the requirement concerning data sender or data receiver or
> > >>> >    both to initiate a QoS request.
> > >>> >    - does it matter who pays?
> > >>> >    - terminology text added
> > >>> >    open issue, what is a potential req (currently we say "both must be
> > >>> >    possible")
> > >>>
> > >>> [GK] both should be possible but it should be optimized for
> > >>> sender initiated;
> > >>
> > >> I think that SHOULD is the right level of requirement for sender /
> > >> reciever driven requests.
> > >>
> > >> John
> > >
> > >
> > >
> > > --------------------------------------
> > > Dr. Marcus Brunner
> > > Network Laboratories
> > > NEC Europe Ltd.
> > >
> > > E-Mail: [email-masked]
> > > WWW:    http://www.ccrle.nec.de/
> > > personal home page: http://www.brubers.org/marcus
> > >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: [email-masked]
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 3 May 2002 09:51:26 -0400

Can we guarantee that the semantics of the signalling do not change
depending on whether it is sender initiated or receiver initiated?
Probably not.

Gary Kenward

> Sent: May 3, 2002 04:25

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Mon, 6 May 2002 14:47:25 -0400

I support the idea to leave this requirement out. 
If you add 3d party requesting case (SIP proxy, application proxy,
softswitch, you name it) than you see that QI does not necessarily represent
neither receiver nor sender and the whole question becomes a moot point. As
Marcus has mentioned as soon as we agreed that signaling path might differ
from the data path we'd better not associate QI with any particular end of
the data flow.
It seems that it can be useful if NSIS protocol semantics allows a QI to
request the bi-directional reservation but it can be rejected by the QC if
employed QoS mechanism does not support it.

Ilya
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 1:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Marcus,

John

---

From: [email-masked]
Date: Tue, 7 May 2002 03:02:46 +0300

Hi Gary,

> depending on whether it is sender initiated or receiver initiated? 

As we are now discussing requirements, perhaps we could discuss if
the requirements are different based upon sender vs. receiver initiated
signaling.  

As a strawman, here are some ideas (not all good ideas ...)

For example, for sender initiated, can we support implicit signaling 
(bundling the QoS requests with other signaling - registration, etc.)?

For reciever initiated, do we need protoection against spamming - 
how do we protect against unwanted changes?

There are some more things, are these relevant?

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 7 May 2002 11:53:09 +0200

Hi Ilya

Maybe the terminology (in the NSIS requirements draft) 
is not clear, but what I mean with:

* a sender initiated approach
  is that the sender of the data path starts the reservation 
  towards the receiver, and 

* in the receiver initiated approach the receiver of the data path
  starts the reservation towards the sender.

Additionally, note that the triggering of this initiation 
can also be done by entities that are not sender or receiver of the 
data path.

In other words:
 * in a sender initiated approach, a QI, a QC or a QR
   that is not the sender of the data path will have to 
   trigger the sender of the data path to start 
   a sender initiated reservation.

 * in a receiver initiated approach, a QI, a QC or a QR
   that is not the receiver of the data path will have 
   to trigger the receiver of the data path to start a 
   receiver initiated reservation.

I hope that this makes it more clear!!

Best regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: maandag 6 mei 2002 20:47
To: [email-masked]'; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included
indraft-ietf-nsis-req-01. txt

Ilya
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 1:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Marcus,

John

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 7 May 2002 10:05:20 -0400

Georgios,

Thanks for the detailed explanation. 
Unfortunately I think we have quite a different picture in mind. Yours I
think originated in RSVP world but let's look at the case when you have
centralized bandwidth broker (QC) managing pre-provisioned LSPs. The
scenario I have in mind is this:
1. Endhosts (sender and receiver, let's say gaming consoles) do not speak
NSIS and are not aware of any bandwidth provisioning
2. An application level entity (gaming server) exists somewhere on the
network and acts as a QI for both of them by requesting network resources
for the session from the bandwidth broker (QC) via NSIS signaling
3. The bandwidth broker accepts session and replies via NSIS to the server
(QI).
4. The gaming server signal to the endhosts in the application specific way
that the session is setup.

I do not see place for the notion of sender/receiver-initiated approach in
this case. What do you think?

Ilya

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 5:53 AM
To: 'Freytsis, Ilya'; [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Ilya

In other words:

Best regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: maandag 6 mei 2002 20:47
To: [email-masked]'; [email-masked];

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 1:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Marcus,

John

---

From: [email-masked]
Date: Tue, 7 May 2002 16:58:13 +0200

Ilya,

I like the scenario that you propose. I think we can conclude from it that
any entity on or off the data path can assume the role of a QI for the
purpose of nsis signaling. In that respect, it seems logical that only
sender-initiated signaling needs to be supported, where sender-initiated
refers to the entity that initiates the nsis reservation, not the data
flow. You could eliminate the requirement, although I would be more in
favour to add this explanation and keep the requirement. It is still
possible that the QI triggers the QR and resources are only reserved on the
way back

Sven

"Freytsis, Ilya" <[email-masked]> on 07/05/2002 16:05:20

  To:          "'Georgios Karagiannis (ELN)'"                 
               <[email-masked]>,        
               "Freytsis, Ilya" <[email-masked]>,     
               "[email-masked]'"                    
               <[email-masked]>,                     
               [email-masked]                           
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

  Subject      RE: [NSIS] comments Issue (2) included         
  :            indraft-ietf-nsis-req-01.           txt        

Georgios,

Ilya

-----Original Message-----

Hi Ilya

In other words:

Best regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: maandag 6 mei 2002 20:47
To: [email-masked]'; [email-masked];

softswitch, you name it) than you see that QI does not necessarily
represent

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 1:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Marcus,

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 7 May 2002 17:15:24 +0200

Hi Sven

The terms sender initiated and receiver initiated are terms 
that are used and applied in IETF since many years, see e.g., RFC 1633.

Both are referring to the data path.

I understand that if you will use bandwidth broker scenarios 
these terms will not make  
much sense, but the bandwidth brokering scenario is 
not the only scenario that the NSIS WG is considering!

I am afraid that this bandwidth brokering scenarios 
complicate the NSIS protocol very much!

I would suggest to use the terms sender initiated and receiver
initiated as defined in e.g., RFC1633.
Additionally I would keep the requirement about sender 
initiated and receiver initiated.

best regards,
Georgios

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: dinsdag 7 mei 2002 16:58
To: Freytsis, Ilya
Cc: 'Georgios Karagiannis (ELN)'; Freytsis, Ilya;
[email-masked]'; [email-masked]; [email-masked]
Subject: RE: [NSIS] comments Issue (2) included
indraft-ietf-nsis-req-01. txt

Ilya,

Sven

                                                              

                                                              

Georgios,

Ilya

-----Original Message-----

Hi Ilya

In other words:

Best regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: maandag 6 mei 2002 20:47
To: [email-masked]'; [email-masked];

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 1:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Marcus,

John

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 7 May 2002 15:43:49 -0400

Good thoughts John.

I was thinking more along the line that the sender begins by stating
"this is the QoS I want use when I send to you", versus the receiver asking
"I would like you to send to me using this QoS". To make the semantic
difference in this example a bit more real, the first statement absolutely 
requires a confirmation from the receiver, in the second case, the sender
can 
response by simply establishing the QoS, and starting to send. 

The semantics are different enough to warrant different protocol exchanges
in
this simplistic example, I think.

As for bundling, I have just been reviewing some ideas being tossed around
for 
SDPng. There is a good case to be made for providing QoS specification with
the
session description. This is end to end QoS, of course, involving end-to-end
negotiation
that is will likely be coupled with other aspects of the session
description. The
material I was reading explicitly stated that QoS provisioning [along the
path network]
was not part of SDPng. However, my question is: how can two end systems
negotiated session
parameters without negotiating QoS? And, if the end systems are negotiating
QoS, how can
they do so without involving the network (or at least, having a fairly
extensive a priori
view of what QoS is available, end-to-end). Likewise, how does can the QI
negotiate with
the QC without the result impacting the session description, particularly
the non-QoS
components of the session description? A simple example of this is
bandwidth: if, for
example, the end hosts agree on G.711 for voice, then there is a minimum
bandwidth 
requirement that must be met.

This may be slightly off of what you had in mind in terms of bundling, but
your suggestion
raised the issue of the co-dependency between QoS and media type selection
in SDPng.

Gary

> Sent: May 6, 2002 20:03
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 7 May 2002 16:18:06 -0400

Georgios:

  To follow-up on my previous comment: 

     - we agree that sender initiated and receiver initiated belong
       (I am not convinced that QoS setup should always be initiated by the
sender)

     - I am confused by your comment about bandwidth broker (perhaps because
I missed
       the discussion). Ignoring the complexity of end-to-end inter-system
negotiation 
       for the moment, how is a bb different from a QC?

     - I believe the details of sender/receiver interaction with QI/QC/QR
can be left
       to the design phase discussion. Do you concur? Can we capture the
requirement
       sufficiently without addressing the nature/order of the interaction?

Gary

> Sent: May 7, 2002 11:15
> To: [email-masked]'; Freytsis, Ilya
> Cc: Freytsis, Ilya; [email-masked]'; [email-masked];
> [email-masked]

---

From: [email-masked]
Date: Wed, 8 May 2002 11:02:38 +0200

Hi Georgios,

I have not found a clear defintion of both although RFC 1633 offers a
rationale for the receiver-initiated reservation. I found no indication in
the text that sender and receiver do not apply to the entities that initate
the signaling. Of course, with RSVP this would be data path entities, my
point was that in NSIS, they is not necessarily the case. They might be
though when data flow sender/receiver acts as QI/QR but that is not
necessarily the case. I think we can use the terminology applying it to
QI/QC.

Sven.

"Georgios Karagiannis (ELN)" <[email-masked]> on
07/05/2002 17:15:24

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL,         
               "Freytsis, Ilya" <[email-masked]>      
                                                              
  cc:          "Freytsis, Ilya" <[email-masked]>,     
               "[email-masked]'"                    
               <[email-masked]>,                     
               [email-masked], [email-masked]            

Hi Sven

best regards,
Georgios

-----Original Message-----

Ilya,

Sven

Georgios,

Ilya

-----Original Message-----

Hi Ilya

In other words:

Best regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: maandag 6 mei 2002 20:47
To: [email-masked]'; [email-masked];

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 1:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01.
txt

Hi Marcus,

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 10 May 2002 15:10:10 +0200

Hi Gary
 
I think that we are in agreement about the definition of sender/ receiver initiated.
If you do not agree with the functionality that has to do with the triggering is Okay with me.
In the scenarios that I am interested in, the QI will always be either an end host 
(or a proxy that operates as an end host).
 
best regards,
Georgios

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: dinsdag 7 mei 2002 22:10
To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (2) included indraft-ietf-nsis-req-01. txt

Georgios: 

  Actually, I was in agreement with you until I received this email. 
It would seem to me, that the "sender" ("receiver") is a higher order 
entity in the end-to-end scenario in that the "sender" ("receiver") not 
only initiates QoS, but also initiates AAA, session establishment, and 
ultimately, the actual data transfer (reception). So, the "sender"("reciever) 
would initiate the QI: either a QI at the end host, or a QI acting as a proxy 
within the network. In other words: the "sender"("receiver") represents the 
end host in this context. 

(Note that I have always equated QI with the end-host, for non-proxy scenarios, 
which would mean the "sender" ("receiver") is a QI - as well as having other roles, 
in those scenarios). 

In a proxy scenario, I do not understand why the QI would "initiate" the "sender" 
("receiver") to "initiate" QoS. On the contrary, I see the "sender" instructing 
the proxy QI to initiate QoS setup, where the instruction may be explicit or implicit 
(i.e. NSIS does care what the form of this instruction is). 

Does this align with what you intended Georgios, or are we in disagreement/ 

Gary 

> [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: May 7, 2002 05:53 
> From: Freytsis, Ilya [ mailto:[email-masked] <mailto:[email-masked]> ] 
> From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
> https://www1.ietf.org/mailman/listinfo/nsis <https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> https://www1.ietf.org/mailman/listinfo/nsis <https://www1.ietf.org/mailman/listinfo/nsis>  
>

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 10 May 2002 10:55:11 -0400

Georgios:

 We are in agreement on the relative roles, but your comment on
triggering has me perplexed. I do not recall making any explicit
comment on triggering. At the moment, I think it is too early to
identify specific mechanisms for triggering. It seems to me that QoS
signalling should be initiated as a consequence of other network
activities (e.g. SDPng session negotiation), however, it is not 
clear how we would describe the requirements for this without
getting into gory detail (e.g. what SDPng protocol event triggers
QoS signalling). 

(Note: I use SDPng only to provide an example.)

Gary

> Sent: May 10, 2002 09:10
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Georgios Karagiannis (ELN);
> 'Freytsis, Ilya'; [email-masked]'; [email-masked]
> Cc: [email-masked]
> To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; 
> [email-masked]'; [email-masked]
> Cc: [email-masked]
> > [ mailto:[email-masked] 
> <mailto:[email-masked]> ] 
> > Sent: May 7, 2002 05:53 
> > From: [email-masked] [ 
> mailto:[email-masked] <mailto:[email-masked]> ] 
> <https://www1.ietf.org/mailman/listinfo/nsis>  
> > 
> <https://www1.ietf.org/mailman/listinfo/nsis>  
> > 
> 
>