[p2p-hackers] UDP file transfer protocol peer review

[Saikat Guha]

On Fri, 2005-07-22 at 21:12 -0700, David Barrett wrote:

> The net result should ideally produce a graph like this:
> 
>     |- - - -|- -/|-/|/|/|/- - link speed
>     |       |  / |/
>     |      || /
>    r|      ||/
>    a|      |
>    t|     |
>    e|     |
>     |    /
>     |__-^
>     +-------------------------- time
>     0       a    b  c d e ...
> 
> (As for the discontinuities at a-e, I'll use the notation rate(a) to 
> mean the rate just before, and rate(a') to mean the adjusted rate 
> immediately after.)
> 
> 0-a: Slow start, exponential increase from scratch
> a-b: Congestion avoid, CONSTANT slope starting from FRAC*rate(a)
> b-c: Congestion avoid from rate(a')+FRAC*(rate(b)-rate(a'))
> c-d: Congestion avoid from rate(b')+FRAC*(rate(c)-rate(b'))
> d-e: Congestion avoid from rate(c')+FRAC*(rate(d)-rate(c'))

Since the point to which you cut back always increases, this approach
will not work with competing traffic or when the bottleneck link
bandwidth decreases, and you'll keep pegging the network.

Consider the line formed by joining the local minimas |/. The line is
some sort of logarithmic curve (shown with +).



    |- - - -|- -/|-/|/+++++- - link speed
    |       |  / |/+++
    |      || / ++
   r|      ||/+
   a|      |+
   t|     |
   e|     |
    |    /
    |__-^
    +-------------------------- time
    0       a    b  c d e ...


1) Your approach will never send fewer packets than this line
2) The line will be monotonically increasing
3) It will increase up to the link speed over time


When the "link speed" drops -- i.e. your fair share decreases (another
competing TCP starts up) or the bottleneck link changes (routing in the
internet changes), your congestion window will be stuck far above the
real link speed.

To fix this, they absolutely must be some set of transitions that bring
the window down; in some cases, all the way down to 1.  Perhaps when you
declare a loss for a couple of RTTs (i.e. 2-3 consecutive packets are
lost in a couple of successive RTT-size windows) then scale back to 1
and start from scratch?

-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050723/84b791d2/attachment.pgp