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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 3 May 2002 11:27:12 +0200

Hi Xiaoming

Regarding the need of having a sender initiated approach 
please look into draft:  "draft-partain-nsis-requirements-00.txt"

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!

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.
> 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:
> 
> > 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
> 
> _______________________________________________
> 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: Xiaoming Fu <[email-masked]>
Date: Fri, 03 May 2002 15:18:19 +0200

Hi Georgios,

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

My comments inline:

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

> Bi-directional reservations are useful in certain unicast (not multicast)

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