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

From: George Tsirtsis <[email-masked]>
Date: Thu, 26 Jul 2001 14:05:55 -0400

Hi Mike,

I think you are making the point that - end hosts already deal with
duplicate packets since this is a natural occurrence in the Internet today
so bicasting should not be a problem -

The difference is that end nodes deal with duplicate packets up to a
point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a row,
before TCP starts having problems. The fact that TCP deals with 3 dupacks
and not with 5 or 10 or 100 was an engineering choice that balances
adaptivity and throughput with the chances of this happening in the Internet
or they just picked a number from thin air...wouldn't know...was not here
:-)

My argument is that bicasting, increases the chances of duplication on top
of what the Internet naturally does and that could have bad effects if in
widespread use. Say for example, due to natural re-ordering somewhere in the
Internet, a node is about to receive 2 TCP acks, which TCP can actually deal
with no problems. At the same time the MN's packets are duplicated (due to
bicasting) at the receiving end, which results in the MN receiving 4 TCP
acks! This forces TCP to half its window thinking that there must be
congestion in the network and the packets do not get across which is clearly
not the case!

So, the objections here are not about being able to "deal" with re-ordering
as it naturally occurs but that we should not introduce mechanisms that
artificially increase the chance duplicate acks.

Regards
George
-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 6:34 PM
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 11:20:34 -0700 (PDT)

> artificially increase the chance duplicate acks.

George,

First off, disclaimer: I'm neutral on both
buffering and bicasting.

My point was simply that we not try to perform any
unnatural acts in the middle of the network to
hide jitter and duplication from the end
hosts. Yes, I agree that that will cause many
TCP's to barf, but the right thing to do is to fix
the TCP, not hide it in the network. In fact, the
effects of bicasting would only affect mobile
nodes, and I'd assume that ones which were the
targets of bicasting would have a fair amount of
incentive to deal with this inevitability. Were it
a possibility toward any random CN, then I'd
probably have a different opinion, but that
doesn't seem to be the case.

	     Mike

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 14:19:08 -0700

> the TCP, not hide it in the network. 
Amen!

PatC

---

From: Arthur Ross <[email-masked]>
Date: Thu, 26 Jul 2001 14:46:54 -0700

>>  the TCP, not hide it in the network.
Likewise.

That was, basically, the point of my comment about "transmit 
erasures". If the app/host cares, it is up to the app to cope with 
the network, warts & all. One app's "desirable network behavior 
hiding" can be another app's "unnatural act".

    -- ahmr