Subject: [rmcat] draft-ohanlon-rmcat-dflow

From: Hassnaa Moustafa <[email-masked]>
Date: Mon, 28 Jan 2013 10:33:25 -0800

Hi,

I have a question on the draft on Congestion Control Mechanism delay-based
<draft-ohanlon-rmcat-dflow>: the draft mentions the use of TFRC and TCP
congestion mechanisms as the current building blocks (and mentions that
while the draft will progress, other mechanisms could be proposed) --> my
question is on the reason for being currently based on TFRC and TCP
although the implentation problems that might exist with TFRC and TCP, is
there a specific use-case for that ?

Regards,
Hassnaa

---

From: Piers O'Hanlon <[email-masked]>
Date: Mon, 28 Jan 2013 20:47:35 +0000

Hi Hassnaa,

Thanks for your question.

On 28 Jan 2013, at 18:33, Hassnaa Moustafa wrote:

> Hi,
>  
> I have a question on the draft on Congestion Control Mechanism delay-based  <draft-ohanlon-rmcat-dflow>: the draft mentions the use of TFRC and TCP congestion mechanisms as the current building blocks (and mentions that while the draft will progress, other mechanisms could be proposed) --> my question is on the reason for being currently based on TFRC and TCP although the implentation problems that might exist with TFRC and TCP, is there a specific use-case for that ?
>  
The thinking is that TFRC provides a reasonable solution for media transport where delay is not an issue, such as streaming media delivery, where it provides for a smoother rate which does not fluctuate as much as TCP. So we took this as a baseline behaviour in loss based environments, but when delay based operation may be used we aim to provide for lower delay and still provide for a smoother rate.

I'm not sure which implementation issues you are referring to with TFRC and TCP? Both have been implemented in a number of systems - clearly TCP has very broad deployment. TFRC, like most rate based approaches, does have some potential issues with implementation of timers in small RTT environments. 

Regards,

Piers