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

From: "Qiong Li" <[email-masked]>
Date: Wed, 3 Dec 2003 09:32:40 -0500

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.

> 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.

So this relates to our previous conversation?  When you're transmitting
at
less than the TFRC allowed rate, your allowed rate could be twice what
you're transmitting.  If a loss event happens, your allowed rate is cut
back, but since it was twice what you were actually transmitting, no
effect.
This gives you the effective "protection" of transmitting at twice your
necessary rate, without actually doing it.

Great if it works.  A simulation would be nice :-).

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Qiong Li" <[email-masked]>
Date: Wed, 3 Dec 2003 10:34:07 -0500

Sorry for the previous message. I was intending to make comments on the
following posting regarding "TFRC allowed rate".

--------------------------------------------------------------
...... When you're transmitting at
less than the TFRC allowed rate, your allowed rate could be twice what
you're transmitting.  If a loss event happens, your allowed rate is cut
back, but since it was twice what you were actually transmitting, no
effect.
This gives you the effective "protection" of transmitting at twice your
necessary rate, without actually doing it.

.......
----------------------------------------------------

Since TRFC allowed rate (R0) is estimated from observed loss rate (L) by
the DCCP flow, and the two are positively correlated, R0 may be
interpreted and used in different ways:

- If the DCCP flow can tolerate a loss rate > L, it can consider to
increase its sending rate. As long as its sending rate R < R0, it will
not be considered to be unfair to other TCP flows. It does not
necessarily means that when R < R0, it is always good to increase R.
Doing that could result higher loss rate when the end-to-end path is
lightly multiplexed with TCP flows.

- If the estimated R0 is reduced, even that it is still higher than R,
keeping the current sending rate for the DCCP flow may imply the flow
will experience higher loss rate.

The point: the adaptation of DCCP flow rate may need to combine the
considerations of both R0 and L, depending on the codec characteristics.
When the decoder can only perform error concealment under certain
pre-designed loss rate, then the L should dominate the adaptation,
assuming scalable media content is used, which may imply that R0 could
become irrelevant under some circumstances.  

Qiong Li

---

From: Mark Handley <[email-masked]>
Date: Fri, 05 Dec 2003 16:55:21 +0000

>> 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

>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
>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