[e2e] Policing TCP flows

[Reuven Zeitak]

>>-----Original Message-----
>>From: Greg Minshall [mailto:minshall at acm.org]
>>Sent: Wednesday, June 19, 2002 18:56
>>To: Reuven Zeitak
>>Cc: end2end-interest at postel.org
>>Subject: Re: [e2e] Policing TCP flows 
>>
>>
>>the TCP connection gets the same amount of throughput 
>>("goodput") in both 
>>cases, but the "badput" is radically different.  policing 
>>incurs lots more 
>>badput.

do you really mean that goodput==throughput?
The rest of your message seems to imply that policing
gives less goodput.

>>
>>if you look at plots from traces, what you see is that with 
>>policing, the RTT 
>>is very low, so the "probe-until-drop" cycle is very short, 
>>so you get lots of 
>>these cycles in the same elapsed time.  with shaping, the RTT is 
>>(artificially) high, so the "probe-until-drop" cycle is very 
>>long and you get 
>>fewer of these cycles in the same elapsed time.  since the 
>>amount of data 
>>transmitted is the same (in this "same elapsed time"), with 
>>policing you drop 
>>lots more packets.

Where can I find examples of such traces ( besides generating them myself)? 

>>
>>if you hate dropped packets, you'll hate policing.
>>
>>(this is all without ECN; i'm not sure how it would change 
>>with ECN, maybe for 
>>the better.  this might be the killer app for ECN!)

I guess the issue is whether TCP can self clock itself
just by fast retransmit and time outs.

Has any work been done on a tcp that works by changing
the time between packets, instead of changing the number of
packets in a window? I suppose that technically it is much easier
to "send n packets" than to "wait x millsec until next send".

>>
>>cheers, Greg Minshall
>>
>>

Thanks,

Reuven Zeitak