Subject: RE: CRTP and QoS

From: [email-masked]
Date: Tue, 8 Aug 2000 17:03:07 +0300

It's not a good idea due to the delay associated 
with TCP (remember, RTP is Real-time Transport
Protocol). As Dan Wing stated, RTP sequence number
is good and sufficient for that purpose.

Br,
Zhigang

> -----Original Message-----
> From: EXT rafi [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2000 1:25 AM
> To: Dan Wing; Harish Manchaiah
> Cc: [email-masked]
> Subject: Re: CRTP and QoS
> 
> 
> If in order delivery is so important then
> we can run RTP over TCP though
> basic purpose might be defeated,  but
> it all depends on what exactly the requirement
> is.
> 
> Thanks
> Rafi Assadi H.M.
> 
> 
> ----- Original Message -----
> From: Dan Wing <[email-masked]>
> To: Harish Manchaiah <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, August 08, 2000 2:17 AM
> Subject: Re: CRTP and QoS
> 
> 
> > On Mon, 7 Aug 2000 16:22 -0700, Harish Manchaiah wrote:
> >
> > > Hello,
> > >
> > > I am new to this area, please pardon me if it is explained in some
> document
> > > I should have read properly.
> > > I am having trouble understanding the requirements for 
> CRTP and QoS.
> > >
> > > CRTP is applied on link-by-link basis. Can multiple RTP/CRTP
> streams/flows
> > > come into a CRTP interface?
> >
> > Yes, that's why CRTP has a context-ID.
> >
> > > I am assuming it is a valid scenario. If this is true, do 
> we need to
> apply
> > > QoS to each of these flows?
> >
> > Yep.
> >
> > > RFC1889 states that rtp doesn't guarantee QoS or in-order 
> delivery.
> > > Has this been discussed before? Can someone provide some 
> pointers to
> > > this please?
> >
> > IP doesn't guarantee in-order delivery, neither does UDP, 
> neither does
> > RTP.  If in-order delivery is important, the application 
> has to rebuild
> > the packets in the correct order.  With RTP, this 
> reconstruction is done
> > using the sequence number.
> >
> > -Dan Wing
> >
> >
> 
>

---

From: Harish Manchaiah <[email-masked]>
Date: Tue, 08 Aug 2000 10:40:56 -0700

Thanks for the responses. I agree that RTP is responsible for 
reconstructing the frame using rtp sequence numbers.
But if CRTP streams with different QoS are passing through a bundle (ex: 
MLPPP), then MLPPP implementation should
absolutely make sure of sending the packets out in the order it received. 
Otherwise, with current error recovery mechanism
of crtp, you see more context invalidation message than you wanted which 
defeats the purpose of real-time transport.

Does network operators generally carry crtp streams over a multilink bundle?

thanks,
-harish

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 8 Aug 2000 18:17:40 +0200

> absolutely make sure of sending the packets out in the order it received.

The point of the sequence number in Multi-Link PPP (RFC1990) is to make sure
the receiver can reconstitute the order of packets even when the individual
links have different delays (and, possibly, queueing characteristics).

> defeats the purpose of real-time transport.

CRTP, like the PPP suite itself, assumes that there is no reordering on the
link layer -- as it is part of the IPCP NCP and thus on top of multi-link,
this is then a requirement on the way multi-link operates.

Schemes such as multi-class multi-link (RFC2686/2687) require that the
sender is very careful to not put information into different classes
(independent sequence number spaces) that would violate these assumptions.
Unfortunately, I'm not aware that anyone has documented in detail what kinds
of reordering are "safe" and which ones are not.

Gruesse, Carsten

---

From: Scott Keagy <[email-masked]>
Date: Wed, 09 Aug 2000 21:26:57 -0700

Yes, it is common to use CRTP together with MLPPP on Cisco routers in two
applications:

1) Passing CRTP (i.e. VoIP) across load-sharing links with ML-PPP. This is most
often used for ISDN circuits (such as bonded B-channels in an ISDN BRI or PRI
circuit, or even among multiple BRI or PRI circuits) or dial-up async modem
circuits. It is also sometimes used to inverse multiplex T-1/E-1 connections.
2) Using  ML-PPP to support "link fragmentation and interleaving" on a low speed
serial link (to minimize serialization delay). Note that this application is
Cisco's twist on ML-PPP, but it is very important and useful to improve QoS
across low speed serial links that use PPP.

-Scott

--
Scott Keagy, CCIE# 3985
Senior Networking Consultant
SK Networks, Inc.
tel: +1 408 439 8541
mailto:[email-masked]
http://www.sknetworks.com