Subject: [Iccrg] Is ECN too complicated?
From: [email-masked] (Mikael Abrahamsson)
Date: Fri Jul 31 14:02:51 2009

On Fri, 31 Jul 2009, John Leslie wrote:

> We do need them to leave ECN marking alone. (Has someone documented
> which core router do and don't?)

I don't know of any core router that will zero the ECN marking, all I have 
seen either have ECN support (used in their WRED schemes) or they don't 
know anything about ECN and just ignores the bits and just passes the 
packet unchanged (ECN-wise).

>   I don't feel the need for more detail of why intelligence in core 
> routers is expensive. What we do need is an upper bound on packet drop 
> (without ECN marking coming first) in actual core routers.

>From what I have seen in recent major vendors, the new platforms seem to 
have around 50-200ms of buffers, coming down from the common 600ms 5+ 
years back.

This is for 10G and 40G interfaces.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (John Leslie)
Date: Fri Jul 31 13:49:55 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <20090731125707.GC9935@verdi>

Mikael Abrahamsson <[email-masked]> wrote:
> 
> The major core routing platforms today do not as far as I know support ECN 
> at all, and these are the ones with big buffers (and support gazillions of 
> queues etc). I asked for ECN support and received pushback for reason 
> being "I was the only one who asked for this" (basically).

   We do need them to leave ECN marking alone. (Has someone documented
which core router do and don't?)

> So as I stated in the meeting, the ISP community is going more in the 
> direction of "let's make a 100GE router/L3-switch with minimal buffers 
> that never congests and upgrade to" than "let's find this platform that 
> can squeeze the max out of this 10GE we already have".

   And that is correct... but when the actual usage of those routers
produces even one packet drop per thousand, we're leaving the comfort
zone. :^(

> DWDM-capacity is cheap, doing buffering/intelligent things in routers is 
> expensive.

   Agreed. But there are some Network Service Providers too cheap to do
either. Can we document which these are?

> I can go more into detail about this if someone feels it's appropriate.

   I don't feel the need for more detail of why intelligence in core
routers is expensive. What we do need is an upper bound on packet drop
(without ECN marking coming first) in actual core routers.

--
John Leslie <[email-masked]>

From: [email-masked] (John Leslie)
Date: Fri Jul 31 13:40:53 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20090731124802.GB9935@verdi>

Bob Briscoe <[email-masked]> wrote:
> 
> I wanted to carry this question over to the list. It is central to 
> challenge #1 in our open issues. What level of router support for cc 
> is appropriate?

   Some explicit congestion notification is decidedly needed. I would
hope that in the vast majority of cases this would be marking a
packet rather than dropping it.

   I believe Bob has in mind a specific usage of ECN (RFC 3168) here.
(It would be good to include a pointer to exactly how he means to
use it.)

   ECN need not be deployed at _every_ router in the Internet cloud,
so long as the markings are preserved (and packet drop at non-ECN
routers is sufficiently rare). But there will be a need to apply
back-pressure somehow, preferably by dropping packets that come from
sources that don't manage the congestion.

> My premise is that ECN is the most minimal mechanism we can imagine 
> on each queue, to get info out of those boxes to the edge of the 
> network, where capacity sharing can be controlled - rather than 
> trying to do capacity sharing on every resource (which I have shown 
> is not even the right thing to be wanting to do).

   I would agree.

> So I was a bit surprised to hear ECN criticised as too complex. It's 
> a tiny no. of cycles per packet. If ECN is too complex, whither RCP?

   It's the _perceived_ complexity that's the problem. Many of us just
don't understand what Bob is currently proposing; and it's a bit
cloudy which RFCs actually apply when he says "ECN".

> BTW, I've recently proved that the parts of the ECN algo that make 
> marking follow a uniform distribution can be removed (redundant).

   Yet another example of what we don't know...
 
> Also, recent work by Damon Wischik iwhere there's hi stat mux (the 
> boxes we're worried about) you don't even need the RED ramp, just a 
> step at a small number of packets.

   Yet another...

> If ECN is still too complex, I'm at a loss (irony intended).

   In order for this to work in the wild, we need quite a few routers
near the core to perform the flavor of ECN that Bob wants. We just
don't yet understand how much of a hurdle this might be (but we're
pretty sure the hurdle is insurmountable until it's better defined).

   It's not a question of how complex the code might be: it's a
question of how difficult it will be to get enough deployment.

--
John Leslie <[email-masked]>

From: [email-masked] (Lars Eggert)
Date: Fri Jul 31 11:59:39 2009
Subject: [Iccrg] Fwd: [e2e] TCP fairness
References: <[email-masked]>
Message-ID: <[email-masked]>

The ICCRG participants may have input on this.

Begin forwarded message:

> From: "Krause, Matthias" <[email-masked]>
> Date: July 31, 2009 10:38:58 GMT+02:00
> To: "[email-masked]" <[email-masked]>
> Subject: [e2e] TCP fairness
>
> Dear community,
>
> I?m afraid I?m stuck with some artifacts I have to be able to  
> explain and maybe even control.
> I appreciate every small hint in a good direction either towards a  
> paper or to the right existing reference.
>
> While experimenting with video streaming over TCP in equilibrium  
> situations, I found several artifacts.
> The environment was as follows. 3 video streaming servers (Windows  
> XP) based on TCP were streaming to 3 receivers
> in a  local network over a bottleneck node.
> Variations on the this setup were {wireless | wired}, {receiver  
> Linux| receiver WinXP}, distance from
> base station (in wireless), number of  network nodes in between,  
> inclusion/exclusion of a token bucket filter
> node for bandwidth limitation.
>
> In all the experiments, I permutated the receivers, and run each  
> permutation for 20 to 50 times.
> The streamed video sequence was 6 Mbit/s and 560 seconds long.
>
> The artifacts I achieved were:
>
>
> ?         In sum, the bitrates achieved were not fair (as in ?close  
> to equal?)
>
> ?         The bit rate ratios stayed stable most of the time.
>
> ?         Sometimes ratios switch, turning the best performer into  
> the worst performer.
>
> I wonder if these phenomena are known and studied or not even worth  
> the effort thinking of it.
>
> Thank you very much for your time and consideration and I?m looking  
> forward to hearing from you.
>
> Yours sincerely,
>
> Matthias Krause
> Philips Research
>
>
> ________________________________
> The information contained in this message may be confidential and  
> legally protected under applicable law. The message is intended  
> solely for the addressee(s). If you are not the intended recipient,  
> you are hereby notified that any use, forwarding, dissemination, or  
> reproduction of this message is strictly prohibited and may be  
> unlawful. If you are not the intended recipient, please contact the  
> sender by return e-mail and destroy all copies of the original  
> message.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090731/8f75d307/smime.bin
>From [email-masked]  Fri Jul 31 13:26:32 2009
From: [email-masked] (John Leslie)
Date: Fri Jul 31 13:19:50 2009
Subject: [Iccrg] FW: [tsv-area] Amount of packet buffering in home gateways
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20090731122632.GA9935@verdi>

Eddy, Wesley M. (GRC-MS00)[Verizon] <[email-masked]> wrote:
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of Iljitsch van Beijnum
>>
>> I'm currently in the congestion control research group session and the
>> issue of excessive buffering in home gateways came up. (I'm posting to
>> tsv area rather than iccrg or ledbat to avoid subscribing to a bunch
>> of new lists for a single discussion, I would prefer to discuss this
>> on homegate but I'm open to redirects if necessary.)

   (I've added Iljitsch as a Cc; I don't think cross-posting would help.)

>> So what is the right thing to do? As I mentioned in the homegate bar
>> bof, last year I was in a place where there was a 128 kbps uplink with
>> 10 seconds (160 kbyte) of buffering. This made the connection almost
>> unusable until I manually set my send/receive buffers to 8k.

   I think we can define a lower bound: the buffer must hold at least
enough bytes to form the maximum-size outgoing message.

   An upper bound is harder.

   Let me suggest that the additional amount of buffering should cover
the time required to input enough bytes for another maximum-size
message _plus_ some "response time" -- the size in bytes being computed
based upon the outgoing byte rate.

   On the question of what that "response time" should be, I'll punt.

   ;^)

>> What I'm thinking is that at 64 kbps or slower, you probably want to
>> buffer 4 packets and no more, but also no less. At higher speeds, I'm
>> thinking 10 packets is really all you need, assuming a single fifo /
>> tail drop queue. Does anyone have data or arguments that conflict with
>> this?

   I wouldn't agree that packet count is the right metric.

   I also wouldn't agree that a single number is appropriate without
regard to the input rate.

   10 maximum-sized packets strikes me as a bit high for a 128 kbps
uplink. (1500 * 8 / 128000 = 94 msec, not even considering jumbograms.)

>> But do we want to recommend RED?

   Random Early Discard makes sense only when you can't rate-limit at
the input (in other words, when you have to accept a packet not knowing
whether it might go out on an uncongested interface). Otherwise, you're
better off letting the sender(s) know you're congested by not accepting
their packet.

>> Bob Briscoe just made the argument that weighted fair queuing isolates
>> flows from each other so they can't interact in useful ways. So
>> recommend against it? On the other hand, WFQ would make VoIP etc work
>> much better in the presence of some heavy flows. But not as well as in
>> the case where we specifically prioritize the real-time traffic.

   This doesn't feel like a congestion-control question to me.

>> I'm guessing that we don't want to specify any default diffserv
>> behavior...

   I certainly don't want to do so here and now...

--
John Leslie <[email-masked]>

From: [email-masked] (Mikael Abrahamsson)
Date: Thu Jul 30 21:38:03 2009
Subject: [Iccrg] RE: Iccrg Digest, Vol 44, Issue 6
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 30 Jul 2009, Ingemar Johansson S wrote:

> To me "ECN not-supported in the routers (or whatever)" can mean two
> things
>
> 1) The ECN bits are ignored and left unchanged
> 2) The ECN bits are zeroed.

To me something that zeroes ECN bits when doing packet forwarding when it 
doesn't understand them is broken.

> So my question is what kind of behavior (1 or 2) is to be expected from 
> e.g core routers that don't support ECN ?

1. It does it's thing completely ignoring (and leaving unchanged) all 
information regarding ECN.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Ingemar Johansson S)
Date: Thu Jul 30 16:05:37 2009
Subject: [Iccrg] RE: Iccrg Digest, Vol 44, Issue 6
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi

