Subject: [Iccrg] Re: Why don't we stop treating ECN and loss similarly
From: [email-masked] (John Leslie)
Date: Wed Oct 31 14:29:52 2012

Ingemar Johansson S <[email-masked]> wrote:
> 
>... It is doable and sometime beneficial to treat ECN and implicit
> signals of congestion (delay, packet loss) differently. We explored
> the possibilities in 
> http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper4.pdf 

... demonstrating that early ECN marking, signaling a condition where
no packet drop is expected yet, enables a smooth adaptation of sending
rate.

> The trick we did was to include the channel conditions into the ECN
> decision meaning that the cost per transmitted bit is included,

   Alas, the paper itself didn't make the ECN-marking algorithm clear.
(And I'm afraid "cost per transmitted bit" isn't entirely clear either.)

> this and the combination of only a limited decrease of the bitrate
> (~20%) gives a dramatically improved performance compared to delay
> based rate adaptation.

   As one would expect, but it's always good to have data to back it up.

> ECN with cost per transmitted bit only makes sense with wireless
> access as it is only then the cost may differ between the terminals.

   Indeed, gathering similar data for all-ethernet networks would be
useful. IMHO, it's good to consider a path "congested" long before
packet drop is inevitable. To some degree, as soon as you have two
packets ready to send, there is _some_ congestion which might be worth
notifying.

   In an ideal world, we could pass on explicit notification of time-
in-queue -- and I believe there is valuable research in exploring
different possible reactions to such a signal.

   Clearly, there is value in ECN feedback if the response to ECN is
allowed to be proportionate to the actual congestion signal instead
of "the same as packet loss". In a Research Group, we can explore that.

>...
> A tough question is .. How is the end user made aware of the
> differentiated ECN and drop behavior?. 

   The right way is to _ask_ for it.

   Alas, IPv6 doesn't do much better than IPv4 at enabling this. The
mere existence of ECN-enabled proves nothing about what level of
ECN-marking is desired. For the big-I internet, something hidden in
a destination option is useless; but we could use that for research...

--
John Leslie <[email-masked]>

From: [email-masked] (Ingemar Johansson S)
Date: Wed Oct 31 06:50:03 2012
Subject: [Iccrg] Re: Why don't we stop treating ECN and loss similarly
Message-ID: <[email-masked]>

Hi

Late with the response so I don't include any earlier conversation in this email
Answer is, Yes. It is doable and sometime beneficial to treat ECN and implicit signals of congestion (delay, packet loss) differently. We explored the possibilities in 
http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper4.pdf 
The trick we did was to include the channel conditions into the ECN decision meaning that the cost per transmitted bit is included, this and the combination of only a limited decrease of the bitrate (~20%) gives a dramatically improved performance compared to delay based rate adaptation. ECN with cost per transmitted bit only makes sense with wireless access as it is only then the cost may differ between the terminals.

Problems ?
The studies that was done was targeted at operator controlled Video telephony (VoLTE), in which case the operator has more control of the whole transmission path including backhaul. It can become a bit more tricky with OTT services but there are probably solutions to this.
One can tune AQMs to trigger ECN earlier than drops in backhaul and thus open up for a differentiated behavior between ECN and loss response. The effect of this will be that the ECN enabled flows will have a higher congestion bitrate, which may give the false impression that ECN enabled flows are more aggressive. How does an operator deal with this ?
ConEx is one solution, the ConEx option use an L bit and a C bit which makes it possible for a ConEx based policer at the network ingress to police ECN based and loss based congestion differently, the policer has possibly some knowledge about the ECN marking behavior in the domain which the policer is set to protect.

A tough question is .. How is the end user made aware of the differentiated ECN and drop behavior?. 

/Ingemar
=================================
Ingemar Johansson  M.Sc. 
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com

"However beautiful the strategy, 
 you should occasionally look at the results" 
        Sir Winston Churchill
=================================

From: [email-masked] (Mayutan A.)
Date: Tue Oct 30 08:49:52 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sorry for jumping in late.

"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 (University of Goettingen and K.K. Ramakrishnan (AT & T) had earlier
proposed (and performed experiments) to use ECN for LEDBAT like flows.  As
soon as such flows see ECN marking, they would back-off to allow other
flows to get more of the bandwidth. In scenarios where ECN enabled LEDBAT
flows co-exist with many normal flows, RFC 3168 would be fine since it was
required that ECN enabled LEDBAT like flows are at a disadvantage. But in
scenarios where most flows were LEDBAT like flows, reducing the congestion
window by half on observing ECN marking resulted in lower overall
throughput due to high fluctuations. You can find the papers and results in
the following links:
www.net.informatik.uni-goettingen.de/publications/1754/NF-TCP_Networking2011.pdf
http://www.net.informatik.uni-goettingen.de/publications/1718/NF-TCP-techreport.pdf

Therefore in my opinion, it would make make sense to evaluate the effect of
changing the current behavior of reducing the congestion window by half on
observing ECN markings to other variants such as decrease by 1/4th and so
on.

Mayutan

On Mon, Oct 29, 2012 at 5:27 PM, Mikael Abrahamsson <[email-masked]>wrote:

