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

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

I agree with you Michael, but with the caveat that we must
consider that many of these hosts will be small, low power,
light weight devices, not 1GHz processor, 256MRAM workstations (or, 
maybe PDAs will have 1GHz/256M in them the time this all gets 
deployed *ponder*).

My point being that while I am also against PEPs, we have to be
careful of pushing things out to the host, at least on the wireless
side?

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: July 26, 2001 14:21
> To: [email-masked]
> Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
> 
> 
> George Tsirtsis writes:
>  > 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.
> 
> 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: Michael Thomas <[email-masked]>
Date: Thu, 26 Jul 2001 15:33:44 -0700 (PDT)

> careful of pushing things out to the host, at least on the wireless

   I seriously doubt that a few small tweaks to the TCP
   stack -- as I imagine that EIFEL is -- should be the
   basis of any decision.

	    Mike