I am a bit curious regarding the interperetation of the word supported
(or not supported).

To me "ECN not-supported in the routers (or whatever)" can mean two
things

1) The ECN bits are ignored and left unchanged
2) The ECN bits are zeroed.

The first alternative is not serious for the endpoint, also the opinion
I have seen sofar is that core routers does not want the extra workload
of peeking into the inner details of the IP headers (may not even look
at the IP headers at all...). The principle as I understand it is that
the edge nodes are supposed to experience congestion.

The second alternative is of course more serious for the endpoints that
decide to use ECN.

So my question is what kind of behavior (1 or 2) is to be expected from
e.g core routers that don't support ECN  ?

Regards
/Ingemar

> Message: 2
> Date: Wed, 29 Jul 2009 13:30:12 +0200 (CEST)
> From: Mikael Abrahamsson <[email-masked]>
> Subject: Re: [Iccrg] Is ECN too complicated?
> To: Bob Briscoe <[email-masked]>
> Cc: iccrg IRTF list <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> On Wed, 29 Jul 2009, Bob Briscoe wrote:
> 
> > If ECN is still too complex, I'm at a loss (irony intended).
> 
> Well, let's put it this way:
> 
> The major core routing platforms today do not as far as I 
> know support ECN at all, and these are the ones with big 
> buffers (and support gazillions of queues etc). I asked for 
> ECN support and received pushback for reason being "I was the 
> only one who asked for this" (basically).
> 
> So ECN support is present in the CPU-based routers from a 
> certain major vendor, but not the more ASIC/NP-accelerated ones.
> 
> So as I stated in the meeting, the ISP community is going 
> more in the direction of "let's make a 100GE router/L3-switch 
> with minimal buffers that never congests and upgrade to" than 
> "let's find this platform that can squeeze the max out of 
> this 10GE we already have".
> 
> DWDM-capacity is cheap, doing buffering/intelligent things in 
> routers is expensive.
> 
> I can go more into detail about this if someone feels it's 
> appropriate.
> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> 
> 
> 

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[Verizon])
Date: Thu Jul 30 15:54:19 2009
Subject: [Iccrg] slides from plenary
Message-ID: <[email-masked]>

