Subject: [Iccrg] Registration now open: PFLDnet 2009
From: [email-masked] (Lars Eggert)
Date: Mon Apr 27 15:30:14 2009

CALL FOR PARTICIPATION

PFLDNet 2009
The 7th International Workshop on Protocols for Future,
Large-Scale and Diverse Network Transports (PFLDNeT)

Akihabara, Tokyo, Japan
May 21-22, 2009
co-located with IRTF ICCRG meeting in May 20, 2009

Web page:          http://www.hpcc.jp/pfldnet2009/
Technical program: http://www.hpcc.jp/pfldnet2009/Program.html
*** Registration:  http://www.hpcc.jp/pfldnet2009/Registration_VISAS.html

Scope

The Internet continues to evolve along several dimensions, allowing
more and more end systems to communicate in increasingly diverse
ways. At one end of the performance spectrum, the Internet protocols
provide communication facilities for extremely-high-speed special-use
networks. At the other end of the performance spectrum, the Internet
contains very low-power and low-bandwidth networks that cater to
infrequent, bursty communication. Enabling efficient and high-
performance end-to-end communication across such a diverse internetwork
is a difficult problem, which is not solved by current transport
layer protocols.  The need to support an application base that grows
more and more dissimilar adds additional challenges.

The 7th International Workshop on Protocols for Future, Large-Scale
& Diverse Network Transports (PFLDNeT)brings together researchers
and practitioners from all continents to exchange their ideas and
experiences in the area of transport layer issues for modern
communication networks. The workshop provides theorists,  
experimentalists
and technologists with a focused, highly interactive opportunity
to present, discuss and exchange experience on leading research,
development and future directions in transport and application
protocols for networks that are increasingly growing in size,
heterogeneity and dynamicity of interaction.

PFLDNeT 2009 solicits papers that further the research on end-to-end
communication protocols for todays and tomorrows Internet in all
its diversity along the continuum from specialized grid networks,
optical transports, wireless connections, to lossy and low-power
networks.  A specific focus of the workshop lies on transport
protocols for the efficient end-to-end transfer of data for a diverse
set of applications and application-layer protocols.

Now approaching its seventh instantiation, the PFLDneT workshop has
broadened its focus over the years from protocols targeted at
specific fast, long-distance networks (the original expansion of
the PFLDneT acronym) into a venue where all kinds of new ideas
relating to end-to-end transport protocols for diverse network
scenarios are being discussed first.

The previous International Workshops on Protocols for Fast, Long-
Distance Networks held at CERN (2003), Argonne (2004), Lyon (2005),
Nara (2006), Marina del Rey (2007) and Manchester (2008) were very
successful in bringing together many researchers from all over the
world including North America, Europe and Asia who are working on
these problems.  PFLDNeT 2009 will continue this tradition, and
provide a perfect forum for researchers in this area to exchange
ideas and experience.

Topics

PFLDNeT 2009 covers all aspects related to transport protocols for the
current and future Internet, including, but not limited to:

- Protocol development
- Enhancements of TCP
- Innovative congestion control mechanisms
- Novel data transport protocols designed for new networks and
- applications
- Explicit signaling protocols: optimization criteria and deployment
- strategies
- Pacing and shaping of traffic
- Parallel transfers and multi-streaming
- Performance evaluation
- Modeling and simulation-based results
- Interaction of transport protocols and network equipment
- Experiments on real networks and live measurements
- Protocol benchmarking
- Transport over optical networks
- Protocol implementation and hardware issues
- End system performance
- Data replication and striping
- Applications with demanding or unusual network performance
- requirements
- Bulk-data transfer applications
- Transport service for Grids
- Quality-of-service and scalability issues
- Multicast

Workshop Organizers

Program Committee Chairs:
Lars Eggert, Nokia Research Center, FI
Kei Hiraki, The University of Tokyo, JP

Steering Committee:
Lachlan Andrew, Swinburne University of Technology, AU
Richard Hughes-Jones, Univ. of Manchester, UK
Katsushi Kobayashi, AIST, JP
Doug Leith, Hamilton Institute, IE
Injong Rhee, North Carolina State University, US
Pascale Vicat-Blanc, INRIA, FR
Michael Welzl, Univ. of Innsbruck, AT

Program Committee:
Dirceu Cavendish ,KIT, JP
Larry Dunn, Univ. of Minnesota, US
Tomohiro Kudoh , AIST, JP
Venkatram Vishwanath, EVL, USA
Steven Low, Caltech, US
Saverio Mascolo, Politecnico di Bari, IT
Hideyuki Shimonishi, NEC, JP
David X. Wei, Facebook, US
Yoshifumi Nishida, Sony CSL, JP
Joerg Ott, TKK, FI
Joe Touch, USC/ISI, US
Mark Handley, UCL, UK
Aleksandar Kuzmanovic, Northwestern University, US
-------------- 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/20090427/3013b26b/smime.bin
>From [email-masked]  Mon Apr 27 15:25:37 2009
From: [email-masked] (Lars Eggert)
Date: Mon Apr 27 15:30:32 2009
Subject: [Iccrg] Registration now open: PFLDnet 2009
Message-ID: <[email-masked]>

CALL FOR PARTICIPATION

PFLDNet 2009
The 7th International Workshop on Protocols for Future,
Large-Scale and Diverse Network Transports (PFLDNeT)

Akihabara, Tokyo, Japan
May 21-22, 2009
co-located with IRTF ICCRG meeting in May 20, 2009

Web page:          http://www.hpcc.jp/pfldnet2009/
Technical program: http://www.hpcc.jp/pfldnet2009/Program.html
*** Registration:  http://www.hpcc.jp/pfldnet2009/Registration_VISAS.html

Scope

