Subject: [NSIS] bi-directional signaling

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

Hi all,

Ilya said:

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

[clip]

Bob said:

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

Bi-directional signaling in NSIS SHOULD only be about the
signaling, not about the nature of the reservation.  It is
my opinion that, within NSIS, the path which the data 
takes maybe an orthoginal issue.

For the requirements draft, the issue if bi-directional signaling
should only apply to if an endpoint signals both the inbound/outbound,
uplink/downlink, sending/receiving (pick your favorite terminology)
QoS needs. 

I wouldn't mind that a NSIS protocol support this, so a MAY or 
SHOULD would be nice to have in the requirements.

John

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 08 May 2002 17:34:51 +0200

Hi John,

> takes maybe an orthoginal issue.

IMO it is not completely orthogonal (although data and signaling path
may be different) and depends largely on the environment. For instance,
in a DiffServ scenario, the reservation of path resources is usually set
up in a two-way sequence from the sender down to the receiver and back,
because traffic conditioning elements (token buckets/shapers etc.) have
to be adapted upstream while processing the response. Otherwise marked
packets may affect adversely other reservations or may be dropped
downstream. This is an example were data path mechanisms imply also an
NSIS signaling sequence order.

However, there are possibilities to have also receiver-initiated
reservations, but usually at some higher cost of a 4-way message
exchange (also due to asymmetric paths), e.g. receiver directly asks
the sender to set up a reservation for him. Furthermore, receiver 
initiation can and should be easily supported for multicast flows.

> uplink/downlink, sending/receiving (pick your favorite terminology)

You mean to signal a bi-directional reservation in a single request?

> SHOULD would be nice to have in the requirements.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097