FYI, here are the slides Aaron showed about ICCRG
during the plenary:
http://www.ietf.org/proceedings/75/slides/iccrg-6.ppt
If you haven't been to an ICCRG meeting lately, this
should give a decent idea of what we've been up to.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: [email-masked] (Bob Briscoe)
Date: Thu Jul 30 09:02:03 2009
Subject: [Iccrg] Congestion Transparency (re-ECN Bar BoF) Agenda
Message-ID: <[email-masked]>

Folks,

[Sorry previous email gave inappropriate URL - below is the correct 
one. Same room, same time.]

     * When Thu 30 Jul '09, 15:10-16:10 (CEST)
     * Rm 501 @ Stockholm IETF
     * No remote audio available in room (recording will be attempted).
     * No jabber

Pls bash proposed agenda:
<http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN>

Cheers

bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  

From: [email-masked] (Bob Briscoe)
Date: Thu Jul 30 06:25:59 2009
Subject: [Iccrg] Congestion Transparency (re-ECN Bar BoF) Agenda
Message-ID: <[email-masked]>

Folks,

     * When Thu 30 Jul '09, 15:10-16:10 (CEST)
     * Rm 501 @ Stockholm IETF
     * No remote audio available in room (recording will be attempted).
     * No jabber

Pls bash proposed agenda:
<http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/re-ECN>