The Internet continues to evolve along several dimensions, allowing
more and more end systems to communicate in increasingly diverse
ways. At one end of the performance spectrum, the Internet protocols
provide communication facilities for extremely-high-speed special-use
networks. At the other end of the performance spectrum, the Internet
contains very low-power and low-bandwidth networks that cater to
infrequent, bursty communication. Enabling efficient and high-
performance end-to-end communication across such a diverse internetwork
is a difficult problem, which is not solved by current transport
layer protocols.  The need to support an application base that grows
more and more dissimilar adds additional challenges.

The 7th International Workshop on Protocols for Future, Large-Scale
& Diverse Network Transports (PFLDNeT)brings together researchers
and practitioners from all continents to exchange their ideas and
experiences in the area of transport layer issues for modern
communication networks. The workshop provides theorists,  
experimentalists
and technologists with a focused, highly interactive opportunity
to present, discuss and exchange experience on leading research,
development and future directions in transport and application
protocols for networks that are increasingly growing in size,
heterogeneity and dynamicity of interaction.

PFLDNeT 2009 solicits papers that further the research on end-to-end
communication protocols for todays and tomorrows Internet in all
its diversity along the continuum from specialized grid networks,
optical transports, wireless connections, to lossy and low-power
networks.  A specific focus of the workshop lies on transport
protocols for the efficient end-to-end transfer of data for a diverse
set of applications and application-layer protocols.

Now approaching its seventh instantiation, the PFLDneT workshop has
broadened its focus over the years from protocols targeted at
specific fast, long-distance networks (the original expansion of
the PFLDneT acronym) into a venue where all kinds of new ideas
relating to end-to-end transport protocols for diverse network
scenarios are being discussed first.

The previous International Workshops on Protocols for Fast, Long-
Distance Networks held at CERN (2003), Argonne (2004), Lyon (2005),
Nara (2006), Marina del Rey (2007) and Manchester (2008) were very
successful in bringing together many researchers from all over the
world including North America, Europe and Asia who are working on
these problems.  PFLDNeT 2009 will continue this tradition, and
provide a perfect forum for researchers in this area to exchange
ideas and experience.

Topics

PFLDNeT 2009 covers all aspects related to transport protocols for the
current and future Internet, including, but not limited to:

- Protocol development
- Enhancements of TCP
- Innovative congestion control mechanisms
- Novel data transport protocols designed for new networks and
- applications
- Explicit signaling protocols: optimization criteria and deployment
- strategies
- Pacing and shaping of traffic
- Parallel transfers and multi-streaming
- Performance evaluation
- Modeling and simulation-based results
- Interaction of transport protocols and network equipment
- Experiments on real networks and live measurements
- Protocol benchmarking
- Transport over optical networks
- Protocol implementation and hardware issues
- End system performance
- Data replication and striping
- Applications with demanding or unusual network performance
- requirements
- Bulk-data transfer applications
- Transport service for Grids
- Quality-of-service and scalability issues
- Multicast

Workshop Organizers

Program Committee Chairs:
Lars Eggert, Nokia Research Center, FI
Kei Hiraki, The University of Tokyo, JP

Steering Committee:
Lachlan Andrew, Swinburne University of Technology, AU
Richard Hughes-Jones, Univ. of Manchester, UK
Katsushi Kobayashi, AIST, JP
Doug Leith, Hamilton Institute, IE
Injong Rhee, North Carolina State University, US
Pascale Vicat-Blanc, INRIA, FR
Michael Welzl, Univ. of Innsbruck, AT

Program Committee:
Dirceu Cavendish ,KIT, JP
Larry Dunn, Univ. of Minnesota, US
Tomohiro Kudoh , AIST, JP
Venkatram Vishwanath, EVL, USA
Steven Low, Caltech, US
Saverio Mascolo, Politecnico di Bari, IT
Hideyuki Shimonishi, NEC, JP
David X. Wei, Facebook, US
Yoshifumi Nishida, Sony CSL, JP
Joerg Ott, TKK, FI
Joe Touch, USC/ISI, US
Mark Handley, UCL, UK
Aleksandar Kuzmanovic, Northwestern University, US
-------------- 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/20090427/f7b6f306/smime.bin
>From [email-masked]  Wed Apr 29 07:04:12 2009
From: [email-masked] (Doan Hoang)
Date: Wed Apr 29 07:07:56 2009
Subject: [Iccrg] Healthcom 2009
Message-ID: <[email-masked]>

Dear Colleagues,

Kindly distribute this call for papers,

Regards,
Doan

Call for Papers

Healthcom 2009
11th International Conference on e-Health networking, Applications & 
Services
http://www.healthcom2009.org

Sydney, Australia
December 16-18, 2009

Paper Submission Deadline: June 12th, 2009

-- 
Doan B. Hoang, PhD			
Email: [email-masked]
http://www.inext.uts.edu.au
http://www.research.uts.edu.au/strengths/inext/overview.html

From: [email-masked] (Michael Welzl)
Date: Mon Apr 27 07:14:33 2009
Subject: [Iccrg] Agenda update
Message-ID: <[email-masked]>

Hi all,

I made a tentative agenda for the Tokyo meeting, available from:
http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09?version=2

Your input is welcome! Just send me an email.

Cheers,
Michael

From: [email-masked] (Matt Mathis)
Date: Tue Apr 21 21:24:42 2009
Subject: Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Sorry for the long delay...

On Tue, 7 Apr 2009, Bob Briscoe wrote:

> At 21:08 06/04/2009, Matt Mathis wrote:
>> I suggest that we start this conversation on the list...
>> 
>> As I see it, the first question is just trying to inventory the 
>> dimensionality of the transition space.  Some possible items (not in 
>> order):
>> 
>> Getting the IETF to agree on a new standard ECN
>
> I don't see changing ECN as necessary.

Ok, perhaps I should have worded it "agree to RE-ECN".
Some components might be the same, but the *system* is different.