> On Mon, 29 Oct 2012, Michael Welzl wrote:
>
>  The bottleneck is often the last mile. So often it's perhaps more
>> important what my modem does than what ISPs do inside their network
>> somewhere... there, turning on ECN can't be such a big deal, as e.g. the
>> buffer bloat folks are putting (FQ_)CoDel in their CeroWrt?
>>
>
> The problem is not getting these distributions to adopt it, it's to get
> Dlink, Netgear, Linksys et al to implement it into their mainstream
> firmware images.
>
> But, as we all are headed for an ETTx world, it's quite likely we will all
> sit behind small buffer devices that'll be the chokepoint of our Internet
> connection, what good does ECN do there?
>
>
> --
> Mikael Abrahamsson    email: [email-masked]
>
> ______________________________**_________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/**mailman/listinfo/iccrg<http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>
>

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121030/ff0138c4/attachment.html
>From [email-masked]  Tue Oct 30 11:36:37 2012
From: [email-masked] (Piers O'Hanlon)
Date: Tue Oct 30 11:30:34 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 29 Oct 2012, at 16:27, Mikael Abrahamsson wrote:

> On Mon, 29 Oct 2012, Michael Welzl wrote:
> 
>> The bottleneck is often the last mile. So often it's perhaps more important what my modem does than what ISPs do inside their network somewhere... there, turning on ECN can't be such a big deal, as e.g. the buffer bloat folks are putting (FQ_)CoDel in their CeroWrt?
> 
> The problem is not getting these distributions to adopt it, it's to get Dlink, Netgear, Linksys et al to implement it into their mainstream firmware images.
> 
There are a some that have ECN - like Thomson/Technicolor who represent a large installed base in the UK at least (and probably in other parts of Europe too). Though the functionality is currently not switched on in domestic deployments - though can be by hand.

> But, as we all are headed for an ETTx world, it's quite likely we will all sit behind small buffer devices that'll be the chokepoint of our Internet connection, what good does ECN do there?
> 
Well if ECN was enabled on the inbound link then an ECN-enabled TCP connection could actually relatively safely signal back to the sender (in the usual way with ECN TCP flags) and lead to some ECN based congestion control for those flows. But the outbound bandwidth can be quite contentious so ECN could also be of value there but the ECN marks would currently mostly get lost... 

But I guess it's possible for the gateway to mark outgoing packets and potentially maintain that state until it sees the returning corresponding returning ACK to which it could then add the 'mark' to.... Anyone looked at this?

Piers

> -- 
> Mikael Abrahamsson    email: [email-masked]
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Arjuna Sathiaseelan)
Date: Mon Oct 29 19:02:18 2012
Subject: [Iccrg] Re: Iccrg Digest, Vol 81, Issue 10
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <CAPaG1AmmsRyWMQ8uNZRF7V=[email-masked]>

something related here :
http://datatracker.ietf.org/doc/draft-carlberg-tsvwg-ecn-reactions/

arjuna

On 29 October 2012 12:07,  <[email-masked]> wrote:
> Send Iccrg mailing list submissions to
>         [email-masked]
>
> 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
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Iccrg digest..."
>
>
> Today's Topics:
>
>    1. Re: Why don't we stop treating ECN and loss similarly?
>       (Jo?o Taveira Ara?jo)
>    2. Re: Why don't we stop treating ECN and loss similarly?
>       (Jo?o Taveira Ara?jo)
>    3. Re: Why don't we stop treating ECN and loss similarly?
>       (Michael Welzl)
>    4. Re: Why don't we stop treating ECN and loss similarly?
>       (Mikael Abrahamsson)
>    5. Re: Why don't we stop treating ECN and loss similarly?
>       (ken carlberg)
>    6. Re: Why don't we stop treating ECN and loss similarly?
>       (Mikael Abrahamsson)
>    7. Re: Why don't we stop treating ECN and loss similarly?
>       (ken carlberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Oct 2012 17:27:20 +0000
> From: Jo?o Taveira Ara?jo <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Excerpts from Lachlan Andrew's message of Sun Oct 28 01:56:33 +0100 2012:
>> Greetings John,
>>
>> On 27 October 2012 22:55, John Leslie <[email-masked]> wrote:
>> >
>> >    As Bob has pointed out, theory clearly shows that the less-aggressive
>> > reaction-to-loss will starve the more-aggressive...
>>
>> Could you remind us which theory shows that?  It sounds rather
>> counter-intuitive.
>
> The term aggressive is a bit of a misnomer in this context. I believe
> what was implied was that flows which back off less in times of contention
> starve those which back off more.
>
> Joao.
>
>>
>> Thanks,
>> Lachlan
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 28 Oct 2012 18:13:31 +0000
> From: Jo?o Taveira Ara?jo <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
>> 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.
>
> With research hat off, I'd be wary of making such changes.
> As you point out, the specification of ECN is overly conservative (more
> so than DECbit for example), but I believe TCP fairness alone was only
> part of it. The Source Quench option had proved a debacle because
> gateways had no expectation on how hosts would react, and hosts had
> little indication on what the option was intended to signal. That SQ
> ended being rendered useless through a myriad of interpretations may
> explain why ECN adhered so strictly to well understood principles and
> concisely specified behaviour.
>
> It would be simpler to answer your thought experiment if you take it one
> step further: what would you replace the rule with, and how would the
> coexistence of both not be detrimental to ECN as a standard?
>
> Joao
>
>> I'm curious what everyone thinks... am I missing something?
>>
>> Cheers,
>> Michael
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 29 Oct 2012 09:03:58 +0100
> From: Michael Welzl <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: Jo?o Taveira Ara?jo <[email-masked]>
> Cc: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi,
>
> inline:
>
> On 28. okt. 2012, at 19:13, Jo?o Taveira Ara?jo wrote:
>
>> Hi,
>>
>> Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
>>> 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.
>>
>> With research hat off, I'd be wary of making such changes.
>> As you point out, the specification of ECN is overly conservative (more
>> so than DECbit for example), but I believe TCP fairness alone was only
>> part of it. The Source Quench option had proved a debacle because
>> gateways had no expectation on how hosts would react, and hosts had
>> little indication on what the option was intended to signal. That SQ
>> ended being rendered useless through a myriad of interpretations may
>> explain why ECN adhered so strictly to well understood principles and
>> concisely specified behaviour.
>
> Hm, I can see that -
>
>>
>> It would be simpler to answer your thought experiment if you take it one
>> step further: what would you replace the rule with, and how would the
>> coexistence of both not be detrimental to ECN as a standard?
>
> ... and THIS is interesting research to pursue!
>
> Perhaps some of the ideas for reacting to a finer-grain ECN signal will lead to an answer to that.
>
> Cheers,
> Michael
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 29 Oct 2012 09:56:14 +0100 (CET)
> From: Mikael Abrahamsson <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> On Mon, 29 Oct 2012, Michael Welzl wrote:
>
>> Perhaps some of the ideas for reacting to a finer-grain ECN signal will
>> lead to an answer to that.
>
> As far as I can tell, ECN has decent end-system support, but very limited
> network support. I don't know of any major core routing platform that
> supports setting ECN in a RED configuration instead of dropping the
> packet (last I checked this was 1.5 years ago, but talking to vendors
> indicated very little interest).
>
> I'm also seeing buffer depth going down over time (see bufferbloat
> discussion, plus prolifiration of L3 switches with minimal onboard buffers
> instead of larger classical router ones), which means that it's even
> harder than before to justify ECN as nothing in a live network will really
> act on ECN being used or not by the end system. If someone else has other
> information, I'd like to know.
>
> Perhaps it would be valuable to write some text about the state of ECN
> support right now, and then a plan to increase value for ECN so we can get
> it adopted. Current state of affairs is that few care about ECN because
> nobody is asking for it (same as with IPv6), so there is little commercial
> incentive to get it implemented. I feel most talk about ECN is from
> academia with little current real world implications. I'd like to see this
> changed, but I don't really know how. Changing the standards to
> implementing ECN actually brings improvement to both ISP and end user
> might be a good first step towards a world where ECN is actually used.
>
> --
> Mikael Abrahamsson    email: [email-masked]
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 29 Oct 2012 06:10:00 -0400
> From: ken carlberg <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: Mikael Abrahamsson <[email-masked]>
> Cc: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Oct 29, 2012, at 4:56 AM, Mikael Abrahamsson wrote:
>
>> Perhaps it would be valuable to write some text about the state of ECN support right now, and then a plan to increase value for ECN so we can get it adopted. Current state of affairs is that few care about ECN because nobody is asking for it (same as with IPv6), so there is little commercial incentive to get it implemented. I feel most talk about ECN is from academia with little current real world implications. I'd like to see this changed, but I don't really know how. Changing the standards to implementing ECN actually brings improvement to both ISP and end user might be a good first step towards a world where ECN is actually used.
>
> this topic has come up before on this list.  about 2.5 years ago, an engineer in my office did some tests and found that IP service providers do one of three things with the ToS field (that have some combination of non-zero markings): (a) they let them pass through unchanged, (b) they clear out the diff-serv field, but leave the ECN field untouched, and (c) they clear the entire ToS byte.
>
> Tony Li made the good suggestion that if folks are concerned about (c), they should go to places like NANOG and talk to the operators about this.
>
> as for interest in ECN, it exists in some planned deployments of LTE for the toll-quality VoIP applications/services.
>
> -ken
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 29 Oct 2012 12:10:23 +0100 (CET)
> From: Mikael Abrahamsson <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: ken carlberg <[email-masked]>
> Cc: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Mon, 29 Oct 2012, ken carlberg wrote:
>
>> as for interest in ECN, it exists in some planned deployments of LTE for
>> the toll-quality VoIP applications/services.
>
> Really? Do you have some pointers to this, my understanding was that VoLTE
> would be on a dedicated bearer with that kind of QoS that 3GPP always has
> done (per bearer, but doing FIFO within the bearer).
>
> --
> Mikael Abrahamsson    email: [email-masked]
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 29 Oct 2012 07:30:26 -0400
> From: ken carlberg <[email-masked]>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: Mikael Abrahamsson <[email-masked]>
> Cc: iccrg <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> part of my understanding comes from individual conversations with carriers from a couple of different countries, so I can't provide a pointer to that.  But indirectly, you can see some of the interest in the form of some standards work in the ITU with participation by industry on H.248.82  "Gateway Control Protocol: Explict Congestion Notification Support", from SG 16 dated May 2012.  And there are other addendums to this base document, but I don't follow SG 16 closely.
>
> -ken
>
>
> On Oct 29, 2012, at 7:10 AM, Mikael Abrahamsson wrote:
>
>> On Mon, 29 Oct 2012, ken carlberg wrote:
>>
>>> as for interest in ECN, it exists in some planned deployments of LTE for the toll-quality VoIP applications/services.
>>
>> Really? Do you have some pointers to this, my understanding was that VoLTE would be on a dedicated bearer with that kind of QoS that 3GPP always has done (per bearer, but doing FIFO within the bearer).
>>
>> --
>> Mikael Abrahamsson    email: [email-masked]
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> End of Iccrg Digest, Vol 81, Issue 10
> *************************************

-- 
Regards
Arjuna
http://about.me/arjuna.sathiaseelan

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Oct 29 16:21:18 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Oct 2012, Michael Welzl wrote:

> The bottleneck is often the last mile. So often it's perhaps more 
> important what my modem does than what ISPs do inside their network 
> somewhere... there, turning on ECN can't be such a big deal, as e.g. the 
> buffer bloat folks are putting (FQ_)CoDel in their CeroWrt?

The problem is not getting these distributions to adopt it, it's to get 
Dlink, Netgear, Linksys et al to implement it into their mainstream 
firmware images.

But, as we all are headed for an ETTx world, it's quite likely we will all 
sit behind small buffer devices that'll be the chokepoint of our Internet 
connection, what good does ECN do there?

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (David Ros)
Date: Mon Oct 29 14:08:35 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 27 oct. 2012, at 11:26, Michael Welzl wrote:

> 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?
> 

Hi,

(jumping late into this thread)

Likely I am missing something, but I don't see a fundamental difference between, say, having CUBIC compete with non-CUBIC flows and having RFC3168-compliant, ECN-enabled flows compete with "non-standard" ones (non-standard as in, reduce cwnd by less than half).

I don't know if we should *remove* the halve-cwnd-if-ECN-mark rule, but it looks like an interesting experiment to do.

Thanks,

David.

PS: by the way, what does a CUBIC sender do in the face of incoming ECN marks?

> 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
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

"It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett

From: [email-masked] (Michael Welzl)
Date: Mon Oct 29 12:44:38 2012
Subject: [Iccrg] New co-chair
Message-ID: <[email-masked]>

Dear group,

Murari Sridharan is stepping down as my ICCRG co-chair. I would like to thank him very much for his service!

I would like to propose David Ros as new co-chair:
http://www.rennes.enst-bretagne.fr/~dros/dros/Home.html

I am proposing him because I know him as a reliable person (I have worked with him in the past), and know that he'll be regularly going to IETF meetings on a regular basis. It's also clear to me that he has a lot of knowledge about congestion control.

If anyone sees any issue with this decision, they should speak up (in public, or in a direct message to me). Else, welcome David!

Cheers,
Michael Welzl (in the role as the other chair)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121029/bb561e7c/attachment.html
>From [email-masked]  Mon Oct 29 13:49:16 2012
From: [email-masked] (David Ros)
Date: Mon Oct 29 13:43:09 2012
Subject: [Iccrg] New co-chair
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

I've been silently lurking this list for quite a while, but it seems the silent-lurker time is over now :-)

Unfortunately I won't be able to attend ICCRG's next meeting in Atlanta, but I do hope to meet you folks in person in later meetings.

Thanks,

David.

On 29 oct. 2012, at 13:50, Michael Welzl wrote:

> Dear group,
> 
> Murari Sridharan is stepping down as my ICCRG co-chair. I would like to thank him very much for his service!
> 
> I would like to propose David Ros as new co-chair:
> http://www.rennes.enst-bretagne.fr/~dros/dros/Home.html
> 
> I am proposing him because I know him as a reliable person (I have worked with him in the past), and know that he'll be regularly going to IETF meetings on a regular basis. It's also clear to me that he has a lot of knowledge about congestion control.
> 
> If anyone sees any issue with this decision, they should speak up (in public, or in a direct message to me). Else, welcome David!
> 
> Cheers,
> Michael Welzl (in the role as the other chair)
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

In theory, theory and practice are the same. In practice, they are different. -- Author unknown

From: [email-masked] (Michael Welzl)
Date: Mon Oct 29 12:16:15 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I wonder - what you write here seems to have an ISP-side / "inner network" flavor to it.
The bottleneck is often the last mile. So often it's perhaps more important what my modem does than what ISPs do inside their network somewhere... there, turning on ECN can't be such a big deal, as e.g. the buffer bloat folks are putting (FQ_)CoDel in their CeroWrt?

Cheers,
Michael

On 29. okt. 2012, at 09:56, Mikael Abrahamsson wrote:

> On Mon, 29 Oct 2012, Michael Welzl wrote:
> 
>> Perhaps some of the ideas for reacting to a finer-grain ECN signal will lead to an answer to that.
> 
> As far as I can tell, ECN has decent end-system support, but very limited network support. I don't know of any major core routing platform that supports setting ECN in a RED configuration instead of dropping the packet (last I checked this was 1.5 years ago, but talking to vendors indicated very little interest).
> 
> I'm also seeing buffer depth going down over time (see bufferbloat discussion, plus prolifiration of L3 switches with minimal onboard buffers instead of larger classical router ones), which means that it's even harder than before to justify ECN as nothing in a live network will really act on ECN being used or not by the end system. If someone else has other information, I'd like to know.
> 
> Perhaps it would be valuable to write some text about the state of ECN support right now, and then a plan to increase value for ECN so we can get it adopted. Current state of affairs is that few care about ECN because nobody is asking for it (same as with IPv6), so there is little commercial incentive to get it implemented. I feel most talk about ECN is from academia with little current real world implications. I'd like to see this changed, but I don't really know how. Changing the standards to implementing ECN actually brings improvement to both ISP and end user might be a good first step towards a world where ECN is actually used.
> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (ken carlberg)
Date: Mon Oct 29 11:24:12 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

part of my understanding comes from individual conversations with carriers from a couple of different countries, so I can't provide a pointer to that.  But indirectly, you can see some of the interest in the form of some standards work in the ITU with participation by industry on H.248.82  "Gateway Control Protocol: Explict Congestion Notification Support", from SG 16 dated May 2012.  And there are other addendums to this base document, but I don't follow SG 16 closely.

-ken

On Oct 29, 2012, at 7:10 AM, Mikael Abrahamsson wrote:

> On Mon, 29 Oct 2012, ken carlberg wrote:
> 
>> as for interest in ECN, it exists in some planned deployments of LTE for the toll-quality VoIP applications/services.
> 
> Really? Do you have some pointers to this, my understanding was that VoLTE would be on a dedicated bearer with that kind of QoS that 3GPP always has done (per bearer, but doing FIFO within the bearer).
> 
> -- 
> Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Oct 29 11:04:31 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Oct 2012, ken carlberg wrote:

> as for interest in ECN, it exists in some planned deployments of LTE for 
> the toll-quality VoIP applications/services.

Really? Do you have some pointers to this, my understanding was that VoLTE 
would be on a dedicated bearer with that kind of QoS that 3GPP always has 
done (per bearer, but doing FIFO within the bearer).

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (ken carlberg)
Date: Mon Oct 29 10:04:07 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Oct 29, 2012, at 4:56 AM, Mikael Abrahamsson wrote:

> Perhaps it would be valuable to write some text about the state of ECN support right now, and then a plan to increase value for ECN so we can get it adopted. Current state of affairs is that few care about ECN because nobody is asking for it (same as with IPv6), so there is little commercial incentive to get it implemented. I feel most talk about ECN is from academia with little current real world implications. I'd like to see this changed, but I don't really know how. Changing the standards to implementing ECN actually brings improvement to both ISP and end user might be a good first step towards a world where ECN is actually used.

this topic has come up before on this list.  about 2.5 years ago, an engineer in my office did some tests and found that IP service providers do one of three things with the ToS field (that have some combination of non-zero markings): (a) they let them pass through unchanged, (b) they clear out the diff-serv field, but leave the ECN field untouched, and (c) they clear the entire ToS byte.

Tony Li made the good suggestion that if folks are concerned about (c), they should go to places like NANOG and talk to the operators about this.

as for interest in ECN, it exists in some planned deployments of LTE for the toll-quality VoIP applications/services. 

-ken

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Oct 29 08:50:12 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Oct 2012, Michael Welzl wrote:

> Perhaps some of the ideas for reacting to a finer-grain ECN signal will 
> lead to an answer to that.

As far as I can tell, ECN has decent end-system support, but very limited 
network support. I don't know of any major core routing platform that 
supports setting ECN in a RED configuration instead of dropping the 
packet (last I checked this was 1.5 years ago, but talking to vendors 
indicated very little interest).

I'm also seeing buffer depth going down over time (see bufferbloat 
discussion, plus prolifiration of L3 switches with minimal onboard buffers 
instead of larger classical router ones), which means that it's even 
harder than before to justify ECN as nothing in a live network will really 
act on ECN being used or not by the end system. If someone else has other 
information, I'd like to know.

Perhaps it would be valuable to write some text about the state of ECN 
support right now, and then a plan to increase value for ECN so we can get 
it adopted. Current state of affairs is that few care about ECN because 
nobody is asking for it (same as with IPv6), so there is little commercial 
incentive to get it implemented. I feel most talk about ECN is from 
academia with little current real world implications. I'd like to see this 
changed, but I don't really know how. Changing the standards to 
implementing ECN actually brings improvement to both ISP and end user 
might be a good first step towards a world where ECN is actually used.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Michael Welzl)
Date: Mon Oct 29 07:57:42 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

inline:

On 28. okt. 2012, at 19:13, Jo?o Taveira Ara?jo wrote:

> Hi,
> 
> Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
>> 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.
> 
> With research hat off, I'd be wary of making such changes. 
> As you point out, the specification of ECN is overly conservative (more
> so than DECbit for example), but I believe TCP fairness alone was only 
> part of it. The Source Quench option had proved a debacle because
> gateways had no expectation on how hosts would react, and hosts had
> little indication on what the option was intended to signal. That SQ 
> ended being rendered useless through a myriad of interpretations may
> explain why ECN adhered so strictly to well understood principles and 
> concisely specified behaviour.

Hm, I can see that -

> 
> It would be simpler to answer your thought experiment if you take it one
> step further: what would you replace the rule with, and how would the
> coexistence of both not be detrimental to ECN as a standard?

... and THIS is interesting research to pursue!

Perhaps some of the ideas for reacting to a finer-grain ECN signal will lead to an answer to that.

Cheers,
Michael

From: [email-masked] (=?utf-8?q?Jo=C3=A3o_Taveira_Ara=C3=BAjo?=)
Date: Sun Oct 28 18:07:30 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
> 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.

With research hat off, I'd be wary of making such changes. 
As you point out, the specification of ECN is overly conservative (more
so than DECbit for example), but I believe TCP fairness alone was only 
part of it. The Source Quench option had proved a debacle because
gateways had no expectation on how hosts would react, and hosts had
little indication on what the option was intended to signal. That SQ 
ended being rendered useless through a myriad of interpretations may
explain why ECN adhered so strictly to well understood principles and 
concisely specified behaviour.

It would be simpler to answer your thought experiment if you take it one
step further: what would you replace the rule with, and how would the
coexistence of both not be detrimental to ECN as a standard?

Joao

> I'm curious what everyone thinks... am I missing something?
> 
> Cheers,
> Michael
> 

From: [email-masked] (=?utf-8?q?Jo=C3=A3o_Taveira_Ara=C3=BAjo?=)
Date: Sun Oct 28 17:21:08 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20121027115559.GS27557@verdi> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Excerpts from Lachlan Andrew's message of Sun Oct 28 01:56:33 +0100 2012:
> Greetings John,
> 
> On 27 October 2012 22:55, John Leslie <[email-masked]> wrote:
> >
> >    As Bob has pointed out, theory clearly shows that the less-aggressive
> > reaction-to-loss will starve the more-aggressive...
> 
> Could you remind us which theory shows that?  It sounds rather
> counter-intuitive.

The term aggressive is a bit of a misnomer in this context. I believe
what was implied was that flows which back off less in times of contention 
starve those which back off more.

Joao.

> 
> Thanks,
> Lachlan
> 

From: [email-masked] (Lachlan Andrew)
Date: Sun Oct 28 01:50:45 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <20121027115559.GS27557@verdi>
References: <[email-masked]> <20121027115559.GS27557@verdi>
Message-ID: <[email-masked]>

Greetings John,

On 27 October 2012 22:55, John Leslie <[email-masked]> wrote:
>
>    As Bob has pointed out, theory clearly shows that the less-aggressive
> reaction-to-loss will starve the more-aggressive...

Could you remind us which theory shows that?  It sounds rather
counter-intuitive.

Thanks,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Arjuna Sathiaseelan)
Date: Sat Oct 27 12:04:52 2012
Subject: [Iccrg] Re: Iccrg Digest, Vol 81, Issue 8
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <CAPaG1Akg8qycZkZ+Y_9mKBOAR_K_9MDj0kF_c1gN263-=[email-masked]>

this sounds great actually..probably reduced to 3/4th cwnd on ecn marks?

arjuna
On Oct 27, 2012 12:06 PM, <[email-masked]> wrote:

> Send Iccrg mailing list submissions to
>         [email-masked]
>
> 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
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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 <[email-masked]>
> Subject: [Iccrg] Agenda
> To: iccrg list <[email-masked]>
> Message-ID: <[email-masked]>
> 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 <[email-masked]>
> Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
> To: iccrg list <[email-masked]>
> Message-ID: <[email-masked]>
> 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
> [email-masked]
> 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/1850b1df/attachment.html
>From [email-masked]  Sat Oct 27 12:16:31 2012
From: [email-masked] (Arjuna Sathiaseelan)
Date: Sat Oct 27 12:10:26 2012
Subject: [Iccrg] Re: Iccrg Digest, Vol 81, Issue 8
In-Reply-To: <CAPaG1Akg8qycZkZ+Y_9mKBOAR_K_9MDj0kF_c1gN263-=[email-masked]>
References: <[email-masked]>
	<CAPaG1Akg8qycZkZ+Y_9mKBOAR_K_9MDj0kF_c1gN263-=[email-masked]>
Message-ID: <[email-masked]>

or proportional rate reduction - even better?

just random thoughts..
On Oct 27, 2012 12:10 PM, "Arjuna Sathiaseelan" <
[email-masked]> wrote:

> this sounds great actually..probably reduced to 3/4th cwnd on ecn marks?
>
> arjuna
> On Oct 27, 2012 12:06 PM, <[email-masked]> wrote:
>
>> Send Iccrg mailing list submissions to
>>         [email-masked]
>>
>> 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
>>         [email-masked]
>>
>> You can reach the person managing the list at
>>         [email-masked]
>>
>> 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 <[email-masked]>
>> Subject: [Iccrg] Agenda
>> To: iccrg list <[email-masked]>
>> Message-ID: <[email-masked]>
>> 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 <[email-masked]>
>> Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
>> To: iccrg list <[email-masked]>
>> Message-ID: <[email-masked]>
>> 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
>> [email-masked]
>> 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
>From [email-masked]  Sat Oct 27 12:55:59 2012
From: [email-masked] (John Leslie)
Date: Sat Oct 27 12:50:13 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20121027115559.GS27557@verdi>

Michael Welzl <[email-masked]> wrote:
> 
> 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.

   As Bob has pointed out, theory clearly shows that the less-aggressive
reaction-to-loss will starve the more-aggressive...

> We have seen various non-standard congestion control behaviors can
> co-exist reasonably well with standard TCP in practice.

   Yes! At the risk of setting-off Bob, this suggests that the theory
may not completely correspond to reality. ;^)

> 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.

   This, of course, would be trivial if we had a gradation of ECN
marking...

> And none of this is possible when we have the "treat an ECN mark
> just like loss" rule in place.

   Rules can be relaxed in research projects...

> Hence, my question: to incentivize ECN usage and enable better  
> behavior when it's used, shouldn't we remove this rule?

   There is certainly room for research which "partially" relaxes
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'll remind folks that the RMCAT WG needs to convince folks that
a less-aggressive response to ECN/loss, coupled with a less-
aggressive ramp-up in the absence of ECN/loss, is safe.

   Early indications are that this will prove acceptable...

--
John Leslie <[email-masked]>

From: [email-masked] (Michael Welzl)
Date: Sat Oct 27 10:21:19 2012
Subject: [Iccrg] Why don't we stop treating ECN and loss similarly?
Message-ID: <[email-masked]>

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

From: [email-masked] (Michael Welzl)
Date: Sat Oct 27 09:14:30 2012
Subject: [Iccrg] Agenda
Message-ID: <[email-masked]>

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

From: [email-masked] (Michael Welzl)
Date: Wed Oct 17 08:31:56 2012
Subject: [Iccrg] RMCAT: IETF group of interest
Message-ID: <[email-masked]>

Hi,

For those who might have missed it, I just thought I should probably tell you ICCRG'ers that there is a new IETF group with focus on congestion control (for interactive real-time media): RMCAT.
For details, see: http://datatracker.ietf.org/wg/rmcat/charter/

Cheers,
Michael

From: [email-masked] (Janardhan Iyengar)
Date: Thu Oct 11 05:01:19 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]> <CAPpWWaLJYeb+wUxjbQvGRpPxxDzo=ORxv+=[email-masked]> <[email-masked]>
Message-ID: <CAD4XsLP-=[email-masked]>

Murari, Lachlan, all,

ICCRG seems like a great place to discuss generation and use of richer ECN
signaling. Related work can exist in both ICCRG and in TCPM, and work can
(and occasionally does) move from ICCRG to the IETF as it becomes more
protocol engineering work.

I support bringing this topic to ICCRG.

FWIW,
- jana

On Wed, Oct 10, 2012 at 8:50 PM, Murari Sridharan <[email-masked]>wrote:

> Great point, as I said this could go either way. However I am saying there
> is work regarding signaling that should be taken up at TCPM and not just
> bucketized into being research.
>
> Thanks
>
> -----Original Message-----
> From: Lachlan Andrew [mailto:[email-masked]]
> Sent: Wednesday, October 10, 2012 5:49 PM
> To: Murari Sridharan
> Cc: Michael Welzl; Yuchung Cheng; iccrg list
> Subject: Re: [Iccrg] Meeting @ Atlanta IETF
>
> Greetings Murari / all,
>
> I think that the signalling itself may be suitable for TCPM, but there is
> plenty of research scope for the many different uses it can be put to.  If
> we stick to the original view of "ECN must be treated as loss"
> then there isn't much to do, but looking at ways to combine ECN marks from
> multiple packets to signal richer information is research, and so is
> deciding what to do with that richer information.
>
> $0.02
> Lachlan
>
> On 11 October 2012 11:07, Murari Sridharan <[email-masked]> wrote:
> > Chair hat off, I think this topic is less research and more useful
> pursued in TCPM.
> >
> > Chair hat on: sounds interesting we should talk about it :-)
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Michael Welzl
> >
> > I think it would be quite fitting, especially because the applications
> of such a scheme seem to be more research'y right now...
> >
> >
> > On Oct 5, 2012, at 5:59 PM, Yuchung Cheng wrote:
> >
> >> Should we discuss better ECN sigaling and feedback here too?
> >> I thought that's a hot topic.
>
> --
> Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
> Swinburne University of Technology, Melbourne, Australia <
> http://caia.swin.edu.au/cv/landrew>
> Ph +61 3 9214 4837
>
>
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121011/2a4ad762/attachment.html
>From [email-masked]  Tue Oct 16 14:06:02 2012
From: [email-masked] (Michael Welzl)
Date: Tue Oct 16 14:01:34 2012
Subject: [Iccrg] Agenda requests
Message-ID: <[email-masked]>

Still no concrete slots planned...

Let us chairs know if you'd like to present / discuss something, thanks!

Michael

From: [email-masked] (Murari Sridharan)
Date: Thu Oct 11 01:47:33 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <CAPpWWaLJYeb+wUxjbQvGRpPxxDzo=ORxv+=[email-masked]>
References: <[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]> <CAPpWWaLJYeb+wUxjbQvGRpPxxDzo=ORxv+=[email-masked]>
Message-ID: <[email-masked]>

Great point, as I said this could go either way. However I am saying there is work regarding signaling that should be taken up at TCPM and not just bucketized into being research. 

Thanks

-----Original Message-----
From: Lachlan Andrew [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2012 5:49 PM
To: Murari Sridharan
Cc: Michael Welzl; Yuchung Cheng; iccrg list
Subject: Re: [Iccrg] Meeting @ Atlanta IETF

Greetings Murari / all,

I think that the signalling itself may be suitable for TCPM, but there is plenty of research scope for the many different uses it can be put to.  If we stick to the original view of "ECN must be treated as loss"
then there isn't much to do, but looking at ways to combine ECN marks from multiple packets to signal richer information is research, and so is deciding what to do with that richer information.

$0.02
Lachlan

On 11 October 2012 11:07, Murari Sridharan <[email-masked]> wrote:
> Chair hat off, I think this topic is less research and more useful pursued in TCPM.
>
> Chair hat on: sounds interesting we should talk about it :-)
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Michael Welzl
>
> I think it would be quite fitting, especially because the applications of such a scheme seem to be more research'y right now...
>
>
> On Oct 5, 2012, at 5:59 PM, Yuchung Cheng wrote:
>
>> Should we discuss better ECN sigaling and feedback here too?
>> I thought that's a hot topic.

--
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia <http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Lachlan Andrew)
Date: Thu Oct 11 01:45:38 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CAPpWWaLJYeb+wUxjbQvGRpPxxDzo=ORxv+=[email-masked]>

Greetings Murari / all,

I think that the signalling itself may be suitable for TCPM, but there
is plenty of research scope for the many different uses it can be put
to.  If we stick to the original view of "ECN must be treated as loss"
then there isn't much to do, but looking at ways to combine ECN marks
from multiple packets to signal richer information is research, and so
is deciding what to do with that richer information.

$0.02
Lachlan

On 11 October 2012 11:07, Murari Sridharan <[email-masked]> wrote:
> Chair hat off, I think this topic is less research and more useful pursued in TCPM.
>
> Chair hat on: sounds interesting we should talk about it :-)
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Welzl
>
> I think it would be quite fitting, especially because the applications of such a scheme seem to be more research'y right now...
>
>
> On Oct 5, 2012, at 5:59 PM, Yuchung Cheng wrote:
>
>> Should we discuss better ECN sigaling and feedback here too?
>> I thought that's a hot topic.

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (=?iso-8859-1?Q?P=E5l_Halvorsen?=)
Date: Tue Oct  9 09:27:13 2012
Subject: [Iccrg] PhD position available in the area of in Time-Dependent Networking
Message-ID: <[email-masked]>

AVAILABLE PHD POSITION

At Simula Research Laboratory (Norway) there is an available PhD position in the area of in Time-Dependent Networking. The PhD Student will work in the area of networking support for time-dependent applications, focusing on thin streams. Thin streams are generated by applications that send data with high interarrival time and also often small packet sizes. These traffic patterns are in stark contrast to greedy streams where the application always has data to send and the sending rate is limited by congestion control. Typical for thin streams is that they are generated by interactive applications with a need for low latency communication.

The following topics are central for the work in this position:

? Develop mechanisms to improve thin-stream latency when transmitted via different buffer types with varying drop schemes.
? Investigate the congestion control support of conditionally thin streams (i.e. not everything must be sent at all times) via per-packet priorities.
? Work towards a formal definition of the concept of thin streams.
? Work towards defining what TCP fairness must mean in thin-stream scenarios.

The position is connected to the "Traffic behaviour of interactive time-dependent thin streams on the modern Internet" (TimeIn) research project cooperating with partners like UNINETT, University of Oslo, Karlstad University, University of Kaiserslautern, CAIDA San Diego, Cisco and Funcom.

It is planned to align the research with, and possibly contribute to, ongoing standardization efforts in the RTP Media Congestion Avoidance Techniques (RMCAT) working group in the IETF.

For more information about the project, the requirements, Simula, salary, etc., 
please see
  http://simula.no/jobs/PhDStudent-TimeIn

or contact:
  Postdoc Andreas Petlund, e-mail: [email-masked] or
  Professor P?l Halvorsen, e-mail: [email-masked]
(where you include the following phrase in the subject field: ?TimeIn PhD position?)

The application deadline is as soon as possible, but no later than 20 October 2012.

To apply for this position, click here: 
https://emea3.recruitmentplatform.com/appproc/index.cfm?event=createSessionAfterSessionClear&ID=QL5FK026203F3VBQBV779QWAD&jobboard=0&nPTID=28&bSessionClear=true
>From [email-masked]  Thu Oct 11 01:07:02 2012
From: [email-masked] (Murari Sridharan)
Date: Thu Oct 11 01:04:42 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<CAK6E8=[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Chair hat off, I think this topic is less research and more useful pursued in TCPM. 

Chair hat on: sounds interesting we should talk about it :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Sunday, October 7, 2012 8:31 AM
To: Yuchung Cheng
Cc: iccrg list
Subject: Re: [Iccrg] Meeting @ Atlanta IETF

(+ Mirja, TCPM chairs)

Hi,

I think it would be quite fitting, especially because the applications of such a scheme seem to be more research'y right now...

Anyone willing to give a talk about this? Richard, Mirja?

Cheers,
Michael

On Oct 5, 2012, at 5:59 PM, Yuchung Cheng wrote:

> Should we discuss better ECN sigaling and feedback here too?
> I thought that's a hot topic.
>
> On Fri, Oct 5, 2012 at 2:53 AM, Michael Welzl <[email-masked]>
> wrote:
>> Not much input so far  :-)
>> We have (tentatively, as usual) been given a 2-hour slot on Monday 
>> afternoon.
>>
>> Fire your agenda slot requests at us, I say!
>>
>> Cheers,
>> Michael
>>
>>
>> On 30. aug. 2012, at 08:45, Michael Welzl wrote:
>>
>>> Hi,
>>>
>>> We're planning on having an ICCRG session at the upcoming IETF in 
>>> Atlanta, and we need to request a slot soon. To make sure that we 
>>> request the right slot size, it would be great to already have an 
>>> indication of the number of speakers and length of talks...  so, if 
>>> you're planning on presenting something, please let us know - with 
>>> (tentative, you can still update it later) title, and expected 
>>> (desired) duration.
>>>
>>> Thanks!
>>> Michael
>>>
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Sun Oct  7 16:27:27 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <CAK6E8=[email-masked]>
References: <[email-masked]> <[email-masked]> <CAK6E8=[email-masked]>
Message-ID: <[email-masked]>

(+ Mirja, TCPM chairs)

Hi,

I think it would be quite fitting, especially because the applications  
of such a scheme seem to be more research'y right now...

Anyone willing to give a talk about this? Richard, Mirja?

Cheers,
Michael

On Oct 5, 2012, at 5:59 PM, Yuchung Cheng wrote:

> Should we discuss better ECN sigaling and feedback here too?
> I thought that's a hot topic.
>
> On Fri, Oct 5, 2012 at 2:53 AM, Michael Welzl <[email-masked]>  
> wrote:
>> Not much input so far  :-)
>> We have (tentatively, as usual) been given a 2-hour slot on Monday  
>> afternoon.
>>
>> Fire your agenda slot requests at us, I say!
>>
>> Cheers,
>> Michael
>>
>>
>> On 30. aug. 2012, at 08:45, Michael Welzl wrote:
>>
>>> Hi,
>>>
>>> We're planning on having an ICCRG session at the upcoming IETF in  
>>> Atlanta, and we need to request a slot soon. To make sure that we  
>>> request the right slot size, it would be great to already have an  
>>> indication of the number of speakers and length of talks...  so,  
>>> if you're planning on presenting something, please let us know -  
>>> with (tentative, you can still update it later) title, and  
>>> expected (desired) duration.
>>>
>>> Thanks!
>>> Michael
>>>
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> [email-masked]
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Yuchung Cheng)
Date: Fri Oct  5 16:56:55 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

Should we discuss better ECN sigaling and feedback here too?
I thought that's a hot topic.

On Fri, Oct 5, 2012 at 2:53 AM, Michael Welzl <[email-masked]> wrote:
> Not much input so far  :-)
> We have (tentatively, as usual) been given a 2-hour slot on Monday afternoon.
>
> Fire your agenda slot requests at us, I say!
>
> Cheers,
> Michael
>
>
> On 30. aug. 2012, at 08:45, Michael Welzl wrote:
>
>> Hi,
>>
>> We're planning on having an ICCRG session at the upcoming IETF in Atlanta, and we need to request a slot soon. To make sure that we request the right slot size, it would be great to already have an indication of the number of speakers and length of talks...  so, if you're planning on presenting something, please let us know - with (tentative, you can still update it later) title, and expected (desired) duration.
>>
>> Thanks!
>> Michael
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Fri Oct  5 10:50:12 2012
Subject: [Iccrg] Meeting @ Atlanta IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Not much input so far  :-)
We have (tentatively, as usual) been given a 2-hour slot on Monday afternoon.

Fire your agenda slot requests at us, I say!

Cheers,
Michael

On 30. aug. 2012, at 08:45, Michael Welzl wrote:

> Hi,
> 
> We're planning on having an ICCRG session at the upcoming IETF in Atlanta, and we need to request a slot soon. To make sure that we request the right slot size, it would be great to already have an indication of the number of speakers and length of talks...  so, if you're planning on presenting something, please let us know - with (tentative, you can still update it later) title, and expected (desired) duration.
> 
> Thanks!
> Michael
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Thomas Dreibholz)
Date: Tue Oct  2 06:55:37 2012
Subject: [Iccrg] [Extended Deadline] Call for Papers of the PAMS 2013
Message-ID: <2724080.zHT5LYnrNn@lupo>

We apologize if you receive multiple copies of this CFP.

CALL FOR PAPERS

The 3rd International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS 2013)
In conjunction with the 27th IEEE International Conference on Advanced 
Information Networking and Applications (AINA 2013)
Barcelona, Spain, March 25-28, 2013
http://simula.no/pams2013

The intent of our workshop is to bring together people from research and
industry, in order to provide a discussion forum for state-of-the-art topics
related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session
(with short presentations) to introduce preliminary ideas as well as work in
progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Testbeds for Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Multi-Homing for Interconnection Networks
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimisation for Multi-Homed Systems
    * Multi-Homing in the Context of the Future Internet

GENERAL CHAIRS:

    * Thomas Dreibholz, Simula Research Laboratory, Norway
    * Hakim Adhari, University of Duisburg-Essen, Germany

PROGRAM CHAIRS:

    * Martin Becke, University of Duisburg-Essen, Germany
    * Thomas Dreibholz, Simula Research Laboratory, Norway

PUBLICITY CHAIRS:

    * Glenford Mapp, Middlesex University, United Kingdom
    * Xing Zhou, Hainan University, China

PROGRAM COMMITTEE

    * Hakim Adhari, University of Duisburg-Essen, Germany
    * Nicola Altan, ista International, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Holger Bleul, DB Systel, Germany
    * Anna Brunstr?m, Karlstad University, Sweden
    * Ahmed Elmokashfi, Simula Research Laboratory, Norway
    * Kristian Evensen, Simula Research Laboratory, Norway
    * Ernst Gunnar Gran, Simula Research Laboratory, Norway
    * Seok Joo Koh, Kyungpook National University, South Korea
    * Amund Kvalbein, Simula Research Laboratory, Norway
    * Glenford Mapp, Middlesex University, United Kingdom
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, Google, U.S.A.
    * Esbold Unurkhaan, Mongolian University of Science and Technology, 
Mongolia
    * Andreas Timm-Giel, TU Hamburg-Harburg, Germany
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway
    * Xing Zhou, Hainan University, China

IMPORTANT DATES

    * Paper Submission Deadline:       October 15, 2012 -- EXTENDED --
    * Author Notification:             November 25, 2012
    * Camera-Ready Paper Submission:   December 28, 2012
    * Author Registration:             January 11, 2013

CONTACT

For further information, please contact:

    * Thomas Dreibholz ([email-masked])
    * Hakim Adhari ([email-masked])

WEBSITE

http://simula.no/pams2013