Cheers

bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[Verizon])
Date: Wed Jul 29 12:36:42 2009
Subject: [Iccrg] presentations online
Message-ID: <[email-masked]>

Thanks to all the presenters at the ICCRG meeting today; the
blue sheets captured 54 in attendance.

The slides are all available at:
https://datatracker.ietf.org/meeting/75/materials.html
under ICCRG.  The minutes and audio archive should become
available in the next week.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: [email-masked] (Mikael Abrahamsson)
Date: Wed Jul 29 12:22:56 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 29 Jul 2009, Bob Briscoe wrote:

> If ECN is still too complex, I'm at a loss (irony intended).

Well, let's put it this way:

The major core routing platforms today do not as far as I know support ECN 
at all, and these are the ones with big buffers (and support gazillions of 
queues etc). I asked for ECN support and received pushback for reason 
being "I was the only one who asked for this" (basically).

So ECN support is present in the CPU-based routers from a certain major 
vendor, but not the more ASIC/NP-accelerated ones.

So as I stated in the meeting, the ISP community is going more in the 
direction of "let's make a 100GE router/L3-switch with minimal buffers 
that never congests and upgrade to" than "let's find this platform that 
can squeeze the max out of this 10GE we already have".

DWDM-capacity is cheap, doing buffering/intelligent things in routers is 
expensive.

I can go more into detail about this if someone feels it's appropriate.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Lars Eggert)
Date: Wed Jul 29 11:43:39 2009
Subject: [Iccrg] FW: [tsv-area] Amount of packet buffering in home gateways
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2009-7-29, at 12:12, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>> [posted to homegate and tsv area, prune as necessary]

And please reply there, so the discussion happens in one place. (There  
are followup postings there already.)

Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090729/e0b19efb/smime.bin
>From [email-masked]  Wed Jul 29 11:55:19 2009
From: [email-masked] (Bob Briscoe)
Date: Wed Jul 29 12:10:07 2009
Subject: [Iccrg] Is ECN too complicated?
Message-ID: <[email-masked]>

Sorry, I didn't catch the name of the questioner in iCCRG just now...

I wanted to carry this question over to the list. It is central to 
challenge #1 in our open issues. What level of router support for cc 
is appropriate?

My premise is that ECN is the most minimal mechanism we can imagine 
on each queue, to get info out of those boxes to the edge of the 
network, where capacity sharing can be controlled - rather than 
trying to do capacity sharing on every resource (which I have shown 
is not even the right thing to be wanting to do).

So I was a bit surprised to hear ECN criticised as too complex. It's 
a tiny no. of cycles per packet. If ECN is too complex, whither RCP?

