Subject: [NSIS] Re: comments Issue (8) included in draft-ietf-nsis-req-01

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

What is the value of bi-directional session setup?
The cost IMO are the higher complexity in QI and QRs handling a 
bi-directional setup in one transaction. I think there are problems in 
error cases (what does it mean if one part has not been setup etc.)

IMO we should exlude bi-directional setup completly.

Marcus

--On Monday, April 22, 2002 10:30 AM +0200 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> Hi Marcus
>
> Please receive my comments on Issue (8) included in the
> NSIS WG draft: draft-ietf-nsis-req-01.txt
>
> Comment on Issue (8):
>
>>    8) (OPEN) bi-directional data path setup with one QoS request
>>    I have not seen consensus on whether to require bi-directional data
>>    path setup with QoS.
>>    - How can we actually perform bi-directional reservations when the
>>    forward and reverse paths are not reciprocal, with respect to
>>    routing topology and routing policy of network domains between
>>    sender and receiver?
>>    - The need to ensure that the return path is the same as the
>>    forwarding path is one of the problems with RSVP, particularly in a
>>    mobile environment.
>
> [GK] The bi-directional data path setup does not need to use the same
> [GK] return path as the forwarding path. The only requirement to achieve
> [GK] a bi-directional reservation is that the sender for the forwarding
> path [GK] is also the receiver for the return path and that the receiver
> for the  [GK] forwarding path is also the sender for the return path.
> [GK] Therefore, I think that the bi-directional option should not be
> mandatory [GK] but at least optional;
> --------------
>
>
>
> Best regards,
> Georgios
>
>
>

--------------------------------------
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: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 3 May 2002 18:07:25 -0400

Let me use this requirement as an example of the aspects of NSIS work that
confuse me over and over again. I hope somebody will help me to sort it out:

What are we trying to say here? In my mind we want that protocol(s) be able
to express an idea of bi-directional reservation. In addition we want to say
that support by the QCs of the bi-directional reservation is optional. But
combination of these ideas is not properly expressed neither by the
statement proposed by John not by Georgios.

Regards,
Ilya

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Monday, April 22, 2002 10:49 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01

Hi John

Yes, I agree the bi-directional requirement is an optional requirement!

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 22 april 2002 15:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (8) included in
draft-ietf-nsis-req-01

Hi,

> [GK] a bi-directional reservation is that the sender for the
> forwarding path
> [GK] is also the receiver for the return path and that the
> receiver for the
> [GK] forwarding path is also the sender for the return path.
mandatory
> [GK] but at least optional;

Perhaps 'Bi-directional QoS requests MAY be possible' is enough.

John

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Sun, 5 May 2002 19:42:45 -0400

Bob,

The topic of my posting was not really the bi-directional reservation but my
(and maybe group's as well) confusion with the difference between the
protocol requirements and requirements to support various parts of the
protocol by the implementations.
Speaking of the bi-direction reservations my impressions from what was said
on this list is that in some mobile environments it has advantage or
preferred over unidirectional. 

Ilya

-----Original Message-----
From: Bob Braden [mailto:[email-masked]]
Sent: Friday, May 03, 2002 7:33 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01

  *>
  *> Let me use this requirement as an example of the aspects of NSIS work
that
  *> confuse me over and over again. I hope somebody will help me to sort it
out:
  *>
  *> What are we trying to say here? In my mind we want that protocol(s) be
able
  *> to express an idea of bi-directional reservation. In addition we want
to say
  *> that support by the QCs of the bi-directional reservation is optional.
But
  *> combination of these ideas is not properly expressed neither by the
  *> statement proposed by John not by Georgios.
  *>
  *> Regards,
  *> Ilya

I am sure I am missing something, but I don't know what you mean by
a "bidirectional reservation".  If you mean that both directions use
the same path, that won't work for the Internet, where the data may
use different paths.

What am I missing?

Bob Braden

  *>
  *> -----Original Message-----
  *> From: Georgios Karagiannis (ELN)
  *> [mailto:[email-masked]]
  *> Sent: Monday, April 22, 2002 10:49 AM
  *> To: [email-masked]'; [email-masked]
  *> Cc: [email-masked]
  *> Subject: RE: [NSIS] comments Issue (8) included in
draft-ietf-nsis-req-01
  *>
  *> Hi John
  *>
  *> Yes, I agree the bi-directional requirement is an optional requirement!
  *>
  *> Best regards,
  *> Georgios
  *>
  *> -----Original Message-----
  *> From: [email-masked] [mailto:[email-masked]]
  *> Sent: maandag 22 april 2002 15:35
  *> To: [email-masked]; [email-masked]
  *> Cc: [email-masked]
  *> Subject: RE: [NSIS] comments Issue (8) included in
  *> draft-ietf-nsis-req-01
  *>
  *>
  *> Hi,
  *>
  *> > Please receive my comments on Issue (8) included in the
  *> > NSIS WG draft: draft-ietf-nsis-req-01.txt
  *> >
  *> > Comment on Issue (8):
  *> >
  *> > >    8) (OPEN) bi-directional data path setup with one QoS request
  *> > >    I have not seen consensus on whether to require
  *> > bi-directional data
  *> > >    path setup with QoS.
  *> > >    - How can we actually perform bi-directional
  *> > reservations when the
  *> > >    forward and reverse paths are not reciprocal, with respect to
  *> > >    routing topology and routing policy of network domains between
  *> > >    sender and receiver?
  *> > >    - The need to ensure that the return path is the same as the
  *> > >    forwarding path is one of the problems with RSVP,
  *> > particularly in a
  *> > >    mobile environment.
  *> >
  *> > [GK] The bi-directional data path setup does not need to use the same
  *> > [GK] return path as the forwarding path. The only requirement
  *> > to achieve
  *> > [GK] a bi-directional reservation is that the sender for the
  *> > forwarding path
  *> > [GK] is also the receiver for the return path and that the
  *> > receiver for the
  *> > [GK] forwarding path is also the sender for the return path.
  *> > [GK] Therefore, I think that the bi-directional option should not be
  *> mandatory
  *> > [GK] but at least optional;
  *>
  *> Perhaps 'Bi-directional QoS requests MAY be possible' is enough.
  *>
  *> 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: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 6 May 2002 12:32:22 +0200

Hi Bob

>> the same path, that won't work for the Internet, where the data may

No, by "bi-directional reservation" we define a resource reservation 
that applies on both directions, i.e., on the path from sender to receiver 
and on the path from receiver to sender, which is  initiated and maintained 
by only one of the end points, e.g., the sender.
Please note that the path from sender->receiver can be different than
the path from receiver->sender.
In this way a simpler edge-proxy resource reservation functionality will
be implemented in the one of the end points, decreasing its complexity.

Best regards,
Georgios

-----Original Message-----
From: Bob Braden [mailto:[email-masked]]
Sent: zaterdag 4 mei 2002 1:33
To: [email-masked]; [email-masked];

  *> 
  *> Let me use this requirement as an example of the aspects of NSIS work that
  *> confuse me over and over again. I hope somebody will help me to sort it out:
  *> 
  *> What are we trying to say here? In my mind we want that protocol(s) be able
  *> to express an idea of bi-directional reservation. In addition we want to say
  *> that support by the QCs of the bi-directional reservation is optional. But
  *> combination of these ideas is not properly expressed neither by the
  *> statement proposed by John not by Georgios.
  *> 
  *> Regards,
  *> Ilya

What am I missing?

Bob Braden

  *> 
  *> Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01