Subject: [Iccrg] ICCRG meeting agenda
From: [email-masked] (Michael Welzl)
Date: Wed Aug 30 17:44:48 2006

Hi all,

Sorry - I forgot something: in your note to me, if you're
planning to attend and if you'd also like to give a talk
(i.e. you have something interesting to say, maybe a
strong opinion about the direction of ICCRG, or thought
provoking questions you'd like to ask, ..), let me know -
and also include a title and abstract, or a less formal
statement about the things you'd like to talk about.

Once I have these facts on the table, we can start working
on an agenda.

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Wed Aug 30 11:20:48 2006
Subject: [Iccrg] ICCRG meeting next February
Message-ID: <[email-masked]>

Dear all,

Let's have a meeting - it would be a great chance to move
things along in the right direction, and decide concrete
next steps.

I discussed this option recently with Aaron and Keshav,
and we agree that it would be best to co-locate it with
the next PFLDnet (Protocols for Fast Long Distance Networks)
workshop, which will take place in Marina del Rey on
February 7+8, 2007. In previous years, it seems that
PFLDnet has generally attracted just the right crowd.

A room is reserved for us on February 6, so this is
the (tentative) date of our meeting; if I receive
tons of emails saying "6th is impossible, but 9th
would work", that could also be an option.

Generally, I'd like to ask those of you who'd like to attend
to send me a short note, containing one of the following statements:

WILL DEFINITELY ATTEND
PLAN TO ATTEND
6TH IS IMPOSSIBLE BUT 9TH WOULD WORK
WOULD LIKE TO ATTEND BUT THESE DATES DON'T WORK FOR ME

Thanks!

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Wed Aug 23 19:35:44 2006
Subject: [Iccrg] PFLDnet2007 -- Call for papers
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Fifth International Workshop on Protocols for Fast, Long Distance networks, 2007
      (PFLDnet2007)
7, 8 February 2007,  ISI, Marina Del Rey (Los Angeles), California

http://wil.cs.caltech.edu/pfldnet2007/cfp.php

PAPER SUBMISSION DEADLINE:  13 OCTOBER, 2006

Future networks will increasingly contain high bandwidth, high delay
paths. Protocols for fast, long distance networks will have to expand
from experimental testbeds and into the wider world. In that process,
it is increasingly important for protocols which achieve high
utilization on fast, long distance networks also to have the qualities
required for widespread use, such as fairness and scalability to many
users.

PFLDnet2007 solicits papers which will further research towards on
protocols for tomorrow's high speed internet, at all stages along the
continuum from the requirements of today's grid networks, through
benchmarking of proposals, to the final selection of the next
generation of TCP.

Participants wishing to present a paper should upload a full paper to
the submission site by Friday 13 October, 2006.
Papers should be typically 4-5 pages, but no longer than 6 pages.

Scope: (choose at least one of the subject areas below - multiple
selections possible)

    * Protocol issues in fast long-distance networks
    * Protocol development
          o Enhancements of TCP and its variants
          o Novel data transport protocols designed for new application services
          o Explicit signaling protocols: Optimization criteria and
deployment strategies
          o Pacing and shaping of TCP and UDP traffic
          o Parallel transfers and multistreaming
    * Performance evaluation
          o Modeling and simulation-based results
          o Experiments on real networks and actual measurements
          o Protocol benchmarking
    * Hardware-specific issues
          o Transport over optical networks
          o RDMA over WANs
          o Protocol implementation and hardware issues (PCs, NICs,
TOEs, routers, switches, etc.)
          o Data replications and striping
    * Application focus
          o Requirements and experience from bandwidth demanding applications
          o Bulk-data transfer applications both TCP and non-TCP based
          o Transport service for Grids
          o QoS and scalability issues
          o Multicast over fast long-distance networks

Authors whose papers are selected for presentation will have the
option to submit a revised paper, to be published on the PFLDnet 2007
web site and in the PFLDnet 2007 proceedings.

Conference Co-Chairs:
    Lachlan Andrew
    Aaron Falk
    Medy Sanadidi

TPC Co-Chairs:
    Lachlan Andrew
    Doug Leith
    Medy Sanadidi

Important Dates
    ***Initial paper submission deadline: Friday 13 October, 2006***
    Acceptance notification: Monday 4 December, 2006
    Final paper submission: Wednesday 24 January, 2007
    Workshop: Wednesday and Thursday, 7 and 8 February, 2007

--
Lachlan Andrew, Doug Leith and Medy Sanadidi, TPC co-chairs

From: [email-masked] (Lachlan Andrew)
Date: Tue Aug 22 10:36:00 2006
Subject: [Iccrg] PFLDnet2007 -- Call for papers
Message-ID: <[email-masked]>

Fifth International Workshop on Protocols for Fast, Long Distance networks, 2007
      (PFLDnet2007)
7, 8 February 2007,  ISI, Marina Del Rey (Los Angeles), California

http://wil.cs.caltech.edu/pfldnet2007/cfp.php

PAPER SUBMISSION DEADLINE:  13 OCTOBER, 2006

Future networks will increasingly contain high bandwidth, high delay
paths. Protocols for fast, long distance networks will have to expand
from experimental testbeds and into the wider world. In that process,
it is increasingly important for protocols which achieve high
utilization on fast, long distance networks also to have the qualities
required for widespread use, such as fairness and scalability to many
users.

PFLDnet2007 solicits papers which will further research towards on
protocols for tomorrow's high speed internet, at all stages along the
continuum from the requirements of today's grid networks, through
benchmarking of proposals, to the final selection of the next
generation of TCP.

Participants wishing to present a paper should upload a full paper to
the submission site by Friday 13 October, 2006.
Papers should be typically 4-5 pages, but no longer than 6 pages.

Scope: (choose at least one of the subject areas below - multiple
selections possible)

    * Protocol issues in fast long-distance networks
    * Protocol development
          o Enhancements of TCP and its variants
          o Novel data transport protocols designed for new application services
          o Explicit signaling protocols: Optimization criteria and
deployment strategies
          o Pacing and shaping of TCP and UDP traffic
          o Parallel transfers and multistreaming
    * Performance evaluation
          o Modeling and simulation-based results
          o Experiments on real networks and actual measurements
          o Protocol benchmarking
    * Hardware-specific issues
          o Transport over optical networks
          o RDMA over WANs
          o Protocol implementation and hardware issues (PCs, NICs,
TOEs, routers, switches, etc.)
          o Data replications and striping
    * Application focus
          o Requirements and experience from bandwidth demanding applications
          o Bulk-data transfer applications both TCP and non-TCP based
          o Transport service for Grids
          o QoS and scalability issues
          o Multicast over fast long-distance networks

Authors whose papers are selected for presentation will have the
option to submit a revised paper, to be published on the PFLDnet 2007
web site and in the PFLDnet 2007 proceedings.

Conference Co-Chairs:
    Lachlan Andrew
    Aaron Falk
    Medy Sanadidi

TPC Co-Chairs:
    Lachlan Andrew
    Doug Leith
    Medy Sanadidi

Important Dates
    ***Initial paper submission deadline: Friday 13 October, 2006***
    Acceptance notification: Monday 4 December, 2006
    Final paper submission: Wednesday 24 January, 2007
    Workshop: Wednesday and Thursday, 7 and 8 February, 2007

--
Lachlan Andrew, Doug Leith and Medy Sanadidi, TPC co-chairs

From: [email-masked] ([email-masked])
Date: Mon Aug 21 08:28:00 2006
Subject: [Iccrg] Introducing MaxNet Explicit Congestion Control Protocol
Message-ID: <[email-masked]>

Dear ICCRG,

I would like to introduce to you the first implementation of the MaxNet 
Congestion Control Protocol. MaxNet is an explicit signal congestion control 
protocol, based on a theoretically proveable design. 

The implementation and papers are available at http://netlab.caltech.edu/maxnet/

The protocol is a culmination of many people's input over the years, and was 
developed at the University of Melbourne (Australia) and Caltech (USA). 
It is open to further input and improvement from you. 

Regards,
Bartek Wydrowski

From: [email-masked] (John Leslie)
Date: Mon Aug  7 18:59:28 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <20060807163623.GC62046@verdi>

Tony Li <[email-masked]> wrote:
> 
> IGRP has carried loading information since the early 80's.  Similarly,
> one of the early Arpanet routing algorithms (SPREAD, I think) carried
> load information.  Both were used in routing decisions and resulted in
> oscillation.

   Oscillation is a serious problem in routing. In a research environment,
it can be measured and appropriate damping can be calcultated. In actual
deployment, oscillation must be avoided.

> The control loop time constant for routing protocols is simply too long
> to be useful at conveying high frequency congestion event notification.
> However, very low frequency utilization information might be possible.
> I would tend to consider this first for IGPs, given their more limited
> scope than BGP.

   IGPs are a simpler problem, certainly; but oscillation must be avoided
there as well.

   IGRP is an excellent starting point to understand the issues. It
correctly identifies the issues of latency, bandwidth, load, and
reliability. More research, IMHO, would help determine a better way
of evaluating these and adjusting forwarding decisions.

- Latency is a minimal delay to reach the origin of the route. It
  obviously can be incremented by the (known) latency of each step
  along the way (not to be confused with the actual delay experienced
  by packets being queued along the way). I would suggest floating-point
  units of seconds.

- Bandwidth is the upper limit of bytes per second. It obviously can
  be evaluated and reduced if necessary at each forwarding step. I
  would suggest floating-point units of bytes per second.

- Load can be expressed either as bytes per second used or bytes per
  second unused. I would suggest the latter. I think it's clear that
  this should be a long-term average, say one hour. Further, I suggest
  that it be two (floating-point) numbers, such as mean and standard
  deviation.

- Reliability is a harder problem. Research is needed. As a starting
  point, I'd think in terms of reporting each failure to forward,
  with coding for the reason (discard, loss of carrier, etc.) and a
  floating-point estimate of bytes failed per bytes sent. Clearly
  such reports should not be propagated very far unless they show
  a substantial change in reliability.

   All of these numbers should be reported based upon the actual path
that a router will use for packets matching that route. We will have
to support environments in which different classes of packets are
routed differently. I assume routing updates will identify classes
to which the reported route applies. I also expect that multiple
paths may be used (without changing the routing updates sent).

   "Reliability", IMHO, should not be confused with route withdrawl.
If "reliability" actually reaches zero, obviously the route should
have been withdrawn; I would guess that "reliability" below 90%
might well justify route withdrawl, but perhaps research would show
otherwise. I only mean to suggest a benefit from reporting reduced
reliability appreciably before a route would be withdrawn.

   It's not clear what action a router "should" take when reduced
reliability is reported. In practice, we've found dropping one
packet per thousand to signal congestion can adequately maintain
basically dependable connections via end-to-end congestion avoidance.
I suspect some improvement might be possible through queueing and
redundancy (to avoid the need for retransmission), but I have no
data to back that up.

   (I hope it's clear I'm not talking about deploying changes to
backbone routers: I'm talking about research to find the sort of
changes which might be worth trying to deploy in the future.)

--
John Leslie <[email-masked]>

From: [email-masked] (Tony Li)
Date: Mon Aug  7 09:12:48 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> >    I doubt we can make much of a change at the backbone in the short
> > term. But research into what sorts of congestion 
> information might be
> > carried in routing updates seems quite useful.
> 
> I never stumbled upon a paper on such a thing - does anyone
> know if this has already been proposed? Any pointers?

IGRP has carried loading information since the early 80's.  Similarly,
one of the early Arpanet routing algorithms (SPREAD, I think) carried
load information.  Both were used in routing decisions and resulted in
oscillation.

The control loop time constant for routing protocols is simply too long
to be useful at conveying high frequency congestion event notification.
However, very low frequency utilization information might be possible.
I would tend to consider this first for IGPs, given their more limited
scope than BGP.

Tony

From: [email-masked] (Tony Li)
Date: Mon Aug  7 09:12:48 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> 1. RED is much easier to deploy without ECN than it is with ECN
> 
> 2. Explicit feedback that is not based on the current outbound
>    queue length might be easier to deploy

Yup.

> ... obviously, with 2, the question arises: what else could
> we feedback to sources?
> 
> What about a traffic measurement from the ingress link, such
> as MIB2-ifInOctets but obviously with a rule that these data
> must be updated whenever explicit signaling is requested -
> would that be more or less effort than feedback that is based
> on egress queue information?

That would be possible.  I'm not sure I see that that's useful, however.
Due to asymmetic routing, I'm also not sure that output bytes would be
useful either.

Tony

From: [email-masked] (Michael Welzl)
Date: Mon Aug  7 08:25:52 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <20060807020615.GB92422@verdi>
References: <001601c6b92f$a2677b10$0200a8c0@fun> <20060807020615.GB92422@verdi>
Message-ID: <[email-masked]>

> > Yet, such mechanisms are critical because they require additional
> > work in routers. So what is realistic? How much extra effort
> > can one really assume from routers, when the scalability of
> > a mechanism must not be constricted?
> 
>    At the research level, I'm not sure this question arises.

There is research and there is research  :)
Given the close releationship between the IRTF and the IETF, and
the role of the IRTF as a whole, I consider this question relevant
for ICCRG.

