RE: [Tsvwg] Rr:Comments on draft-lefaucheur-rsvp-dste-02.txt

Hi Francois,

See my comments in-line.

Rurick

On Wed, 2005-03-09 at 16:05, Francois Le Faucheur (flefauch) wrote:
> Hi Rurick,
>         
>         ______________________________________________________________
>         From: Rurick Kellermann [mailto:rurick@nortel.com] 
>         Sent: mercredi 9 mars 2005 20:53
>         To: Francois Le Faucheur (flefauch)
>         Cc: tsvwg@ietf.org
>         Subject: Re: [Tsvwg] Rr:Comments on
>         draft-lefaucheur-rsvp-dste-02.txt
>         
>         
>         
>         Francois, 
>         
>         Each of the hosts issuing a RESV is waiting for an approval of
>         its
>         request. When aggregation is performed, one might have the
>         case where
>         the aggregate of the reservation could fail due to b/w, etc.  
>         
>         In that case, a) shouldn't the aggregator inform the
>         individual hosts
>         with a PathErr message? 
>         [FLF:] Remember that with RSVP the reservation is controlled
>         by the destination (which issues the Resv). In case of CAC
>         failure, you want to notify the destination and the way to do
>         that is to send a ResvErr.

RK: Agreed. My typo - meant to type ResvErr,

>          The source need not be informed about the CAC failure.

RK: Agreed. 
>         
>         In the context of achieving CAC for VoIP, the destination ,
>         upon receipt of a ResvErr, would then notify its Call Manager
>         (eg SIP Proxy/Server) that the reservation (aka "SIP
>         precondition") is not met. The CAll Manager woul take
>         appropriate action (eg abort call setup and return some tone
>         indicating network busy).

RK: Agreed. However, IMO, Section 3.5 could benefit with the explanation
that the source issues an E2E RESVErr which is issued instead of all the
individual RESV Err. messages? In other words, this is the advantage of
aggregation capabilities.

>         
>          b) if the condition which caused the PathErr
>         message persists, say due to insufficient b/w for the
>         aggregate, 
>          some
>         individual requests could have obtained a PATH if they had
>         been
>         responded individually (i.e. through a PATH message instead of
>         an
>         E2EPATH).
>         [FLF:] I am not quite with you. Say we have a TE tunnel with
>         bandwidth B which can currently fit 10 calls. Say, we have 10
>         calls that try to get established. Each source will send a
>         Path, ecah destination will send a Resv which will all be
>         accepted by CAC over teh tunnel. Say another 5 calls come and
>         the Tunnel head-end can increase the Tunnel size to fit total
>         of 15 calls. Then the 5 additional calls will get accepted.
>         Say another 5 calls come in, and say teh TE tunnel Head-end
>         can no longer increase teh TE Tunnel size. Then each source
>         for these 5 last call will send a Path and each destination
>         will send a Resv. Each Resv will be rejected by CAC on teh
>         tunnel headend and a ResvErr (with error cause "no bandwidth")
>         will be generated by teh tunnel head-end towards each
>         destination.

RK: What I meant in b) was: there are already 15 calls and the TE Tunnel
Head-end can increase the tunnel to accept 2 more calls instead of 5.
With the E2E ResvErr. 5 calls would be rejected, instead of 3 if
individual ResvErrs. had been received. At this point it is up to the
application to throttle the reservation requests, which is
implementation specific. Can your explanation above be included? Also,
any intention of adding capability to accept the  'not 5 but 3' reply?

Thanks for your replies...

Cheers, Rurick
>         
>         Does that clarify?
>         
>         Francois
>         
>         Regards,
>         
>         Rurick
>         
>         
>         > >> 5) Section 3.6
>         > >> 
>         > >> On a reservation failure at the aggregator, is a PathErr 
>         > >> also sent out
>         > >> upstream (towards sender) ?
>         >  
>         > I don't believe so.
>         > In regular RSVP, Path Err report errors in the processing of
>         Path
>         > messages. In case of CAC rejection on the Resv, we should
>         just send a
>         > ResvhErr. The destination may decide to try make a smaller
>         reservation
>         > or try a different Intserv service. Everything is normal as
>         far Path is
>         > concerned.
>         > 
>         > >> Finally, you may want to mention somewhere (just to
>         prevent 
>         > >> confusion)
>         > >> that these reservations are assumed to be unidirectional.
>         >  
>         > We can state that. But RSVP reservations are unidirectional
>         of course,
>         > so sas there something specific that you feel would create
>         confusion?
>         > 
>         > Thank you for your review an comments.
>         > 
>         > Francois
>         > 
>         > >> thanks,
>         > >> -arthi
>         > >> 
>         > 
>         > _______________________________________________
>         > tsvwg mailing list
>         > tsvwg@ietf.org
>         > https://www1.ietf.org/mailman/listinfo/tsvwg
>         > 
>         