>> In the network:
>>         Turning on ECN marking
>>         [NOT] Deploying rate fairness
>>         Updating marking algorithms to a new operating regime
>
> We've been at great pains to ensure the evolution path keeps forwarding 
> elements with ECN as is. We have enough problems getting ECN into L2 queues 
> as it is without changing the target mid-stream.

Agreed, however I suspect that people will find that more aggressive transport 
protocols are better behaved with more aggressive router responses.   I think 
this is likely to happen naturally later in the evolution.  At common scales 
I suspect that current ECN marking is just fine, but yes it has to be 
evaluated.

> We had worked out an early version of re-ECN in 2003. But until we worked out 
> a way to retrofit it to the Internet without requiring forwarding elements to 
> be changed, we didn't come to the IETF/IRTF. That's why we first appeared in 
> late 2005, when we had worked out how to introduce re-ECN only requiring a 
> change at the sender.

Note that there is a difference between "not requiring forwarding element 
changes" and being optimal.

> If we have to get a new marking behaviour it will never happen (IMHO). The 
> chances of getting r queues on a path all upgraded if each is upgraded with 
> independent probability p is p^r. Which for small p (say 10%) and even 
> reasonably small r (say 5) is vanishingly small (0.001%).

It is only needed at bottlenecks....

> But anyway, what makes you imagine we need to change network ECN behaviour?
>
>> Updating TCP (etc) receiver behavior in current stacks:
>>         From one ECN signal per RTT to counting signals per RTT
>> Updating TCP (etc) sender behavior in current stacks:
>>         Add RE-ECN marking
>>         Transition Congestion control from 1/sqrt(p) to 1/p
>>              How can we manage the co-existence?
>>         Adding a weight parameter to CC and the TCP API
>>         Getting OS vendors to turn ECN on
>
> I see a much easier transition. Already networks allow all sorts of end 
> system behaviours, while generally limiting users who are heavy overall. They 
> usually define heavy as lots of byte volume at peak times.
>
> For me, there is no problem moving from TCP-friendly to some other definition 
> of fairness, because no *network* uses TCP-friendly as a guiding star anyway. 
> That star was only followed in IETF-land and in the research community, so 
> they are the only lands that need to remove TCP from their mind-set. And, as 
> you heard from the hum in the transport area at San Francisco, those in the 
> room at the IETF seem to have abandoned TCP-friendly already :)
>
> Certainly, there are as many reasons for why no-one hummed for TCP-friendly 
> as there are people. And as many views on what direction we should take 
> instead. But IMHO we don't need to worry about introducing something that's 
> 1/p, rather than 1/sqrt(p), per se.
>
> We do have to avoid introducing something that
> a) continually ratchets up relative to competing transports (no stable 
> equilibrium)
> b) reduces the share of existing TCPs to near-nothing under normal operating 
> conditions.
>
> To me, that's a problem of choice of a constant, not the shape of the 
> response curve.

There is no constant W such that W/p is similar to 1/sqrt(p) across any 
significant portion of the global Internet.  If you know E(sqrt(p)) in some 
local region you can set W to that value (which happens to be reciprocal of 
the expected window size in packets).  As you note this is probably good enough 
for a provider with relatively uniform customers (such as BT), however in the 
global Internet p varies by at least 8 orders of magnitude and the "correct" 
value of W probably spans 4 orders of magnitude.  Picking a 
"one-size-fits-all" value doesn't work.

If you add an adaptive controller to estimate W at run time, then yes indeed 
you might be able to mimic the response of AIMD(1,0.5) congestion control. 
However, since the window adjustments (and losses) are constrained to be 
integral numbers of packets, the effective sampling frequency would drop to be 
the same as AIMD. (This is where the fluid approximation becomes useless). 
The whole point of 1/p congestion control is to get sampling frequency up high 
enough to be useful.  In the region where AIMD congestion control has an 
unreasonable sampling frequency it will be crushed by any loss based 
congestion control that has a reasonable sampling frequencies if the network 
sends the same signals (per packet independent) to each.  (Strictly speaking 
it comes into equilibrium, not "ratcheting", but the distinction is likely to 
be lost on the users).