>    I doubt we can make much of a change at the backbone in the short
> term. But research into what sorts of congestion information might be
> carried in routing updates seems quite useful.

I never stumbled upon a paper on such a thing - does anyone
know if this has already been proposed? Any pointers?

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Mon Aug  7 08:25:52 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 2006-08-07 at 00:43, Tony Li wrote:
>  
> > > verifiability perspective.  Any in-band packet 
> > modifications (e.g., RFC
> > > 3168 ECN) are problematic because packet header examination and
> > > modification is typically done on the ingress side of the 
> > router, prior
> > > to the actual switching of the packet.  For scalability reasons,
> > > maintaining full active queue state on the input side of 
> > the system is
> > > challenging, as the queues only truly exist on the output side.
> > 
> > This part interests me: why is this a problem?
> > Is it because separate hardware pieces are involved on the ingress
> > and egress side, where every such piece (chip) would do all the
> > necessary work for one link only?
> 
> 
> Typical high end routers now are designed for tens or hundreds of
> thousands of queues.   Some systems are probably well over a million.
> The egress side has queue information that it needs to propagate in
> real-time to the ingress side over an unreliable medium.  This is
> certainly solvable, but it comes at a price in bandwidth and mechanism,
> multiplied by scale and timeliness.  Justifying that cost is, IMHO, very
> hard.

