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

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

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

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: May 7, 2002 05:53
> 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
> 
> 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
> 
> 
> 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,
> 
> > 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
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 08 May 2002 08:52:15 +0200

Gary,

I agree with you. While sender-initiated has advantages for many 
scenarios, limiting it as MUST for the requirement may implicate 
incompatiability with some other scenarios or complexity in e2e 
negotiation/interaction.

Regards,
Xiaoming

> Gary Kenward wrote:

--
Xiaoming Fu 
[email-masked]
http://www-tkn.ee.tu-berlin.de/