>> Note that several of these should be more finely subdivided, and I am 
>> missing a bunch such as enforcing RE-ECN at borders as well as other 
>> potential inhibitory deployments.
>> 
>> Bob can you extend the list?
>
> I'd rather start a route plan that sets off in a different initial direction 
> to get to the same eventual end point. It starts in the policing direction 
> the industry is already taking. It allows a lot of leeway and slop on the 
> way.
>
> 1/ Get operators to understand the benefits of moving from policing volume to 
> policing congestion-volume, initially by counting congestion locally at 
> congested resources (ie without transparency of policing to the end-user, 
> which they don't care about now anyway). They can make this move 
> unilaterally.
>
> We're starting this in the MIT-based group I mentioned.

This is profoundly important if it can be done entirely locally.  This 
device/function needs a crisp name and to be written up really clearly for 
several different audiences.  Note that deploying it actually entails several 
sub-steps: not only convincing the operators that it is correct, but to put 
it in RFQ's with enough weight to have the router vendors build the gear, and 
then to actually deploy it.

I'd really like to see this algorithm.  Is it patented?  How much state is 
needed?  Can it be implemented at highly aggregated core routers?  How would 
it respond to relentless-TCP?

It is not my intent to prescribe what the network has to do, only that it does 
something to enforce some form of fairness.  I use WFQ etc for illustration 
because they are known by the community and easy to understand.

> 2/ Develop new (1/p) transports with weight (constant of proportionality) 
> set low, to be close to equal rate with a competing TCP flow under 'average' 
> conditions.

Such a constant doesn't exist for the reasons I indicated above.  Average for 
DSL != average for DOCSYS != average for FIOS.  Also average for GB != average 
for USA != average for Korea.

> Current volume policing will approximately incentivise these transports not 
> to set their weight too high without some special arrangement (eg. paying 
> more), merely because they will otherwise transfer lots of volume over time 
> and get stopped.

I fail to see how this adaptation will take place.   The end users can't tune 
their systems.  The application developers can't anticipate where their users 
are or what their network looks like.  If you make W adaptive, then the system 
reverts to 1/sqrt(p), with all of the problems that we want to avoid.

> Where there are special arrangements (experiments and real life), these 
> transports can be used for hi-speed by setting their weight to where you 
> would want it set eventually. They will create a lot more loss/ECN, and go a 
> lot faster, than competing TCPs, but that's the intention - only for where 
> there's plenty of capacity that TCP isn't using well.

This I agree with.

> On low capacity paths where such hi-speed isn't appropriate, it's up to 
> operators to limit users, which they have to do today - based on volume or 
> per-user rate.

Right - I'd really like to see an algorithm to do this based on congestion 
volume.   But somehow this feels circular to me.

> 3/ A missing piece is a signal from policer to transport, so the transport 
> knows when loss is because it has tripped a policing trigger (or close to it) 
> rather than just experiencing congestive loss.
>
> I've recently worked out half an idea for an in-band signal, but it uses a 
> re-ECN codepoint - we'd need something for today first. Preferably in-band, 
> so it just works. I think Dave Oran has ideas in this space too.

So this algorithm orthogonal to RE-ECN.  RE-ECN permits the policing to be 
done anywhere in the network and allows aggregation, but is independent of the 
design of the congestion controller.  Correct?

> 4/ In parallel, define an experimental extension header for re-ECN in IPv6 
> only.
> Reason: experiments are no longer allowed with IPv4 header fields (RFC4727), 
> even tho the specific field re-ECN needs (the evil bit) isn't mentioned.

I guess that depend on how you interpret 4827.

> 5/ Deploy experimental boundary policers using the congestion-volume info 
> provided by re-ECN (v6)
>
> As operators protect off their v6 networks with edge congestion policers, 
> they can remove all the other interim ad hoc policing stuff:
> - volume crossing the trust boundary
> - rate crossing the trust boundary
> - congestion at specific resources
>
> The main difference is that policing moves to being based on a transparent 
> metric that all sides can see and trust (re-ECN marks). And the metric 
> represents marginal cost of usage rather than very poor ad hoc 
> approximations. A competitive market is trying to drive providers to cost, so 
> this will be a natural end-point that the invisible hand of the market will 
> want to drive the Internet towards.

Yes, one would hope that deploying gear to do it right will cause older, less 
correct equipment to be retired.  The critical question is how much does the 
incorrect gear cause barriers to deployment for the newer algorithms?  Can 
the new and the old completely coexist?

> 6/ Apps find they can start increasing the weight of the new transports 
> defined at #2 without tripping off operator alarms (#3). So they do.

This step will be tested continuously, starting yesterday.

> 7/ If the experiments in v6 are successful, one assumes it will become de 
> facto used in v6. Then we need to define re-ECN for IPv4 too.

I thought you said you didn't want to change ECN?   :-)

> 8/ Let new cogestion controls evolve however the hell they want within the 
> new incentive framework that encourages responsiveness to congestion and 
> enforces it in extremum. There will be good reason for transports to respond 
> as (1/p), but we don't have to mandate that. Any response (1/p^b) is OK (0 < 
> b <= 1). We want to allow new apps to evolve in the mix. But the IETF/IRTF 
> needs to define best practice and some good generic transport(s).

> As you can see, overall this is a more liberal path, which I believe better 
> matches the way networks and their customers will push each other naturally.

I think your interpretation of it being more liberal is only due to missing 
details in both..

> My working model is that no-one will do what the IETF mandates, but they 
> might use what the IETF provides if it is in their interests for 
> interworking. The IETF only provides the tools for the battle, not the 
> behaviour guidelines.

I would concur with this.

>> At this stage I would add items (and not replace existing items) even if 
>> they are not orthogonal.  It would be better to make the coverage as 
>> complete as possible even if some of the items are redundant.
>> 
>> One task for the meeting would trying to imagine a partial ordering on the 
>> smaller steps, such that each one is motivated by the preceding steps, and 
>> not excessively inhibited by any negating technology.

> We have different views on the ordering of the big steps to deal with first 
> :)

No, deciding which steps to do first presupposes the outcome.  I would rather 
start from an inventory of all possible first (and other) steps and then 
as a separate process weed out the ones that lead to bad outcomes or are 
infeasible.   This is in the style of brainstorming, where know bad ideas are 
not discarded until later in the process, because sometimes they stimulate 
additional good ideas.