BTW, I've recently proved that the parts of the ECN algo that make 
marking follow a uniform distribution can be removed (redundant). 
Also, recent work by Damon Wischik iwhere there's hi stat mux (the 
boxes we're worried about) you don't even need the RED ramp, just a 
step at a small number of packets.

If ECN is still too complex, I'm at a loss (irony intended).

Bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[Verizon])
Date: Wed Jul 29 11:05:22 2009
Subject: [Iccrg] FW: [tsv-area] Amount of packet buffering in home gateways
Message-ID: <[email-masked]>

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Iljitsch van Beijnum
>Sent: Wednesday, July 29, 2009 4:35 AM
>To: [email-masked]; TSV Area
>Subject: [tsv-area] Amount of packet buffering in home gateways
>
>[posted to homegate and tsv area, prune as necessary]
>
>I'm currently in the congestion control research group session and the
>issue of excessive buffering in home gateways came up. (I'm posting to
>tsv area rather than iccrg or ledbat to avoid subscribing to a bunch
>of new lists for a single discussion, I would prefer to discuss this
>on homegate but I'm open to redirects if necessary.)
>
>So what is the right thing to do? As I mentioned in the homegate bar
>bof, last year I was in a place where there was a 128 kbps uplink with
>10 seconds (160 kbyte) of buffering. This made the connection almost
>unusable until I manually set my send/receive buffers to 8k.
>
>The question is, what do we want to tell home gateway builders?
>Obviously it would be nice to give priority to VoIP and gaming traffic
>and so on, but how do you easily do this without an extensive packet
>classification system? We also wouldn't want applications to game the
>system by sending more small packets that get better service than
>fewer large packets.
>
>What I'm thinking is that at 64 kbps or slower, you probably want to
>buffer 4 packets and no more, but also no less. At higher speeds, I'm
>thinking 10 packets is really all you need, assuming a single fifo /
>tail drop queue. Does anyone have data or arguments that conflict with
>this?
>
>But do we want to recommend RED? I seem to remember it has fallen
>somewhat out of favor, but is it worse than a simple tail drop queue?
>With RED it's necessary to have more buffering in order to let it work
>without tail drops happening anyway. So how much buffering would that
>require? 20 packets? 40?
>
>Bob Briscoe just made the argument that weighted fair queuing isolates
>flows from each other so they can't interact in useful ways. So
>recommend against it? On the other hand, WFQ would make VoIP etc work
>much better in the presence of some heavy flows. But not as well as in
>the case where we specifically prioritize the real-time traffic.
>
>I'm guessing that we don't want to specify any default diffserv
>behavior...
>
>Iljitsch

From: [email-masked] (Bob Briscoe)
Date: Wed Jul 29 10:28:18 2009
Subject: [Iccrg] Capacity sharing arch design team slides
Message-ID: <[email-masked]>

Wes, Michael,

Slides as promised:
<http://www.bobbriscoe.net/present.html#0907iccrg>

Bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Lars Eggert)
Date: Wed Jul 29 09:30:07 2009
Subject: [Iccrg] Too-big buffers in routers
In-Reply-To: <20090729080552.GJ9935@verdi>
References: <20090729080552.GJ9935@verdi>
Message-ID: <[email-masked]>

On 2009-7-29, at 10:05, John Leslie wrote:
>   I'd like to pose the question whether we've got any research project
> to _locate_ routers which buffer "too much".

http://netalyzr.icsi.berkeley.edu/ tells end users about their  
buffers. Nothing stops operators from running it, too.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090729/277fb73c/smime.bin
>From [email-masked]  Wed Jul 29 10:01:13 2009
From: [email-masked] (Woundy, Richard)
Date: Wed Jul 29 09:55:06 2009
Subject: [Iccrg] Too-big buffers in routers
References: <20090729080552.GJ9935@verdi>
	<[email-masked]>
Message-ID: <[email-masked]>

Also look at http://www.imconf.net/imc-2007/papers/imc137.pdf. See Figure 13 on page 10, especially the DSL and cable upstream queue length measurements.
 
