Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation

From: "Cheng Hong" <[email-masked]>
Date: Mon, 9 Oct 2006 18:27:27 +0800

Hi Georgios,

After rethinking about the issue, I have a few questions about the error case you mentioned. 

Is this retransmission procedure at NSLP layer or at the transport layer? For the later case, does it mean the reliable transport is supported? (that is what the re-transmission is for) Then, it seems that RP would not be lost(it would be retransmitted from Router2 to Router1). 

For the earlier case, does the NSLP layer need a timer to decide when to do retransmission? In that case, after send RP, the Router2 could just keep the NSLP state until the timer expires (this should not matter since the actual resources are already released). Would this avoid the error case?

cheers

Cheng Hong

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Monday, October 09, 2006 5:27 PM
> To: Cheng Hong; 'Jukka MJ Manner'
> Cc: [email-masked]
> Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation
> 
> Hi Cheng Hong
> 
> Sorry I meant:
> But we cannot always assume that these criteria are met. That 
> is why we are using the retransmission procedure for RESERVE messages.
> 
> Best Regards,
> Georgios
> 
> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: maandag 9 oktober 2006 11:24
> To: 'Cheng Hong'; 'Jukka MJ Manner'
> Cc: [email-masked]
> Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation
> 
> Hi Cheng Hong
> 
> But we cannot always assume that these criteria are met. That 
> is why we are using the retransmission procedure!
> 
> Best Regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Cheng Hong [mailto:[email-masked]]
> Sent: maandag 9 oktober 2006 11:14
> To: Georgios Karagiannis; Jukka MJ Manner
> Cc: [email-masked]
> Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation
> 
> Hi Georgios,
> 
> Sounds that we need a reliable tranport for the Response.
> 
> I think the problem you pointed out could be solved by 
> setting the criteria of removing of the state to when the RP 
> is successfully forwarded the next hop, i.e. Router1. 
> 
> Of course, if the transport layer does not support Ack, we 
> may need to resort to the solution you suggested, i.e. 
> disallow restransmission of RS.
> 
> What do you think?
> 
> cheers
> 
> Cheng Hong 
> 
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:[email-masked]]
> > Sent: Monday, October 09, 2006 4:50 PM
> > To: 'Jukka MJ Manner'; Cheng Hong
> > Cc: [email-masked]
> > Subject: RE: [NSIS] A question to people about QoS NSLP 
> Tear operation
> > 
> > Hi Jukka
> > 
> > The problem that I have with the retransmission of tear 
> RESERVE is the
> > following:
> > 
> > Consider the following scenario:
> > 
> > QNI <----> Ruoter1 <-----> Router2 <------> QNR
> >  
> >      RS             RS               RS
> >     ---->          ------>         ----->
> >                        RP             RP
> >               XX   <-----          <----
> > 
> > 
> > Note that RS is assumed to be a tear RESERVE that carries a RII 
> > object.
> > RP is assumed to be a RESPONSE. Based on what we have discussed in 
> > previous e-mails, QNR will remove the state and
> > Router2 will remove the state when the RESPONSE arrives at Router2.
> > 
> > However, the tear RESPONSE is lost before reaching Router1 (this is 
> > shown by XX in above figure).
> > This means that the QNI will retransmit the tear RESERVE.  
> > This retransmitted tear RESERVE will be processed by 
> Router1 since the 
> > state is not released, but when the tear RESERVE is sent to 
> Router2 it 
> > will not be able to be processed since the state has been removed 
> > earlier. Router2 will generate an error RESPONSE message.
> > This error RESPONSE message will again not remove the state in 
> > Router1.
> > I am afraid that this problem cannot be easily solved.
> > 
> > A solution could be to disalow retransmissions when the 
> tear RESERVE 
> > messages are generated by the QNI. If the QNI does not receive a 
> > RESPONSE for the tear RESERVE then it will assume that an error 
> > occurred, but it will know that the release of all resources is 
> > accomplished by the soft state.
> > 
> > 
> > Best Regards,
> > Georgios
> >  
> > 
> > -----Original Message-----
> > From: Jukka MJ Manner [mailto:[email-masked]]
> > Sent: maandag 9 oktober 2006 10:29
> > To: Cheng Hong
> > Cc: [email-masked]
> > Subject: RE: [NSIS] A question to people about QoS NSLP 
> Tear operation
> > 
> > 
> > Sounds like a good plan.
> > 
> > Jukka
> > 
> > On Mon, 9 Oct 2006, Cheng Hong wrote:
> > 
> > > Hi Jukka,
> > > 
> > > How about when a QNE receives a TEAR, it free the resources of the
> > reservation (that is a job of RMF), but keep the NSLP state (marked 
> > with a
> > flag) for the confirmation? In this case, no network 
> resources would 
> > be wasted, and the error message could be still correctly 
> processed by 
> > the previous hop. Then, the solution you mentioned earlier could be 
> > used, e.g.
> > the NSLP state to be removed after a timeout, etc.
> > > 
> > > cheers
> > > 
> > > Cheng Hong
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jukka MJ Manner [mailto:[email-masked]]
> > > > Sent: Sunday, October 08, 2006 12:37 AM
> > > > To: David Palma
> > > > Cc: [email-masked]
> > > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear 
> > > > operation
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > That is exactly what I have written in my editor's copy
> > currently. 
> > > > Furthermore, I had an idea for a small additional functionality.
> > > > 
> > > > When a QNE sends forward a tear, how long should it 
> wait for the 
> > > > RESPONSE to come back through towards the QNI? I think 
> we have to 
> > > > have some time limit how long we still keep the 
> resources. I was 
> > > > thinking of "one refresh interval". At the expiry of the time 
> > > > interval, the QNE will remove the reservation. A QNE must
> > also stop
> > > > sending periodic refresh messages, even if one was
> > earlier scheduled
> > > > to be sent. This should not happen, if we consider that
> > proper timer
> > > > management makes sure that if a node gets any RESERVE 
> message, it 
> > > > removes it's pending refresh timer, and possibly restart it.
> > > > 
> > > > Regards,
> > > > Jukka
> > > > 
> > > > On Sat, 7 Oct 2006, David Palma wrote:
> > > > 
> > > > > Hi Jukka and all,
> > > > > 
> > > > > I agree with everything said in your previous email but
> > > > would like to
> > > > > ask a question and suggest some other option.
> > > > > 
> > > > > Regarding the second option, by maintaining the reservation
> > > > state for
> > > > > a certain period of time (almost like soft stat on the
> > > > first option),
> > > > > if there is no error and the QNI has not included the RII
> > > > object (it
> > > > > is not mandatory right?). We will have a waste of resources
> > > > on every
> > > > > peer except on the QNR for every successful reservation.
> > > > > 
> > > > > With the first option we only waste some resources when
> > there is
> > > > > an error (which is not probable as success) and this waste of
> > > > resources
> > > > > only affects the peer that produced the error and forward.
> > > > > 
> > > > > Although the first option still seems to me less wasteful,
> > > > none of the
> > > > > options are perfect. From my point of view a mix of the two 
> > > > > options would be perfect.
> > > > > 
> > > > > My proposal is:
> > > > > 
> > > > > If a RESERVE with the TEAR flag set is sent every peer should 
> > > > > check for the presence of the RII object. If this one
> > exists, the
> > > > > state should not be removed until it receives a successful
> > > > REPONSE from the
> > > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts
> > > > accordingly).
> > > > > 
> > > > > If it does not exists the state should be immediately
> > > > removed and if
> > > > > there is some kind of error the soft state will take care
> > > > of removing
> > > > > all the remaining resources on the path.
> > > > > 
> > > > > 
> > > > > I hope that I have understood everything correctly 
> and that my 
> > > > > proposal makes sense to you.
> > > > > 
> > > > > Best Regards,
> > > > > David Palma
> > > > > 
> > > > > 
> > > > > -----Mensagem original-----
> > > > > De: Jukka MJ Manner [mailto:[email-masked]]
> > > > > Enviada: sábado, 7 de Outubro de 2006 9:39
> > > > > Para: Bernd Schloer
> > > > > Cc: [email-masked]
> > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP
> > > > Tear operation
> > > > > 
> > > > > 
> > > > > Hi all,
> > > > > 
> > > > > Actually the proposed solution will not work. When any
> > QNE gets a
> > > > > tearing RESERVE without RII, the QNE accepts it, removes the 
> > > > > reservations, and sends it further to the next hop. Now, if
> > > > this next
> > > > > hop gets into an error situation, it is basically useless
> > > > to send an
> > > > > error message even to its previous hop (not to mention the
> > > > QNI), since
> > > > > it has already removed the reservation, and its
> > associated state -
> > > > > only GIST MA is probably still available, but not QoS
> > NSLP state.
> > > > > 
> > > > > Thus, we seem to have two options:
> > > > > 
> > > > > a) Just note in the spec, that sending error messages
> > > > related to the
> > > > > processing of a tearing RESERVE is uselsss, or
> > > > > 
> > > > > b) define that a QNE SHOULD keep the reservation state for
> > > > a period of
> > > > > X before finally removing the state. This would allow
> > > > processing of a
> > > > > error related to tearing. Still, what could a QNE do
> > different then?
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > Jukka
> > > > > 
> > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote:
> > > > > 
> > > > > > Sounds good to me.
> > > > > > 
> > > > > > Bernd
> > > > > > 
> > > > > > 
> > > > > > Jukka MJ Manner wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Good point, in most cases this would work. And if
> > there is an
> > > > > > > error the previous QNEs did not have, most probably the
> > > > QNI is not
> > > > > > > anymore able to help either, since it has removed, and
> > > > lost, all NSLP states it had.
> > > > > > > 
> > > > > > > Thus, if there is no RII in the tearing RESERVE, any
> > > > error in the
> > > > > processing
> > > > > > > should be propagated to the previous hop, but not further.
> > > > > > > 
> > > > > > > Jukka
> > > > > > > 
> > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > >Is it important to send the error message back to the
> > > > QNI?  What
> > > > > > > >can
> > > > > the
> > > > > > > >QNI
> > > > > > > >do
> > > > > > > >QNE2 can't do? It would be more scalable for the
> > > > network to send
> > > > > > > >the
> > > > > error
> > > > > > > >message
> > > > > > > >not further than QNE2. The QNI has not requested a
> > > > confirmation. 
> > > > > > > >QNE2
> > > > > can
> > > > > > > >take
> > > > > > > >over the role of the QNI and take care about
> > removing state.
> > > > > > > >
> > > > > > > >Bernd
> > > > > > > >
> > > > > > > >
> > > > > > > >Jukka MJ Manner wrote:
> > > > > > > >
> > > > > > > > >Yes, that is something I was thinking. Still, 
> we have a 
> > > > > > > > >small
> > > > > performance
> > > > > > > > >problem if no RESPONSE is requested, but there is an
> > > > error in
> > > > > > > > >the processing of a tearing RESERVE.
> > > > > > > > >
> > > > > > > > >E.g., we have
> > > > > > > > >
> > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR
> > > > > > > > >
> > > > > > > > >1. QNI asks to remove a reservation, without
> > confirmation 2. 
> > > > > > > > >QNE1 does that, asks GIST remove the state, and
> > sends the
> > > > > > > > >requests
> > > > > to
> > > > > > > > >QNE2
> > > > > > > > >3. QNE does the same and sends the message to
> > QNE3 4. QNE3
> > > > > > > > >noticies some error situation, and sends an 
> error message
> > > > > towards
> > > > > > > > >the QNI
> > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and 
> QNE3 can send 
> > > > > > > > >the error to
> > > > > > > > >QNE2
> > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards
> > > > QN1, thus,
> > > > > > > > >it
> > > > > needs
> > > > > > > > >to
> > > > > > > > >set up one
> > > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI.
> > > > > > > > >
> > > > > > > > >Thus, phases 6 & 7 get us a performance penalty,
> > but if we
> > > > > > > > >consider
> > > > > that
> > > > > > > > >a
> > > > > > > > >tear in the common case does not fail in the
> > middle of the
> > > > > > > > >network,
> > > > > then
> > > > > > > > >we
> > > > > > > > >could just follow the procedure above.
> > > > > > > > >
> > > > > > > > >Anyway, if people are fine with the above, I'll
> > > > introduce this
> > > > > > > > >functionality to the spec. Then we are done with it,
> > > > and ready
> > > > > > > > >for either another
> > > > > WGLC,
> > > > > > > > >or
> > > > > > > > >AD review.
> > > > > > > > >
> > > > > > > > >Jukka
> > > > > > > > >
> > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >Hi Jukka,
> > > > > > > > > >
> > > > > > > > > >what if the QNE asks GIST to remove routing
> > state after
> > > > > > > > > >receiving
> > > > > the
> > > > > > > > > >RESPONSE
> > > > > > > > > >to the tearing RESERVE when requested or
> > directly when no
> > > > > > > > > >response
> > > > > is
> > > > > > > > > >requested?
> > > > > > > > > >
> > > > > > > > > >Bernd
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >3. If either, or both, should be made possible
> > > > by the spec,
> > > > > > > > > > >how
> > > > > would
> > > > > > > > > > >this
> > > > > > > > > > >  affect GIST? A QNE gets a tearing RESERVE, it
> > > > removes the
> > > > > > > > > > >state
> > > > > > > > > > >  (1),
> > > > > > > > > > >  forwards the message towards the next 
> QNE (2), and 
> > > > > > > > > > >may ask GIST
> > > > > to
> > > > > > > > > > >  remove
> > > > > > > > > > >  any routing state for this session. Now,
> > if this QNE
> > > > > > > > > > > later gets  back  an  error message, or a
> > > > RESPONSE, for a
> > > > > > > > > > > session it no longer knows,  what  does
> > the QNE do? 
> > > > > > > > > > > Re-set up routing state towards the QNI 
> using GIST,
> > > > > and
> > > > > > > > > > >  send
> > > > > > > > > > >  the message forward?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > 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: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 9 Oct 2006 13:38:48 +0200