>> Thanks,
>> --MM--
>> -------------------------------------------
>> Matt Mathis     http://staff.psc.edu/mathis
>> Work:412.268.3319    Home/Cell:412.654.7529
>> -------------------------------------------
>> Evil is defined by mortals who think they know
>> "The Truth" and use force to apply it to others.
>> 
>> On Thu, 26 Mar 2009, Bob Briscoe wrote:
>> 
>>> Matt,
>>> 
>>> It would be useful to get a 'design team' together to thrash out the 
>>> roadmap to get from the death of TCP-friendliness to somewhere else.
>>> - You have your path.
>>> - I have mine.
>>> - Perhaps others have theirs.
>>> - They all have common points and differences.
>>> 
>>> A roadmap is about all the places we could visit and which ones are places 
>>> of interest and which ones are shit-holes. It's not a route-plan. We don't 
>>> all have to agree on the destination, or on the path. Just the pits to 
>>> avoid and the high points we don't want to block off. For instance, 
>>> identifying that travelling via place M precludes getting to place Z.
>>> 
>>> Would Tokyo be a good venue? I don't know who will be there. Or should we 
>>> wait until an ICCRG co-located with an IETF? Or should we say Tokyo is 
>>> where the discussion will start, so come if you want to start the journet? 
>>> I would come if we did that. But currently I have no plans to be in Tokyo, 
>>> just because I'm travelling too much.
>>> 
>>> 
>>> Bob
>>> 
>>> 
>>>> From: Michael Welzl <[email-masked]>
>>>> To: [email-masked]
>>>> Organization: University of Innsbruck
>>>> Date: Tue, 24 Mar 2009 17:17:43 +0100
>>>> X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
>>>> X-Spam-Score: 0.001 () UNPARSEABLE_RELAY
>>>> X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
>>>> X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140
>>>> X-UCL-MailScanner-Information: Please contact the UCL Helpdesk,
>>>>         [email-masked] for more information
>>>> X-MailScanner-ID: 1Lm9K4-00056n-Au
>>>> X-UCL-MailScanner: Found to be clean
>>>> X-UCL-MailScanner-From: [email-masked]
>>>> X-Spam-Status: No
>>>> Subject: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
>>>> X-BeenThere: [email-masked]
>>>> X-Mailman-Version: 2.1.5
>>>> List-Id: "Discussions of Internet Congestion Control Research Group 
>>>> \(ICCRG\)"
>>>>         <iccrg.cs.ucl.ac.uk>
>>>> List-Unsubscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>,
>>>>         <mailto:[email-masked]?subject=unsubscribe>
>>>> List-Archive: <http://oakham.cs.ucl.ac.uk/pipermail/iccrg>
>>>> List-Post: <mailto:[email-masked]>
>>>> List-Help: <mailto:[email-masked]?subject=help>
>>>> List-Subscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>,
>>>>         <mailto:[email-masked]?subject=subscribe>
>>>> Sender: [email-masked]
>>>> X-OriginalArrivalTime: 24 Mar 2009 19:06:08.0437 (UTC) 
>>>> FILETIME=[96B57E50:01C9ACB3]
>>>> X-EsetId: C30EC8256EB3173D9542
>>>> Dear all,
>>>> As announced quite some time ago, and not mentioned again
>>>> for a long time - sorry!! - we will have the next ICCRG
>>>> meeting in Tokyo, co-located with PFLDNet; details:
>>>> http://www.hpcc.jp/pfldnet2009/Top.html
>>>> I will be your host  :)
>>>> Please send me suggestions for agenda items to Wes
>>>> and me ASAP so that we can start building it. Thanks!
>>>> Cheers,
>>>> Michael
>>>> 
>>>> _______________________________________________
>>>> Iccrg mailing list
>>>> [email-masked]
>>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>> 
>>> ________________________________________________________________
>>> Bob Briscoe,               Networks Research Centre, BT Research
>> 
>> ________________________________________________________________
>> Bob Briscoe,               Networks Research Centre, BT Research

From: [email-masked] (Bob Briscoe)
Date: Wed Apr  8 00:49:07 2009
Subject: Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
In-Reply-To: <[email-masked] m>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lachlan,

inline...

At 22:33 07/04/2009, Lachlan Andrew wrote:
>Greetings Bob,
>
>2009/4/8 Bob Briscoe <[email-masked]>:
> >
> > 1/ Get operators to understand the benefits of moving from policing volume
> > to policing congestion-volume, initially by counting congestion locally at
> > congested resources (ie without transparency of policing to the end-user,
> > which they don't care about now anyway).
> >
> > 2/ Develop new (1/p) transports with weight (constant of proportionality)
> > set low, to be close to equal rate with a competing TCP flow 
> under 'average'
> > conditions.
> >
> > Current volume policing will approximately incentivise these transports not
> > to set their weight too high without some special arrangement (eg. paying
> > more), merely because they will otherwise transfer lots of volume over time
> > and get stopped.
>
>Does that incentive require that the transport know the policing rules
>used by the operators?  A particular OS/stack can't evolve in time to
>reflect the gradual changes of throttling policy by different
>operators.  However, if it could, relying on the punishment would mean
>that the current incentive is simply to be as aggressive as possible,
>wouldn't it?

The key is that policing shouldn't just be a memoryless instantaneous process.

We've written this paper to show that a policer can be designed to 
gently take over enforcing a congestion response if the overall 
volume of congestion from one customer is excessive *over time*. But 
it makes it in the interests of stack designers to *at most* fly just 
below the radar of the particular policer it encounters at run-time 
(to avoid the additional drop from exceeding the policed limit).
"Policing Freedom to use the Internet Resource Pool"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#polfree>

Note however that policing can kick in because:
a) the transport is *set* aggressively at design time, or
b) because the transport is simply *used* excessively at run-time 
(e.g. users make their apps send too much data through the transport).

Corollary: a stack won't be designed to be as aggressive as possible, 
because it has to cater for a wide range of run-time circumstances: 
it doesn't know what the user might want to do in the future, so it 
doesn't want to run too close to the limit all the time and leave 
nothing spare for later.

>I think the current incentive not to be too aggressive is
>over-buffered low-speed dedicated access links (e.g. ADSL), where the
>user is only competing against its own flows.

My vision is an Internet that doesn't have to be constricted at the 
access. Rather than giving 100 users only 100M each from a 10G PON, 
they could all peak at 10G. I believe this would be possible if they 
were limited in the congestion they could cause over time in the 
whole Internet (including in their PON). Similarly for other shared 
access technologies like UMTS, WLAN, cable and so on. As access 
technologies get faster, we have to move away from relying on access 
rate restrictions to keep everthing well-tempered.

