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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 2 May 2002 16:03:24 +0200

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

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 02 May 2002 16:31:40 +0200

Sure, I know.
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.

Marcus

--On Thursday, May 02, 2002 4:03 PM +0200 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> - 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.

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 03 May 2002 10:25:09 +0200

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