Subject: [NSIS] QoS NSLP Proxy mode

From: Roland Bless <[email-masked]>
Date: Thu, 10 Jul 2008 17:47:50 +0200

Hi,

just a quick question for sec 4.8:
I find the dual use of the Proxy flag somewhat confusing.
In particular the draft says:

   For outgoing data flows and sender-initiated reservations, the end
   host is the QNI, and sends a RESERVE with the PROXY scope flag set.
   The P-QNE is the QNR, it will receive the RESERVE, notice the PROXY
   scope flag is set and reply with a RESPONSE (if requested).

a) How can an initiator know that a P-QNE will answer instead of the
   destination end host? (probably the have a prior appl. level
   signaling, but I think it would not be necessary to set the
   proxy bit in the RESERVE).

b) If there is the following use
   "certain region, e.g., for an administrative domain.  A node
   initiating the signaling may set the PROXY scope flag to indicate
   that the signaling is meant to be confined within the area controlled
   by the proxy, e.g., the local access network."
   it may actually conflict with the situation in a) where the QNI
   set the P-bit to indicate proxy use in its domain.

Assume A is the QNR and has to set the P-bit in the RESERVE because
B is not NSIS capable, then Domain 1 may use the P-bit
as scoping indication and drop the RESERVE?
   ---                ------
 /    \              /      \
|A   P |--> .... -->|   P    | B
 \    /              \      /
  ----                ------
Domain 1             Domain 2

My intuitive understanding of a proxy-mode would be:
QNI A sends a normal RESERVE and QNE P in Domain 2
intercepts the RESERVE and acts as proxy (P-QNE) for B.
Thus it sets the P-Bit in the RESPONSE (if one was requested).
A will see that P-bit is set and so conclude that it wasn't
really B who sent the RESPONSE. However, I don't see the
need that A must set the P-bit if the P-QNE in Domain 2
is configured to act as proxy for B.
Furthermore, I would recommend to remove the scope overloading
function of the P-bit as its use would be ambiguous.
Could someone clarify on that, please?

Regards,
 Roland

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 14 Jul 2008 18:26:20 +0300 (EEST)

Hi Roland,

The proxy concept is meant to be used in deployments where we (somehow, 
magically) know that the QNR will not answer the signaling. The recent 
work on RSVP proxies lists several actual deployment cases where proxies 
would work. Sure, you can set up your network such that a certain QNE 
always stops the signaling and possibly replies with RESPONSE (acting as 
a P-QNE).

The use of an explicit bit is meant to make this case clearer in 
mixed-mode scenarios, where some signaling can be e2e and some only local, 
proxied.

The scenario your draw is an example which is difficult to solve, since 
the two domains would need to know about each other. The trick you 
mentiond could be a further refinement, but you make the expectation that 
the QNE in domain 2 knows that the receiving node will not be NSIS aware 
and will not be able to reply with a RESPONSE. The case of nested proxies 
is a difficult one since you would need to have somekind of e2e awareness 
for the last proxy on the path to know there is not QNE beyond it. The 
proxy flag does not cover this case.

The text is not very clear on this, and the "dual use", we'll fix this in 
the next revision, after Magnus's AD review.

Thanks for the comment,
Jukka

---

From: Roland Bless <[email-masked]>
Date: Tue, 15 Jul 2008 16:13:16 +0200

Hi Jukka,

> always stops the signaling and possibly replies with RESPONSE (acting as 

Aside from the magic knowing that the QNR is not the end host, it's
actually clear so far.

> mixed-mode scenarios, where some signaling can be e2e and some only local, 

Do you have an example for this?

> mentiond could be a further refinement, but you make the expectation that 

What trick? I was not aware of mentioning one...

> and will not be able to reply with a RESPONSE. The case of nested proxies 

Yes, that's actually the draft saying that the QNE is configured to act
as proxy for certain end systems. I don't see a big problem with that
information, probably it is well known which terminals support NSIS and
which don't. That would be important for supporting a migration scenario
allowing for increasing NSIS deployment.

> proxy flag does not cover this case.

Yes, every case where you have different configured proxies in
different domains will make it difficult with the scope concept.
On the other hand, NSIS is usually designed for e2e signaling, so
I think it is not very uncommon to cross various domains.

> the next revision, after Magnus's AD review.

That would be great.

Regards,
 Roland