Incidentally, there is already an incentive for app writers to be as 
aggressive as possible (including auto-config to fit to the line they 
encounter at run-time). Although they don't necessarily consciously 
write apps to game the system, app code does evolve so that faster 
strategies get selected more often. An app opening more flows is one 
example. It's equivalent to setting a higher weight in a weighted transport.

Cheers

Bob

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

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Lachlan Andrew)
Date: Tue Apr  7 22:40:31 2009
Subject: Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Bob,

2009/4/8 Bob Briscoe <[email-masked]>:
>
> 1/ Get operators to understand the benefits of moving from policing volume
> to policing congestion-volume, initially by counting congestion locally at
> congested resources (ie without transparency of policing to the end-user,
> which they don't care about now anyway).
>
> 2/ Develop new (1/p) transports with weight (constant of proportionality)
> set low, to be close to equal rate with a competing TCP flow under 'average'
> conditions.
>
> Current volume policing will approximately incentivise these transports not
> to set their weight too high without some special arrangement (eg. paying
> more), merely because they will otherwise transfer lots of volume over time
> and get stopped.

Does that incentive require that the transport know the policing rules
used by the operators?  A particular OS/stack can't evolve in time to
reflect the gradual changes of throttling policy by different
operators.  However, if it could, relying on the punishment would mean
that the current incentive is simply to be as aggressive as possible,
wouldn't it?

I think the current incentive not to be too aggressive is
over-buffered low-speed dedicated access links (e.g. ADSL), where the
user is only competing against its own flows.

Cheers,
Lachlan

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

From: [email-masked] (Bob Briscoe)
Date: Tue Apr  7 19:17:42 2009
Subject: Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Matt,

At 21:08 06/04/2009, Matt Mathis wrote:
>I suggest that we start this conversation on the list...
>
>As I see it, the first question is just trying to inventory the 
>dimensionality of the transition space.  Some possible items (not in order):
>
>Getting the IETF to agree on a new standard ECN

I don't see changing ECN as necessary.

>In the network:
>         Turning on ECN marking
>         [NOT] Deploying rate fairness
>         Updating marking algorithms to a new operating regime

We've been at great pains to ensure the evolution path keeps 
forwarding elements with ECN as is. We have enough problems getting 
ECN into L2 queues as it is without changing the target mid-stream.

We had worked out an early version of re-ECN in 2003. But until we 
worked out a way to retrofit it to the Internet without requiring 
forwarding elements to be changed, we didn't come to the IETF/IRTF. 
That's why we first appeared in late 2005, when we had worked out how 
to introduce re-ECN only requiring a change at the sender.

If we have to get a new marking behaviour it will never happen 
(IMHO). The chances of getting r queues on a path all upgraded if 
each is upgraded with independent probability p is p^r. Which for 
small p (say 10%) and even reasonably small r (say 5) is vanishingly 
small (0.001%).

But anyway, what makes you imagine we need to change network ECN behaviour?

>Updating TCP (etc) receiver behavior in current stacks:
>         From one ECN signal per RTT to counting signals per RTT
>Updating TCP (etc) sender behavior in current stacks:
>         Add RE-ECN marking
>         Transition Congestion control from 1/sqrt(p) to 1/p
>              How can we manage the co-existence?
>         Adding a weight parameter to CC and the TCP API
>         Getting OS vendors to turn ECN on

I see a much easier transition. Already networks allow all sorts of 
end system behaviours, while generally limiting users who are heavy 
overall. They usually define heavy as lots of byte volume at peak times.

For me, there is no problem moving from TCP-friendly to some other 
definition of fairness, because no *network* uses TCP-friendly as a 
guiding star anyway. That star was only followed in IETF-land and in 
the research community, so they are the only lands that need to 
remove TCP from their mind-set. And, as you heard from the hum in the 
transport area at San Francisco, those in the room at the IETF seem 
to have abandoned TCP-friendly already :)

Certainly, there are as many reasons for why no-one hummed for 
TCP-friendly as there are people. And as many views on what direction 
we should take instead. But IMHO we don't need to worry about 
introducing something that's 1/p, rather than 1/sqrt(p), per se.

We do have to avoid introducing something that
a) continually ratchets up relative to competing transports (no 
stable equilibrium)
b) reduces the share of existing TCPs to near-nothing under normal 
operating conditions.

To me, that's a problem of choice of a constant, not the shape of the 
response curve.

>Note that several of these should be more finely subdivided, and I 
>am missing a bunch such as enforcing RE-ECN at borders as well as 
>other potential inhibitory deployments.
>
>Bob can you extend the list?

I'd rather start a route plan that sets off in a different initial 
direction to get to the same eventual end point. It starts in the 
policing direction the industry is already taking. It allows a lot of 
leeway and slop on the way.

