[Iccrg] Re: Appropriate rate given corruption

[Michael Welzl]

> > > Do you agree that
> >
> > > 2. On a path with multiple bottlenecks, with loss rates  p_i,  the
> > > total loss rate is slightly    less   than the sum of the p_i.   That
> > > is,  p = 1-product(1-p_i) < (sum p_i)
> >
> > No.
> >
> > I don't understand why the total loss rate of
> > the path would be slightly less than the sum of the p_i
> > and not precisely that sum.
> 
> *grin*  Last thread, I made the approximation that  p = sum p_i, and
> you correctly pointed out that, strictly,
>     p = 1 - product(1-p_i)
> because the probability a packet gets through is the probability it
> gets through on the first link *and* the second *and* the third, ...

Argh! I'm terribly sorry. I remember sending yesterday's
email *before* I had my first cup of coffee, which apparently
was a big mistake. You're right of course.

Now I already had a cup, and will now fetch another one
before I continue - hold on...

okay I'm back  :-)


> If you're happy with the approximation  p = sum p_i,  we can go with
> that and it will (greatly) simplify my later arguments.

I guess my main problem with your original emails was
the mixture of
1) assumptions which weren't all explicitly stated
2) a counter-intuitive message
3) and just the fact that it all is complicated

All three things combined were a little too much for me.

Now, as long as I understand the assumptions and they
are explicitly written, I think I can handle them. So,
if assuming that sum greatly simplifies your later
arguments, that's okay with me.


> However, if you want to more precise and go with  p = 1 -
> product(1-p_i)  then we'll need to use the fact that
>     1 - product(1-p_i)  <=  sum  p_i
> This follows immediately by induction.  We don't need the inequality
> to be strict.

Okay, I get it. Fine with me to take the simpler road
now, though.


> > The way I think about it, there is only one
> > bottleneck along a path per definition (so the p_i's will
> > all be close to zero except for one of them, which
> > represents the bottleneck).
> 
> OK.  In the optimization flow control literature, the term
> "bottleneck" is used to mean any link which has non-zero p_i.  That
> means that a link which is a bottleneck for *any* flow using that link
> will be a "bottleneck" for all flows using that link.

Okay, I understand.


> Do you agree that,
>    If one flow loses packets at a link due to congestion (non-zero p_i)
>    then that congestion will cause all flows to lose some packets on
>    that link eventually (not necessarily all in the same "congestion event")?
> That is the basis behind AIMD giving fairness.

Yes.


> > > 3. As a result, TCP gives slightly  higher  rate to multi-hop flows
> > > than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
> > > K/sqrt(p)
> >
> > No because this is based on 2, which I disagree with.
> 
> Again, we can try for a slightly weaker statement, based on 2a:
> 3a. TCP gives   no smaller   rate to multi-hop flows
>       than would a hypothetical scheme which gave a rate
>       K/sqrt(sum p_i) <= K/sqrt(p)
> 
> If you are happy with the approximation that  p = sum p_i  then  3a
> follows immediately.

Okay.

Cheers,
Michael