Thanks for elaborating! So, just to see if I got that right:
what you're saying means that:

1. RED is much easier to deploy without ECN than it is with ECN

2. Explicit feedback that is not based on the current outbound
   queue length might be easier to deploy

... obviously, with 2, the question arises: what else could
we feedback to sources?

What about a traffic measurement from the ingress link, such
as MIB2-ifInOctets but obviously with a rule that these data
must be updated whenever explicit signaling is requested -
would that be more or less effort than feedback that is based
on egress queue information?

Cheers,
Michael

From: [email-masked] (John Leslie)
Date: Mon Aug  7 04:29:04 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <001601c6b92f$a2677b10$0200a8c0@fun>
References: <001601c6b92f$a2677b10$0200a8c0@fun>
Message-ID: <20060807020615.GB92422@verdi>

Michael Welzl <[email-masked]> wrote:
> 
> There is no doubt that explicit feedback from routers is useful
> for a congestion control mechanism - this has been illustrated
> by mechanisms like XCP and Quickstart (and several others).

   It's obvious that sending packets we know will be discarded is
sub-optimal. The question is, how can we know they'll be discarded?
Clearly, this is an area deserving research.

> Yet, such mechanisms are critical because they require additional
> work in routers. So what is realistic? How much extra effort
> can one really assume from routers, when the scalability of
> a mechanism must not be constricted?

   At the research level, I'm not sure this question arises.

   Clearly, in the "real-world" Internet, there are routers which