1/ Get operators to understand the benefits of moving from policing 
volume to policing congestion-volume, initially by counting 
congestion locally at congested resources (ie without transparency of 
policing to the end-user, which they don't care about now anyway). 
They can make this move unilaterally.

We're starting this in the MIT-based group I mentioned.

2/ Develop new (1/p) transports with weight (constant of 
proportionality) set low, to be close to equal rate with a competing 
TCP flow under 'average' conditions.

Current volume policing will approximately incentivise these 
transports not to set their weight too high without some special 
arrangement (eg. paying more), merely because they will otherwise 
transfer lots of volume over time and get stopped.

Where there are special arrangements (experiments and real life), 
these transports can be used for hi-speed by setting their weight to 
where you would want it set eventually. They will create a lot more 
loss/ECN, and go a lot faster, than competing TCPs, but that's the 
intention - only for where there's plenty of capacity that TCP isn't 
using well.

On low capacity paths where such hi-speed isn't appropriate, it's up 
to operators to limit users, which they have to do today - based on 
volume or per-user rate.

3/ A missing piece is a signal from policer to transport, so the 
transport knows when loss is because it has tripped a policing 
trigger (or close to it) rather than just experiencing congestive loss.

I've recently worked out half an idea for an in-band signal, but it 
uses a re-ECN codepoint - we'd need something for today first. 
Preferably in-band, so it just works. I think Dave Oran has ideas in 
this space too.

4/ In parallel, define an experimental extension header for re-ECN in 
IPv6 only.
Reason: experiments are no longer allowed with IPv4 header fields 
(RFC4727), even tho the specific field re-ECN needs (the evil bit) 
isn't mentioned.

5/ Deploy experimental boundary policers using the congestion-volume 
info provided by re-ECN (v6)

As operators protect off their v6 networks with edge congestion 
policers, they can remove all the other interim ad hoc policing stuff:
- volume crossing the trust boundary
- rate crossing the trust boundary
- congestion at specific resources

The main difference is that policing moves to being based on a 
transparent metric that all sides can see and trust (re-ECN marks). 
And the metric represents marginal cost of usage rather than very 
poor ad hoc approximations. A competitive market is trying to drive 
providers to cost, so this will be a natural end-point that the 
invisible hand of the market will want to drive the Internet towards.

6/ Apps find they can start increasing the weight of the new 
transports defined at #2 without tripping off operator alarms (#3). So they do.

7/ If the experiments in v6 are successful, one assumes it will 
become de facto used in v6. Then we need to define re-ECN for IPv4 too.

8/ Let new cogestion controls evolve however the hell they want 
within the new incentive framework that encourages responsiveness to 
congestion and enforces it in extremum. There will be good reason for 
transports to respond as (1/p), but we don't have to mandate that. 
Any response (1/p^b) is OK (0 < b <= 1). We want to allow new apps to 
evolve in the mix. But the IETF/IRTF needs to define best practice 
and some good generic transport(s).

______
As you can see, overall this is a more liberal path, which I believe 
better matches the way networks and their customers will push each 
other naturally.

My working model is that no-one will do what the IETF mandates, but 
they might use what the IETF provides if it is in their interests for 
interworking. The IETF only provides the tools for the battle, not 
the behaviour guidelines.

Bob

>At this stage I would add items (and not replace existing items) 
>even if they are not orthogonal.  It would be better to make the 
>coverage as complete as possible even if some of the items are redundant.
>
>One task for the meeting would trying to imagine a partial ordering 
>on the smaller steps, such that each one is motivated by the 
>preceding steps, and not excessively inhibited by any negating technology.

We have different views on the ordering of the big steps to deal with first :)

Bob

>Thanks,
>--MM--
>-------------------------------------------
>Matt Mathis     http://staff.psc.edu/mathis
>Work:412.268.3319    Home/Cell:412.654.7529
>-------------------------------------------
>Evil is defined by mortals who think they know
>"The Truth" and use force to apply it to others.
>
>On Thu, 26 Mar 2009, Bob Briscoe wrote:
>
>>Matt,
>>
>>It would be useful to get a 'design team' together to thrash out 
>>the roadmap to get from the death of TCP-friendliness to somewhere else.
>>- You have your path.
>>- I have mine.
>>- Perhaps others have theirs.
>>- They all have common points and differences.
>>
>>A roadmap is about all the places we could visit and which ones are 
>>places of interest and which ones are shit-holes. It's not a 
>>route-plan. We don't all have to agree on the destination, or on 
>>the path. Just the pits to avoid and the high points we don't want 
>>to block off. For instance, identifying that travelling via place M 
>>precludes getting to place Z.
>>
>>Would Tokyo be a good venue? I don't know who will be there. Or 
>>should we wait until an ICCRG co-located with an IETF? Or should we 
>>say Tokyo is where the discussion will start, so come if you want 
>>to start the journet? I would come if we did that. But currently I 
>>have no plans to be in Tokyo, just because I'm travelling too much.
>>
>>
>>Bob
>>
>>
>>>From: Michael Welzl <[email-masked]>
>>>To: [email-masked]
>>>Organization: University of Innsbruck
>>>Date: Tue, 24 Mar 2009 17:17:43 +0100
>>>X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
>>>X-Spam-Score: 0.001 () UNPARSEABLE_RELAY
>>>X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
>>>X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140
>>>X-UCL-MailScanner-Information: Please contact the UCL Helpdesk,
>>>         [email-masked] for more information
>>>X-MailScanner-ID: 1Lm9K4-00056n-Au
>>>X-UCL-MailScanner: Found to be clean
>>>X-UCL-MailScanner-From: [email-masked]
>>>X-Spam-Status: No
>>>Subject: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
>>>X-BeenThere: [email-masked]
>>>X-Mailman-Version: 2.1.5
>>>List-Id: "Discussions of Internet Congestion Control Research 
>>>Group \(ICCRG\)"
>>>         <iccrg.cs.ucl.ac.uk>
>>>List-Unsubscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>,
>>>         <mailto:[email-masked]?subject=unsubscribe>
>>>List-Archive: <http://oakham.cs.ucl.ac.uk/pipermail/iccrg>
>>>List-Post: <mailto:[email-masked]>
>>>List-Help: <mailto:[email-masked]?subject=help>
>>>List-Subscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>,
>>>         <mailto:[email-masked]?subject=subscribe>
>>>Sender: [email-masked]
>>>X-OriginalArrivalTime: 24 Mar 2009 19:06:08.0437 (UTC) 
>>>FILETIME=[96B57E50:01C9ACB3]
>>>X-EsetId: C30EC8256EB3173D9542
>>>Dear all,
>>>As announced quite some time ago, and not mentioned again
>>>for a long time - sorry!! - we will have the next ICCRG
>>>meeting in Tokyo, co-located with PFLDNet; details:
>>>http://www.hpcc.jp/pfldnet2009/Top.html
>>>I will be your host  :)
>>>Please send me suggestions for agenda items to Wes
>>>and me ASAP so that we can start building it. Thanks!
>>>Cheers,
>>>Michael
>>>
>>>_______________________________________________
>>>Iccrg mailing list
>>>[email-masked]
>>>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>________________________________________________________________
>>Bob Briscoe,               Networks Research Centre, BT Research
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Michael Welzl)
Date: Tue Apr  7 10:51:10 2009
Subject: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear ICCRG'ers,

