Subject: RE: [NSIS] bi-directional signaling

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 7 May 2002 10:51:54 +0200

Hi 

I agree with John!

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 7 mei 2002 2:03
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [NSIS] bi-directional signaling

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

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

---

From: [email-masked]
Date: Fri, 10 May 2002 11:33:17 +0300

Hi Roland,

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

I actually meant that in the discussion at hand it was orthoginal, as
NSIS is not working on resource reservation.  In summary, the
nature of the reservation is a different issue (and one which we 
are not trying to solve in NSIS) than what & how the user requests it.
 
> You mean to signal a bi-directional reservation in a single request?

We are not talking about bi-directional reservations in NSIS.  
Reservation mechanisms are out of scope, and something that we are not
chartered to do.

What I mean is that, for example, if we support sender-initiated
requests, we may wish to support bi-directional requests.  So,
I ask for 512K bw upstream and 256k bw downstream, for exampe ... 

John