cannot spare any per-packet processing time. But these "should" not
be the ones experiencing the congestion. (They get maximal advantage
of aggregation.)

   In principle, it should be possible to convey congestion status
in routing updates, and avoid introducing packets to congested routes
at packet rates which cannot be sustained.

   (It's not clear how we might retrofit that into current Internet
routing; that's another research area...)

> And how should the provision of such feedback be specified - e.g.
> with pseudocode, as in the appendix of the XCP paper, or something
> else...?

   Not an issue. Presumably we're smart enough to code from any
sufficiently detailed explanation.

> This kind of knowledge is missing in the congestion control
> landscape. Perhaps we can we make a change here.

   I doubt we can make much of a change at the backbone in the short
term. But research into what sorts of congestion information might be
carried in routing updates seems quite useful.

--
John Leslie <[email-masked]>

From: [email-masked] (Tony Li)
Date: Mon Aug  7 01:06:24 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <000501c6b9a4$4c560a00$0200a8c0@fun>
Message-ID: <[email-masked]>

> > verifiability perspective.  Any in-band packet 
> modifications (e.g., RFC
> > 3168 ECN) are problematic because packet header examination and
> > modification is typically done on the ingress side of the 
> router, prior
> > to the actual switching of the packet.  For scalability reasons,
> > maintaining full active queue state on the input side of 
> the system is
> > challenging, as the queues only truly exist on the output side.
> 
> This part interests me: why is this a problem?
> Is it because separate hardware pieces are involved on the ingress
> and egress side, where every such piece (chip) would do all the
> necessary work for one link only?

Typical high end routers now are designed for tens or hundreds of
thousands of queues.   Some systems are probably well over a million.
The egress side has queue information that it needs to propagate in
real-time to the ingress side over an unreliable medium.  This is
certainly solvable, but it comes at a price in bandwidth and mechanism,
multiplied by scale and timeliness.  Justifying that cost is, IMHO, very
hard.

Tony

From: [email-masked] (Michael Welzl)
Date: Mon Aug  7 00:23:44 2006
Subject: [Iccrg] Explicit feedback
References: <[email-masked]>
Message-ID: <000501c6b9a4$4c560a00$0200a8c0@fun>

> Would a former router vendor do?

Sure  :-)