I suspect there would be different results for some operators today, compared to 2007, because some operators have increased their upstream speeds (and overall upstream capacity) but with the same modem upstream queue lengths. (As one example, Comcast raised their typical upstream speed from 384k to 1 Mbps and higher in 2008.)
 
-- Rich

________________________________

From: [email-masked] on behalf of Lars Eggert
Sent: Wed 7/29/2009 4:37 AM
To: John Leslie
Cc: iccrg IRTF list
Subject: Re: [Iccrg] Too-big buffers in routers

On 2009-7-29, at 10:05, John Leslie wrote:
>   I'd like to pose the question whether we've got any research project
> to _locate_ routers which buffer "too much".

http://netalyzr.icsi.berkeley.edu/ tells end users about their 
buffers. Nothing stops operators from running it, too.

Lars

From: [email-masked] (John Leslie)
Date: Wed Jul 29 08:59:33 2009
Subject: [Iccrg] Too-big buffers in routers
Message-ID: <20090729080552.GJ9935@verdi>

   In today's session, Lawrence Stewart complained about several things:
the one leading to the most discussion (IMHO) was router buffers that
were too large.

   I'd like to pose the question whether we've got any research project
to _locate_ routers which buffer "too much".

   The point being, ISPs can't do much about this unless they know
_which_ routers are causing problems by buffering too much.

--
John Leslie <[email-masked]>

From: [email-masked] (Xiaoming Fu)
Date: Mon Jul 27 23:33:19 2009
Subject: [Iccrg] ICNP 2009 Call for Demos
Message-ID: <[email-masked]>

Our apologies for cross-posting...
----
Dear colleagues,

Please kindly forward to your colleagues and students for consideration
of a demo contribution to ICNP'09 - Please note there will be a best
demo prize (at the courtesy of Microsoft)!

The deadline for submitting a demo abstract (as well as posters) to
ICNP'09 is August 7, 2009 (Fri 23:59 PDT).

Thanks and best regards,
Xiaoming Fu (ICNP 2009 Publicity Chair)

ICNP'09 Call for Demos:
======================
IEEE ICNP 2009 will include a demo session. Proposals for research
demonstrations and exhibits are strongly solicited. Research
demonstrations should be innovative research prototypes that show new
research related to the topics included in the ICNP call for papers. The
best demo will receive a cash prize of USD 500, courtesy of Microsoft
Research.

Submission Instructions:
-----------------------
Submit demo proposal at: http://edas.info/N7882.

The proposals should include a two-page (10 pt) abstract describing the
goals of the demo and the basic idea it supports. Submissions are single
blind, so please include authors' names and affiliation.

In addition, include a list of equipment the demo will use, as well as
space and power requirements. Note that the organizers can provide only
space and power. We may be able to provide Internet access for the demos
as well, but this is not guaranteed. Let us also know if you will need a
large amount of setup time.

All demo proposals will be reviewed by the ICNP 2009 Poster and Demo
committee. Selected demo abstracts will be published in the ICNP
proceedings.

Important Dates:
---------------
Submission deadline (on EDAS)     August 7, 2009, (Fri 23:59 PDT)
Notification of acceptance        August 28, 2009
Camera ready deadline             September 4, 2009

Organizing Committee:
--------------------
Jitendra Padhye (Chair)  Microsoft Research, USA
Srikanth Krishnamurthy   UC Riverside, USA
Henning Schulzrinne      Columbia University, USA
K. K. Ramakrishnan       AT&T labs, USA

From: [email-masked] (Xiaoming Fu)
Date: Mon Jul 27 23:20:58 2009
Subject: [Iccrg] ICNP 2009 Call for Posters
Message-ID: <[email-masked]>

Our apologies for cross-posting...
----
Dear colleagues,

Please kindly consider a poster contribution to ICNP'09 and/or forward
the following call for posters to interested people/students.