Feedback to this announcement has been disappointingly
limited, to say the least. PLEASE, if you consider attending
and want to give a talk, send your input to Wes and me NOW.

( Surely there will be some overlap between ICCRG and
  Pfldnet and participants, and the latter may still be
  waiting to see if they have a paper accepted... but, as
  these notifications for Pfldnet will be sent out soon,
  I figured that this may be a good time for a reminder.  )

Cheers,
Michael

On Tue, 2009-03-24 at 17:17 +0100, Michael Welzl wrote:
> Dear all,
> 
> As announced quite some time ago, and not mentioned again
> for a long time - sorry!! - we will have the next ICCRG
> meeting in Tokyo, co-located with PFLDNet; details:
> http://www.hpcc.jp/pfldnet2009/Top.html
> 
> I will be your host  :)
> 
> Please send me suggestions for agenda items to Wes
> and me ASAP so that we can start building it. Thanks!
> 
> Cheers,
> Michael
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

From: [email-masked] (Matt Mathis)
Date: Mon Apr  6 21:15:40 2009
Subject: Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I suggest that we start this conversation on the list...

As I see it, the first question is just trying to inventory the dimensionality 
of the transition space.  Some possible items (not in order):

Getting the IETF to agree on a new standard ECN
In the network:
         Turning on ECN marking
         [NOT] Deploying rate fairness
 	Updating marking algorithms to a new operating regime
Updating TCP (etc) receiver behavior in current stacks:
         From one ECN signal per RTT to counting signals per RTT
Updating TCP (etc) sender behavior in current stacks:
 	Add RE-ECN marking
 	Transition Congestion control from 1/sqrt(p) to 1/p
 	     How can we manage the co-existence?
 	Adding a weight parameter to CC and the TCP API
 	Getting OS vendors to turn ECN on

Note that several of these should be more finely subdivided, and I am missing 
a bunch such as enforcing RE-ECN at borders as well as other potential 
inhibitory deployments.

Bob can you extend the list?

At this stage I would add items (and not replace existing items) even if they 
are not orthogonal.  It would be better to make the coverage as complete as 
possible even if some of the items are redundant.

One task for the meeting would trying to imagine a partial ordering on the 
smaller steps, such that each one is motivated by the preceding steps, and not 
excessively inhibited by any negating technology.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Thu, 26 Mar 2009, Bob Briscoe wrote:

> Matt,
>
> It would be useful to get a 'design team' together to thrash out the roadmap 
> to get from the death of TCP-friendliness to somewhere else.
> - You have your path.
> - I have mine.
> - Perhaps others have theirs.
> - They all have common points and differences.
>
> A roadmap is about all the places we could visit and which ones are places of 
> interest and which ones are shit-holes. It's not a route-plan. We don't all 
> have to agree on the destination, or on the path. Just the pits to avoid and 
> the high points we don't want to block off. For instance, identifying that 
> travelling via place M precludes getting to place Z.
>
> Would Tokyo be a good venue? I don't know who will be there. Or should we 
> wait until an ICCRG co-located with an IETF? Or should we say Tokyo is where 
> the discussion will start, so come if you want to start the journet? I would 
> come if we did that. But currently I have no plans to be in Tokyo, just 
> because I'm travelling too much.
>
>
> Bob
>
>
>> From: Michael Welzl <[email-masked]>
>> To: [email-masked]
>> Organization: University of Innsbruck
>> Date: Tue, 24 Mar 2009 17:17:43 +0100
>> X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
>> X-Spam-Score: 0.001 () UNPARSEABLE_RELAY
>> X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
>> X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140
>> X-UCL-MailScanner-Information: Please contact the UCL Helpdesk,
>>         [email-masked] for more information
>> X-MailScanner-ID: 1Lm9K4-00056n-Au
>> X-UCL-MailScanner: Found to be clean
>> X-UCL-MailScanner-From: [email-masked]
>> X-Spam-Status: No
>> Subject: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
>> X-BeenThere: [email-masked]
>> X-Mailman-Version: 2.1.5
>> List-Id: "Discussions of Internet Congestion Control Research Group 
>> \(ICCRG\)"
>>         <iccrg.cs.ucl.ac.uk>
>> List-Unsubscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>,
>>         <mailto:[email-masked]?subject=unsubscribe>
>> List-Archive: <http://oakham.cs.ucl.ac.uk/pipermail/iccrg>
>> List-Post: <mailto:[email-masked]>
>> List-Help: <mailto:[email-masked]?subject=help>
>> List-Subscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>,
>>         <mailto:[email-masked]?subject=subscribe>
>> Sender: [email-masked]
>> X-OriginalArrivalTime: 24 Mar 2009 19:06:08.0437 (UTC) 
>> FILETIME=[96B57E50:01C9ACB3]
>> X-EsetId: C30EC8256EB3173D9542
>> 
>> Dear all,
>> 
>> As announced quite some time ago, and not mentioned again
>> for a long time - sorry!! - we will have the next ICCRG
>> meeting in Tokyo, co-located with PFLDNet; details:
>> http://www.hpcc.jp/pfldnet2009/Top.html
>> 
>> I will be your host  :)
>> 
>> Please send me suggestions for agenda items to Wes
>> and me ASAP so that we can start building it. Thanks!
>> 
>> Cheers,
>> Michael
>> 
>> 
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
> ________________________________________________________________
> Bob Briscoe,               Networks Research Centre, BT Research