Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode

From: "Cheng Hong" <[email-masked]>
Date: Tue, 25 Jul 2006 15:14:05 +0800

Hi all,

I would also agree that the proxy mode is very useful and should be
included into the QoS-NSLP draft. However, regarding the operation
procedure mentioned by Jukka below, I have some questions:

> >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender]
>
<snip>
>
> >For incoming flows, the end host is also the QNI, and it sends a 
> >RESERVE towards the data sender with the proxy-scope bit 
> set. Here the 
> >end host sets the MRI so that it indicates the end host as 
> the receiver 
> >of the data, and the D-flag is set. If there is only one 
> P-QNE in the 
> >domain, GIST gets the RESERVE to the P-QNE. If there are 
> more than one 
> >P-QNEs, GIST will do its best, but may reply with an error 
> indicating 
> >destination unreachable.

How does this work? When the data path is asymmetric, how could the
P-QNE be identified from the receiver (End Host) side?

cheers

Cheng Hong

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Monday, July 17, 2006 6:23 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Proposal for implementing QoS NSLP Proxy Mode
> 
> 
> Hi Jukka
> 
> Great!
> I think that the use of the QoS-NSLP proxy mode is useful and 
> the additional complexity introduced in the QoS-NSLP by this 
> mode is not big.
> Therefore, I agree to include it in the QoS-NSLP draft.
> 
> Best regards,
> Georgios
> 
> On 7/16/2006, "Jukka MJ Manner" <[email-masked]> wrote:
> 
> >
> >We had a good discussion with Robert about the QoS NSLP 
> Proxy mode, and 
> >at the end we agreed that the QoS NSLP does not really need much. 
> >Actually, we only need a new scope (besides single link and 
> e2e) called e.g.
> >"proxy", and the domain admin must define manually, which 
> QNE operates 
> >as proxy (Proxy-QNE, P-QNE). Here is how the fing works:
> >
> >[End host/QNI] - [QNE] - ... [P-QNE] ... [data receiver or sender]
> >
> >For outgoing flows, the end host is the QNI, and sends a 
> RESERVE with 
> >the new proxy-scope bit set. The P-QNE will receive the RESERVE and 
> >reply with a RESPONSE (if requested), and NOT forward the RESERVE 
> >further to the next peer. The receiver-oriented reservation 
> works the 
> >same way (QUERY towards P-QNE, RESERVE back, then RESPONSE to P-QNE, 
> >all carrying the proxy-scope bit).
> >
> >For incoming flows, the end host is also the QNI, and it sends a 
> >RESERVE towards the data sender with the proxy-scope bit 
> set. Here the 
> >end host sets the MRI so that it indicates the end host as 
> the receiver 
> >of the data, and the D-flag is set. If there is only one 
> P-QNE in the 
> >domain, GIST gets the RESERVE to the P-QNE. If there are 
> more than one 
> >P-QNEs, GIST will do its best, but may reply with an error 
> indicating 
> >destination unreachable.
> >
> >Jukka
> >
> >ps. I'll be out of emails for a couple of weeks now. I intend to 
> >finalize the QoS NSLP draft in August and we can then send 
> it for AD review.
> >
> >_______________________________________________
> >nsis mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> 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: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Jul 2006 10:13:35 +0100

hi cheng hong,

> P-QNE be identified from the receiver (End Host) side?

basically, this is known and accepted to be a Hard Problem. 
because it is a problem about message routing, the proposal
for the QoS-NSLP (as I discussed it with Jukka and Andy) is
that this hard problem should be delegated to GIST. what's
then necessary is for GIST to be able to set up routing state
upstream for the MRMs that the QoS-NSLP uses (which is just the
path-coupled MRM). 

GIST includes functionality to achieve this (see section 5.8.1.3).
it only works in a limited range of environments, but it does
work robustly in there, and it covers the key scenarios where
this functionality is needed in practice. if we want the proxy 
mode in more general scenarios, the right way to achieve that
is to work on solving the reverse routing problem in general,
and extending GIST in that direction.

see http://www1.ietf.org/mail-archive/web/nsis/current/msg04537.html
for further background on how this got into GIST.

r.

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 25 Jul 2006 18:23:33 +0800

Hi Robert,

Thanks a lot for pointing out the information. Will check the details
when I go back to the office.

Delegating the problem to GIST is a reasonable choice, since it is a
general issue for all NSLP applications. Extending GIST for a general
solution sounds interesting. I guess it may also be part of the MRM
Pattern discussions.

cheers

Cheng Hong

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 5:14 PM
> To: Cheng Hong; Georgios Karagiannis; [email-masked]; 
> [email-masked]
> Cc: Toyoki Ue; Pek Yew Tan; Takako Sanda
> Subject: RE: [NSIS] Proposal for implementing QoS NSLP Proxy Mode
> 
> hi cheng hong,
> 
> upstream for the MRMs that the QoS-NSLP uses (which is just 
> the path-coupled MRM). 
> 
> this functionality is needed in practice. if we want the 
> proxy mode in more general scenarios, the right way to 
> achieve that is to work on solving the reverse routing 
> problem in general, and extending GIST in that direction.
> 
> > > I think that the use of the QoS-NSLP proxy mode is useful and the 
> > > additional complexity introduced in the QoS-NSLP by this 
> mode is not 
> > > big.