Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting

From: "Gary Kenward" <[email-masked]>
Date: Thu, 26 Jul 2001 17:50:03 -0400

Michael:

 Sorry for the confusion. I agree that if you are willing
to accept duplicates, much of the problem goes away. However,
duplicate removal can be a tad nasty for real time services,
depending upon the time latency between received copies. That
is, if you know that the duplicates always arrive together,
then you can use a very short (two packet) buffer, but if the
duplicates can be 10s of packets apart, not only do you need 
more memory, but you likely have to spend more time searching the
buffer for duplicates. This search time is usually the main
difficulty for real time duplicate removal.

But you probably are more familiar with these issues then I am.

As a side issue, I don't see why anything really special needs to
be done for TCP. TCP is designed around best effort delivery, and
as long as you keep within the rather generous limits of a best 
effort service (which means you can buffer for a very long time),
everything should be fine (I'm presuming here that 4G, if not
3G, gets beyond the long, thin pipe problem).

Cheers,
Gary

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: July 26, 2001 13:34
> To: [email-masked]
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
> 
> 
> Gary Kenward writes:
>  > > From: James Kempf [mailto:[email-masked]]
>  > > In the case of 1, the probability of a duplicate packet 
> has nothing
>  > > whatsoever to do with the radio link. It is purely a 
> matter of traffic
>  > > engineering in the wired network. So the probability of 
> a duplicate
>  > > packet can be reduced by properly engineering the wired 
> network. In
>  > > addition, the probability is likely to increase with the 
> topological
>  > > distance between the new AR and the source of the bicast (simply
>  > > because, the more network a packet has to traverse, the 
> more likely
>  > > it is that a congestion event may cause delay). Since engineering
>  > > of the wired network is largely under the network 
> operator's control,
>  > > this problem is fairly straightforward to solve, though it may
>  > > require measures such as over provisioning.
>  > 
>  > Well, it takes more then over provisioning. You need to ensure
>  > the same number of hops between the bicasting source (the traffic
>  > bifurcation
>  > point if you will), and you also need to provide some 
> guaranteed bounds on
>  > the delay at each hop after the bicasting source. *if* you 
> want to ensure no
>  > duplicates
>  > at all at the receiver. This may seem like a definition of EF, but
>  > consider that the constraint is much more severe then that 
> of EF. With
>  > EF the bound is on inter-packet delay and delay jitter for 
> a single stream.
>  > With bicasting, the bound is on the arrival delay of two 
> copies of the
>  > same packet that traverse different paths through N hops. 
> The maximum
>  > delay difference, I believe, is one packet duration, T. 
> Thus, the delay 
>  > difference bound at each hop must roughly be T/N (the 
> relationship is
>  > not linear, but this gives a rough approximation). If the source of
>  > the delay is from queuing, then this would imply that there can be
>  > no other traffic following the same path. E.g. if a bicasted packet
>  > arrives at an AR and is queued behind a packet that is being served
>  > (note: served, not queued), from a different packet stream, then
>  > it receives a delay of roughly T/2.
> 
> I am very, very confused by all of this. Bicasting
> at the IP layer would merely result in duplicates
> which the transport/application layer would need
> to deal with. In fact, it already needs to deal
> with dups because IP packets are fairly regularly
> duplicated anyway. While it may require some
> specific tweaks to TCP (which I assume EIFEL
> attempts to provide), I see no reason why one
> would want to shield the receiver from this in the
> network, nor do I see any reason why it requires a
> difference in the per hop behavior in the tunneled
> traffic to AR new, or any consideration of number
> of hops, etc. The beauty of the end to end principal is
> that the receiver just adapts *regardless* of
> where the source of the jitter/loss/duplication/etc
> came from. Trying to deal with jitter hop-by-hop is akin
> to the general X.25 approach to transport which
> is if nothing else against the general IP
> philosphy of end to end transport. More
> pragmatically, dealing with jitter in the network
> will almost certainly yield a worse end to end
> delay as a single jitter buffer on the receiver.
> 
> 	 Mike
>    
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Jul 2001 15:40:23 -0700 (PDT)

Gary Kenward writes:
 > depending upon the time latency between received copies. 

   Why so? You get the same SSRC, same timestamps, etc,
   and there's already in that slot, you ditch it. Doesn't
   sound very complicated to me. Also: it's already required
   in any implementation since UDP doesn't make any guarantees
   about delivery including duplicates.

> That

   You already need a jitter buffer to smooth out
   jitter over the net in general, so this comes for
   free. Frankly, RTP traffic is probably
   the least of considerations with bicasting.

	     Mike