> verifiability perspective.  Any in-band packet modifications (e.g., RFC
> 3168 ECN) are problematic because packet header examination and
> modification is typically done on the ingress side of the router, prior
> to the actual switching of the packet.  For scalability reasons,
> maintaining full active queue state on the input side of the system is
> challenging, as the queues only truly exist on the output side.

This part interests me: why is this a problem?
Is it because separate hardware pieces are involved on the ingress
and egress side, where every such piece (chip) would do all the
necessary work for one link only?

I have no idea about router hardware design, I'm just guessing.

Cheers,
Michael

From: [email-masked] (Tony Li)
Date: Sun Aug  6 22:45:36 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <001601c6b92f$a2677b10$0200a8c0@fun>
Message-ID: <[email-masked]>

Michael,

Would a former router vendor do?

A complete answer to your query would probably be more lengthy than what
you really intended, so I'm going to be relatively terse.  Please feel
free to ask me to expound where it's of interest.

Modern high end router design has a 100% pure hardware data path.  While
some instantiations actually have some degree of programmability, there
is nothing that looks like a general purpose processor executing
arbitrarily complicated code anywhere near the average packet.

Thus, what's realistic is extremely limited: any solution must not
require significant state, as there is typically very little high speed
memory available; any solution must also be relatively simple, both from
a computational complexity point of view, as well as from a
verifiability perspective.  Any in-band packet modifications (e.g., RFC
3168 ECN) are problematic because packet header examination and
modification is typically done on the ingress side of the router, prior
to the actual switching of the packet.  For scalability reasons,
maintaining full active queue state on the input side of the system is
challenging, as the queues only truly exist on the output side.
Out-of-band notification (e.g., ICMP source quench) is a security
nightmare.  Interaction with MPLS needs to be thought through and fully
specified.

Finally, on the non-technical front, the system replacement cycle is on
the order of five years, and router customer and router vendors need to
be presented with a direct and immediate business case for any
modifications.

I don't mean to sound discouraging, but any changes at this point would
be challenging.

Regards,
Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Welzl
> Sent: Sunday, August 06, 2006 1:09 AM
> To: iccrg
> Subject: [Iccrg] Explicit feedback
> 
> Hi,
> 
> There is no doubt that explicit feedback from routers is useful
> for a congestion control mechanism - this has been illustrated
> by mechanisms like XCP and Quickstart (and several others).
> 
> Yet, such mechanisms are critical because they require additional
> work in routers. So what is realistic? How much extra effort
> can one really assume from routers, when the scalability of
> a mechanism must not be constricted? And how should the
> provision of such feedback be specified - e.g. with pseudocode,
> as in the appendix of the XCP paper, or something else...?
> 
> This kind of knowledge is missing in the congestion control
> landscape. Perhaps we can we make a change here.
> 
> Presumably, the best answers would come from folks who
> work for router vendors - do we have some here? If so,
> could you please comment?
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

From: [email-masked] (Michael Welzl)
Date: Sun Aug  6 10:29:36 2006
Subject: [Iccrg] Explicit feedback
Message-ID: <001601c6b92f$a2677b10$0200a8c0@fun>

Hi,

There is no doubt that explicit feedback from routers is useful
for a congestion control mechanism - this has been illustrated
by mechanisms like XCP and Quickstart (and several others).

Yet, such mechanisms are critical because they require additional
work in routers. So what is realistic? How much extra effort
can one really assume from routers, when the scalability of
a mechanism must not be constricted? And how should the
provision of such feedback be specified - e.g. with pseudocode,
as in the appendix of the XCP paper, or something else...?

This kind of knowledge is missing in the congestion control
landscape. Perhaps we can we make a change here.

Presumably, the best answers would come from folks who
work for router vendors - do we have some here? If so,
could you please comment?

Cheers,
Michael