[e2e] TCP Loss Differentiation

[Sergey Gorinsky]

   Dear David,

   Freedom is exercised when available. Turning on the low-delay
service in some providers creates incentives for interactive
gaming and telephony applications to opt in, and puts pressure
on other providers to follow suit.

   By default, a throughput-greedy flow gets a twice higher rate
in the RD Network Services. The throughput ratio can be increased
for stronger incentives in selecting between the low-delay and
larger-throughput services.

   The benefits for throughput-greedy traffic from such forwarding
differentiation are in addition to those from potential improvements
in routing (to which you attribute the 50% underutilization of
the Internet aggregate throughput, I presume).

   Best regards,

   Sergey

On Sat, 21 Feb 2009, David P. Reed wrote:

> Sergey - I understand the motivation and approach.  The problem today is that 
> few applications are deployed that would exercise that freedom.
>
> There is not strong (in the sense of importance to users) tradeoff between 
> throughput and micro/per-packet delays today in the Internet.  Most of the 
> Internet gives aggregate throughput that is better than 1/2 the potential 
> throughput, and if the improvement is less than a factor of 2 for big FTPs, 
> it's not really that important except to tweakers.
>
> Sergey Gorinsky wrote:
>>
>>   Dear David and Fred,
>>
>>   A small buffer offers small delay to delay-sensitive traffic.
>> Throughput-greedy traffic is served through another, bigger buffer
>> at a higher per-flow rate. The two-buffer forwarding gives
>> the senders complete freedom in choosing between
>> the two best-effort services of larger throughput versus
>> low queuing delay:
>> 
>> "RD Network Services: Differentiation through Performance Incentives"
>> by Maxim Podlesny and Sergey Gorinsky,
>> Proceedings of ACM SIGCOMM 2008, pp. 255-266, August 2008,
>> http://www.arl.wustl.edu/~gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf
>> 
>> The architecture is an attempt at throughput-delay differentiation
>> designed explicitly for incremental deployment in the multi-provider
>> Internet.
>>
>>   Thank you,
>>
>>   Sergey
>> 
>>> On 20 Feb 2009, at 18:10, Fred Baker wrote:
>>> 
>>>> On Feb 19, 2009, at 9:55 PM, David P. Reed wrote:
>>>>> Fred, you are right.  Let's get ECN done.  Get your company to take the 
>>>>> lead.
>>>> 
>>>> ECN has been in the field, in some products, for the better part of a 
>>>> decade. Next step; get ISPs to turn it on. The products that don't 
>>>> support it don't because our customers tell us they don't need it (nobody 
>>>> is paying them to turn it on) or are simply not asking for it.
>> 
>