Re: [Codel] [RFC PATCH] codel: ecn mark at target

[Andrew McGregor <andrewmcgr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

I don't think that's a real either/or question.  ECN itself does not mean that those flows get to scam the network; that's what my points 2 and 3 are for.  I guess that argues for the marking to be earlier than drop onset, but right now that's just a guess. Properly working ECN TCP should mean that with the right choice of marking pattern the result should be much the same as non-ECN TCP for fairness, but less bursty and with fewer delay events for the application.

ECN isn't all that useful for bulk transfer TCP, but for things like videoconferencing RTP it's really quite important to maintaining a good user experience. So is congestion control; these applications are better served by being consistently a bit slower than they are by bursting up and down, because frequent resolution or frame rate changes are really annoying to watch. ECN also serves many thin flow TCP applications well (SSH for example).

I have to think a bit more about what the right thing is; maybe marking once or twice each time codel enters the dropping state, and then dropping as usual. Don't take that as a real proposal, though, as this is a quick response and a solid proposal deserves a lot more thought.

Andrew

On 5/08/2012, at 9:58 AM, Kathleen Nichols <nichols@pollere.com> wrote:

> 
> So you want to provide an incentive to deploy ECN. This also provides an
> incentive to
> scam the network. I think a bigger question is what is gained by doing
> this? Is it more
> important to deploy something called ECN than to have a well-functioning
> network?
> 
> 	Kathie
> 
> On 8/5/12 9:53 AM, Andrew McGregor wrote:
>> Well, there's a lot of people at the IETF who really want to do other things with ECN, but it seems like the simple version is far too aggressive.
>> 
>> So, I think the desirable properties are something like:
>> 1) Allow ECN flows to achieve the same or slightly higher throughput to maintain an incentive to deploy it.
>> 2) Still drop ECN flows eventually to avoid too much queue buildup.
>> 3) Account somehow for the fact that marking takes longer to control the queue (but we don't know how much longer).
>> 
>> Maybe mark ECN instead of dropping, but if we end up trying to mark/drop twice in one round, drop the later packets?
>> 
>> Oh, and ECN nonce deployment is negligible, to the extent that there are proposals in the IETF to reuse the bits for other things, and there is no pushback on that.
>> 
>> Andrew
>> 
>> On 4/08/2012, at 10:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> 
>>> On Sat, 2012-08-04 at 20:06 -0700, Andrew McGregor wrote:
>>>> Well, thanks Eric for trying it.
>>>> 
>>>> Hmm.  How was I that wrong?  Because I was supporting that idea.
>>>> 
>>>> Time to think.
>>> 
>>> No problem Andrew ;)
>>> 
>>> Its seems ECN is not well enough understood.
>>> 
>>> ECN marking a packet has the same effect for the sender : reducing cwnd
>>> exactly like a packet drop. Only difference is avoiding the
>>> retransmit[s].
>>> 
>>> It cannot be used only to send a 'small' warning, while other competing
>>> non ECN flows have no signal.
>>> 
>>> As far as packet schedulers are concerned, there should be no difference
>>> in ECN marking and dropping a packet. I believe linux packet schedulers
>>> are fine in this area.
>>> 
>>> Now, there are fundamental issues with ECN itself, out of Codel scope,
>>> thats for sure.
>>> 
>>> How widely has been RFC 3540 deployed, anybody knows ?
>>> 
>>> 
>>> 
> 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2330 bytes --]