Thank you!
Xiaoming Fu (ICNP'09 Publicity Chair)

ICNP'09 Call for Posters:
========================
ICNP 2009 will hold a poster session to showcase "work-in-progress".
This has been a successful regular event at ICNP in past years and has
attracted many bright ideas that have developed into mature conference
and journal papers over time. The poster session will provide a great
chance for students to obtain feedback on their ongoing research from
knowledgeable conference attendees. In the past, these sessions have
been very well attended. While posters are welcome from everyone, we
particularly encourage on-going work in which the primary contributor
(i.e., first author) is a student. Extended (2-page) abstracts of the
posters will be reviewed by members of the Poster Session Committee. At
the conference, posters must be presented by one of the co-authors.

Posters submitted to this call for papers should contain unpublished
original ideas and not be abbreviations of published papers. The poster
extended abstract (2 pages) will be published in the conference
proceedings and CD, and put on the ICNP website.

Note that acceptance and presentation of a poster at ICNP 2009 will not
prevent authors from publishing a more complete version of their ideas
in future conferences and journals.

Important dates:
---------------
Submission deadline:          August 7, 2009, (Fri 23:59 PDT)
Notification of decisions:    August 28, 2009
Final version of abstracts:   September 4, 2009

Where to submit?
----------------
By email to: [email-masked]
Use Subject Line: ICNP 2009 poster submission Registration

At least one person must be registered for the conference to present the
poster. Students may register for the conference at the student rate for
presenting posters (if they are not presenting a full paper in the
conference which requires a full registration).
What the final poster should look like?

We define a poster to be 12 pages 8.5in x11in (letter size) on which you
can affix visually appealing material that describes your research.
Alternatively you can use the space as a continuum. You can arrange the
space and orient the poster either horizontally or vertically. You
should prepare the best material (visually appealing and succinct) that
effectively communicates your research problem, techniques, results, and
what is novel and important about your work. You are responsible for
printing your poster and bringing it to the conference site. We will
provide stands for you to mount your poster materials on.

Posters Review Committee
------------------------
Ahmed Helmy        University of Florida (Chair)
Sonia Fahmy        Purdue University
Romit Choudhury    Duke University

For questions: Email [email-masked]

From: [email-masked] (Bob Briscoe)
Date: Wed Jul 22 18:58:23 2009
Subject: [Iccrg] Congestion Transparency (re-ECN) ad hoc BoF @Stockholm IETF
Message-ID: <[email-masked]>

ICCRG & TSVAREA folks,

Just to announce this invite if you're not on the [email-masked] list.
Apologies if you are.

Bob

>Date: Wed, 22 Jul 2009 19:00:39 +0100
>To: re-ECN unIETF list <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Congestion Transparency (re-ECN) ad hoc BoF @Stockholm IETF
>
>Folks,
>
>I'd like to get together people who might be interested in helping 
>organise a BoF on Congestion Transparency (re-ECN) for a future IETF.
>
>15:00 - 16:30 CET Thu 30 Jul Rm 501 @ Stockholm IETF conference venue
>
>Pls give ideas for agenda items (I will too).
>
>This isn't intended to be a general show-and-tell - it's mainly for 
>people interested in helping/reviewing/discussing plans for a BoF to 
>form an IETF working group. This should complement the design team 
>work going on in ICCRG on a new capacity sharing architecture for 
>the Internet. 
><http://trac.tools.ietf.org/group/irtf/trac/wiki/CapacitySharingArch>
>
>For those who won't be able to attend (and those who will), this 
>list would also be a fine place to start discussions.
>
>The main idea is to get some protocol specification activity going 
>around re-ECN. Probably initially experimental track. So we can make 
>some practical progress. But there is also room for writing docs 
>about uses of congestion transparency and so on.
>
>My colleague Alan Smith has (finally) got the green light from our 
>employers to open source the Linux kernel code he has written. And 
>there are two implementations in ns2 that I know of, with another 
>two being planned. So we ought to be making sure the spec becomes 
>truly common property and starts to evolve to commonly agreed requirements.
>
>That means we have to be open to any changes, including using 
>better/different fields in protocol headers, choosing a different 
>name, and so on. But the most important thing is to make some 
>practical progress.
>
>
>
>Bob
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[Verizon])
Date: Mon Jul 13 15:25:15 2009
Subject: [Iccrg] draft ICCRG IETF 75 agenda posted
Message-ID: <[email-masked]>

A draft agenda for the ICCRG meeting at IETF 75 is
posted at:
http://www.ietf.org/proceedings/09jul/agenda/iccrg.txt

This is still open for additions, corrections, and
other bashing :).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------