Re: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its preferred rate?

[Mark Handley <M.Handley@cs.ucl.ac.uk>]

>> If the congested link has low levels of statmux -- like one  DCCP flow and
>> one TCP flow -- then yes, the TCP would try for the available bandwidth.
>> And during a silent period, the TFRC flow would have to transmit something
>> so it wasn't crowded out entirely.  But this amount would be *half* the
>> nominal rate, or perhaps less.  Not twice.

>Huh?  You seem to be saying that if you have a lot of TCP streams on a link
>they won't use all of the available bandwidth.  I thought just the opposite.
>With a low level of multiplexing there's more chance of synchronizing losses
>and cutbacks, and not fully utilizing the link.  But with a large number
>of flows enough of them will be blasting away while others are cut back.

No this isn't what Eddie was saying.  Say the link has capacity C.
Assume every flow has the same RTT for the sake of simplicity:

In the low statmux case:
  The TFRC flow achieves rate C because there's no other traffic.  Then
  it pauses, and a TCP starts which achieves rate C.  Then TFRC starts
  up again at rate C, and 50% loss briefly ensures before everything
  settles down.

In the high statmux case (n flows): 

  The TFRC flow achieves rate C/n, and loss rate p1.  Then it
  pauses. The other TCP flows rapidly use up the available capacity,
  each averaging rate C/(n-1).  Then TFRC restarts with rate C/n, and
  briefly sees loss rate p2.  If n >> 1 then C/n ~= C/(n-1) and p1 ~=
  p2.  Thus the *startup* of the TFRC flow doesn't significantly
  affect the loss rate, and it is going at approximately the correct
  rate.

  Of course the number of flows can change while the TFRC flow is
  idle.  But the worst that can happen is that the *additional* loss
  caused by the TFRC restarting is bounded to p = 1/(n-1).  For large
  n, this will likely be dominated by the loss caused by the TCPs
  themselves doing AIMD.

Thus the restart issue is only a serious problem when there is little
statmuxing at the bottleneck link (or where many TFRC restart
simultaneously, synchronized by some external event).

The moral of this is to use RSVP/Intserv on your 56K modem link, and
ignore the problem elsewhere.

Cheers,
	Mark

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html