[Iccrg] Re: Iccrg Digest, Vol 81, Issue 8

[Arjuna Sathiaseelan]

or proportional rate reduction - even better?

just random thoughts..
On Oct 27, 2012 12:10 PM, "Arjuna Sathiaseelan" <
arjuna.sathiaseelan at gmail.com> wrote:

> this sounds great actually..probably reduced to 3/4th cwnd on ecn marks?
>
> arjuna
> On Oct 27, 2012 12:06 PM, <iccrg-request at cs.ucl.ac.uk> wrote:
>
>> Send Iccrg mailing list submissions to
>>         iccrg at cs.ucl.ac.uk
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> or, via email, send a message with subject or body 'help' to
>>         iccrg-request at cs.ucl.ac.uk
>>
>> You can reach the person managing the list at
>>         iccrg-owner at cs.ucl.ac.uk
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Iccrg digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Agenda (Michael Welzl)
>>    2. Why don't we stop treating ECN and loss similarly? (Michael Welzl)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 27 Oct 2012 10:20:13 +0200
>> From: Michael Welzl <michawe at ifi.uio.no>
>> Subject: [Iccrg] Agenda
>> To: iccrg list <iccrg at cs.ucl.ac.uk>
>> Message-ID: <9C0FF8B7-8A75-4599-9980-BBA7B76842F0 at ifi.uio.no>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> Hi,
>>
>> There is still space on our agenda - currently, it looks like this:
>>
>>
>> ICCRG agenda, IETF 85, Atlanta, Monday, 5 November, 13:00-15:00, Salon A
>>
>> Rong Pan: "A new algorithm for dealing with buffer bloat", 20+10 min
>>
>> Nestor Michael C. Tiglao: "Transport layer caching mechanisms and
>> optimization", 20+10 min
>>
>> Open discussion about the applicability of more precise ECN signalling
>>
>>
>> Cheers,
>> Michael
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 27 Oct 2012 11:26:59 +0200
>> From: Michael Welzl <michawe at ifi.uio.no>
>> Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
>> To: iccrg list <iccrg at cs.ucl.ac.uk>
>> Message-ID: <920D98EE-EFEB-47E2-879C-84999F258771 at ifi.uio.no>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> Hi,
>>
>> Here's an idea, inspired by something Bob Briscoe posted to the TSVWG
>> list recently in a discussion of draft-carlberg-tsvwg-ecn-reactions.
>> However, this possibly stupid idea is my own responsibility alone  :-)
>>
>>
>> According to RFC 3168, senders must react to ECN just as if packets
>> had been dropped. This is to maintain fairness between ECN-compatible
>> and non-compatible flows.
>> Because of this requirement, AQMs cannot ECN-mark packets more
>> aggressively than it drops packets from non-ECN-capable flows - else
>> ECN-marked flows would be at a disadvantage.
>>
>> We have seen various non-standard congestion control behaviors can co-
>> exist reasonably well with standard TCP in practice. If it was
>> possible to have a milder congestion reaction to ECN-based reaction,
>> it would also be possible to ECN-mark packets earlier, leading to a
>> bigger advantage for everyone using ECN. And none of this is possible
>> when we have the "treat an ECN mark just like loss" rule in place.
>>
>> Hence, my question: to incentivize ECN usage and enable better
>> behavior when it's used, shouldn't we remove this rule?
>>
>> Note that this is not even about a more fine-grain interpretation of
>> ECN feedback - it's more like an intermediate step.
>>
>> I'm curious what everyone thinks... am I missing something?
>>
>> Cheers,
>> Michael
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Iccrg mailing list
>> Iccrg at cs.ucl.ac.uk
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>> End of Iccrg Digest, Vol 81, Issue 8
>> ************************************
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121027/5228110e/attachment.html