Hi Cheng Hong

The retransmissions are at the NSLP layer, see Section 5.2.4 in:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt

Regarding the timer, what you actually mean is to keep the state 
for a time equal, to a timer, even if a RESPONSE is 
processed correctly.
The question is for how long should this state be kept.

Please note that similar errors followed by retransmissions might occur 
until the time: QOSNSLP_RETRY_MAX, see Section 5.2.4, 
that is smaller or equal to refresh period.

This is because in worst case, similar errors might occur in 
different locations in the network during different retransmissions 
of the tear RESERVE message.

Thus I do not see many advantages when introducing this 
additional complexity into the nodes.

Best Regards,
Georgios

> Sent: maandag 9 oktober 2006 12:27
> Is this retransmission procedure at NSLP layer or at the 
> transport layer? For the later case, does it mean the 
> reliable transport is supported? (that is what the 
> re-transmission is for) Then, it seems that RP would not be 
> lost(it would be retransmitted from Router2 to Router1). 
> 
> For the earlier case, does the NSLP layer need a timer to 
> decide when to do retransmission? In that case, after send 
> RP, the Router2 could just keep the NSLP state until the 
> timer expires (this should not matter since the actual 
> resources are already released). Would this avoid the error case?
> 
> cheers
> 
> Cheng Hong
> 
> 
>  
> 
> > But we cannot always assume that these criteria are met. 
> That is why 
> > we are using the retransmission procedure for RESERVE messages.
> > 
> > Best Regards,
> > Georgios
> > 
> > But we cannot always assume that these criteria are met. 
> That is why 
> > we are using the retransmission procedure!
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > I think the problem you pointed out could be solved by setting the 
> > criteria of removing of the state to when the RP is successfully 
> > forwarded the next hop, i.e. Router1.
> > 
> may need to 
> > resort to the solution you suggested, i.e.