Subject: [Iccrg] RE: [tsv-area] Congestion Exposure (re-ECN): to BoF or to Bar BoF?
From: [email-masked] (philip.eardley)
Date: Thu May 28 10:28:26 2009

Bob

I support this work. My views are that:

- work on Congestion Exposure (re-ECN) & TCP-unfriendly can proceed in
parallel - and in fact, given the time to get things done, the work
needs to be done in parallel. They're separate things - eg re-eCN
implies changes in network gateways, tcp-unfriendly could be useful in
some environments without re-ecn. (of course I'm not saying they're
completely independent - eg as you point out below their motivations are
connected.)
- on re-ecn, personally I don't see the benefit of waiting and would
prefer a BoF in Stockholm
- it would be good to see a proto-charter, or at least a list of
documents the WG would produce. Do you envisage the protocols being Expt
or Stds track? Is the output 1 protocol with similar scope to the
draft-briscoe-tsvwg-re-ecn-tcp, or are there more protocols? Plus what
other informational docs? - maybe some examples of how to use the
protocol - sort of an architecture doc?
- to me the point of the congestion exposure is that it's transparent in
2 senses: (1) it's visible to all network nodes (2) it's truthful. To
me, the reason re-ecn is very interesting is that it promises to give
both. I think both should be mentioned up front in any proto-charter as
what the objectives are.

Phil.

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On
{ Behalf Of Bob Briscoe
{ Sent: 21 May 2009 09:37
{ To: tsv-area IETF list
{ Cc: iccrg IRTF list
{ Subject: [tsv-area] Congestion Exposure (re-ECN): to BoF or to Bar
BoF?
{ 
{ TSV Area folks,
{ 
{ [Please continue this discussion on tsvarea]
{ 
{ I'd like to launch a concrete protocol-specification activity on
{ congestion exposure (with re-ECN as a candidate solution) in
{ Stockholm? Here at the ICCRG in Tokyo, we've just agreed that this
{ doesn't conflict with the new IRTF ICCRG  design team in this space
{ or prejudge any consensus on direction (see background below). The
{ question is purely about timing...
{ 
{ I'm finding that re-ECN seems to feature somewhere in the plans of
{ those expressing an opinion in the ICCRG discussions. My concern: the
{ protocol that will take longest needs to be finished soonest. E.g.
{ ECN took 7 years from first research paper to proposed standard.
{ 
{ Therefore, I'd like to propose we get started on a specific protocol
{ specification activity, in parallel to the ICCRG design team. We have
{ to set this up so it doesn't imply it is the *official and only* way
{ forward. But it's a good punt to be starting on.
{ 
{ My questions are:
{ * Do you think discussions should start on building a BoF on
{ "Congestion Exposure" in Stockholm (getting late but still do-able)?
{ * Or less ambitiously should we arrange another ad hoc BoF (bar BoF)
{ in Stockholm, building on ICCRG work in Tokyo this week, to get a
{ community together to form a BoF later?
{ * Or do people actively oppose anyone doing anything yet on
{ congestion exposure or re-ECN in the IETF or IRTF?
{ 
{ Background on TCP-unfriendly and on re-ECN
{ -------------------------------------------
{ You may be aware that, in San Francisco we had discussions in TSVArea
{ (prompted by Matt Mathis's talk) on whether to move beyond
{ TCP-friendliness as a comprehensive direction for both sharing
{ Internet capacity and future congestion controls. In the IRTF ICCRG
{ the same week it was decided to set up a design team to work on the
{ way forward and propose it in an informational RFC - Matt Mathis has
{ kicked off a first shot <draft-mathis-iccrg-unfriendly-00.txt>. We
{ just had the launch meeting of that design team at the ICCRG here in
{ Tokyo.
{ 
{ Re-ECN is a change to IP to make congestion as transparent to the
{ network as it is to the endpoints (hence congestion exposure). Then:
{ i) causes of excessive congestion can be kept in check if ISPs choose
{ - but at the bulk packet level like the Internet architecture should
{ be - agnostic to behaviour of individual flows;
{ ii) and ISPs that under-provision can be held to account as well.
{ (see the end for the status of re-ECN).
{ 
{ Re-ECN status
{ -------------
{ We've been keeping a draft spinning on this proposed change to IP
{ since 2005. It's still an individual contribution waiting for the
right
{ time.
{ <draft-briscoe-tsvwg-re-ecn-tcp-07>
{ <draft-briscoe-tsvwg-re-ecn-tcp-motivation-00>
{ 
{ When we first presented it and had subsequent ad hoc BoFs, the idea
{ fell on stony ground. I think because back then few could see the
{ limitations of TCP-friendly. Even if you still think there's
{ something in TCP-friendly, it was apparent from the lack of any hum
{ it received in SF that we at least need something wider.
{ 
{ It seems re-ECN is one of those things people want someone else to
{ have already done. It gives a permit to be able to work on protocols
{ that are really safe and fair, but they're not strictly TCP-friendly
{ (e.g. mTCP, relentless, etc). For instance, re-ECN would allow ISPs
{ to count how little congestion LEDBAT traffic was causing, so they
{ need not count it against the user's allowance, etc.
{ 
{ We've now implemented it. There's now a great amount of security
{ analysis on trying to game it and attack it and how it defends
{ itself. People are working on using it as a basis for other DDoS
{ protection mechanisms. Another is trying to build traffic engineering
{ over it. Others are interested in deploying it using proxies. It's
{ potential impact on net neutrality etc is being analysed by
{ regulatory and economics people. So has it's time come?
{ 
{ Cheers
{ 
{ 
{ Bob
{ 
{ 
{ 
{ ________________________________________________________________
{ Bob Briscoe,               Networks Research Centre, BT Research

From: [email-masked] (Saverio Mascolo)
Date: Tue May 26 11:05:11 2009
Subject: [Iccrg] Notes from the meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

 in mills' slides Scalable TCP is still mentioned...our experience  is that
scalable tcp does not work at all. in a case as simple as 3   connections
starvation happens.
this is  important to simplify a scenario with an ever increasing number of
TCP variants ...

saverio

On Tue, May 26, 2009 at 12:13 AM, <[email-masked]> wrote:

> >> Michael Scharf talk: quick-start algorithms: discussion with bob briscoe
> >> about details of the proposed algorithm.
> >>
> >> Kevin Mills talk: in-depth evaluation of some TCP protocols. FAST
> >> behavior stands out; some discussion about the underlying model.
> >
> >
> > are slides available?
>
> these two, yes. here's what I wrote in my previous
> email, once again:
>
> >> I also uploaded the slides which I received so far to the agenda:
> >> http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09
> >> Bob, Matt, please send me yours, I'll include them too as soon
> >> as I get them.
>
> :-)
>
> cheers
> michael
>
>
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <[email-masked]>

http://c3lab.poliba.it

=================================
This message may contain confidential and/or legally privileged information.
 If you are not the intended recipient of the message, please destroy it.
Any unauthorized dissemination, distribution, or copying of the material in
this message, and any attachments to the message, is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090526/6334069c/attachment.html
>From [email-masked]  Tue May 26 18:12:08 2009
From: [email-masked] (Bob Briscoe)
Date: Tue May 26 18:13:05 2009
Subject: [Iccrg] RE: [tsv-area] Congestion Exposure (re-ECN): to BoF or to
	Bar BoF?
In-Reply-To: <[email-masked]
	d.alcatel.com>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Dimitri,

I've cc'd to the iccrg, because it's a v good question that others on 
the list might want answered.

The discussions in Tokyo concluded that the ICCRG itself is mainly 
focused on congestion control protocols and there is less of an 
appetite for traffic security, policing etc. Therefore the ICCRG is a 
natural home for new congestion controls that might arise if 
congestion exposure existed, but not the best home to do the 
congestion exposure work itself.

Traffic security expertise is a fairly rare resource in the IETF/IRTF 
and it was thought they wouldn't feel ICCRG was their natural home.

Also, the proposal is for standards track, rather than IRTF activity 
on this particular aspect. This is because the research that has 
already been done has identified a piece that can safely and 
separately be standardised without committing to any particular 
transport behaviour that might be added on top.

Bob

At 11:00 23/05/2009, PAPADIMITRIOU Dimitri wrote:
>Bob:
>
>Why did you exlcude the possibility to progress the work in the ICCRG
>context ?
>
>Did you discuss this option/alternative in the context of the ICCRG
>meeting held in Tokyo ?
>
>thanks,
>-dimitri.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bob Briscoe
> > Sent: Thursday, May 21, 2009 10:37 AM
> > To: tsv-area IETF list
> > Cc: iccrg IRTF list
> > Subject: [tsv-area] Congestion Exposure (re-ECN): to BoF or
> > to Bar BoF?
> >
> > TSV Area folks,
> >
> > [Please continue this discussion on tsvarea]
> >
> > I'd like to launch a concrete protocol-specification activity on
> > congestion exposure (with re-ECN as a candidate solution) in
> > Stockholm? Here at the ICCRG in Tokyo, we've just agreed that this
> > doesn't conflict with the new IRTF ICCRG  design team in this space
> > or prejudge any consensus on direction (see background below). The
> > question is purely about timing...
> >
> > I'm finding that re-ECN seems to feature somewhere in the plans of
> > those expressing an opinion in the ICCRG discussions. My concern: the
> > protocol that will take longest needs to be finished soonest. E.g.
> > ECN took 7 years from first research paper to proposed standard.
> >
> > Therefore, I'd like to propose we get started on a specific protocol
> > specification activity, in parallel to the ICCRG design team. We have
> > to set this up so it doesn't imply it is the *official and only* way
> > forward. But it's a good punt to be starting on.
> >
> > My questions are:
> > * Do you think discussions should start on building a BoF on
> > "Congestion Exposure" in Stockholm (getting late but still do-able)?
> > * Or less ambitiously should we arrange another ad hoc BoF (bar BoF)
> > in Stockholm, building on ICCRG work in Tokyo this week, to get a
> > community together to form a BoF later?
> > * Or do people actively oppose anyone doing anything yet on
> > congestion exposure or re-ECN in the IETF or IRTF?
> >
> > Background on TCP-unfriendly and on re-ECN
> > -------------------------------------------
> > You may be aware that, in San Francisco we had discussions in TSVArea
> > (prompted by Matt Mathis's talk) on whether to move beyond
> > TCP-friendliness as a comprehensive direction for both sharing
> > Internet capacity and future congestion controls. In the IRTF ICCRG
> > the same week it was decided to set up a design team to work on the
> > way forward and propose it in an informational RFC - Matt Mathis has
> > kicked off a first shot <draft-mathis-iccrg-unfriendly-00.txt>. We
> > just had the launch meeting of that design team at the ICCRG
> > here in Tokyo.
> >
> > Re-ECN is a change to IP to make congestion as transparent to the
> > network as it is to the endpoints (hence congestion exposure). Then:
> > i) causes of excessive congestion can be kept in check if ISPs choose
> > - but at the bulk packet level like the Internet architecture should
> > be - agnostic to behaviour of individual flows;
> > ii) and ISPs that under-provision can be held to account as well.
> > (see the end for the status of re-ECN).
> >
> > Re-ECN status
> > -------------
> > We've been keeping a draft spinning on this proposed change to IP
> > since 2005. It's still an individual contribution waiting for
> > the right time.
> > <draft-briscoe-tsvwg-re-ecn-tcp-07>
> > <draft-briscoe-tsvwg-re-ecn-tcp-motivation-00>
> >
> > When we first presented it and had subsequent ad hoc BoFs, the idea
> > fell on stony ground. I think because back then few could see the
> > limitations of TCP-friendly. Even if you still think there's
> > something in TCP-friendly, it was apparent from the lack of any hum
> > it received in SF that we at least need something wider.
> >
> > It seems re-ECN is one of those things people want someone else to
> > have already done. It gives a permit to be able to work on protocols
> > that are really safe and fair, but they're not strictly TCP-friendly
> > (e.g. mTCP, relentless, etc). For instance, re-ECN would allow ISPs
> > to count how little congestion LEDBAT traffic was causing, so they
> > need not count it against the user's allowance, etc.
> >
> > We've now implemented it. There's now a great amount of security
> > analysis on trying to game it and attack it and how it defends
> > itself. People are working on using it as a basis for other DDoS
> > protection mechanisms. Another is trying to build traffic engineering
> > over it. Others are interested in deploying it using proxies. It's
> > potential impact on net neutrality etc is being analysed by
> > regulatory and economics people. So has it's time come?
> >
> > Cheers
> >
> >
> > Bob
> >
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,               Networks Research Centre, BT Research
> >
> >

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Saverio Mascolo)
Date: Mon May 25 18:17:58 2009
Subject: [Iccrg] Notes from the meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

hi michael,

can you tell more on:

On Mon, May 25, 2009 at 2:38 PM, Michael Welzl <[email-masked]> wrote:

> Hi all,
>
> Please find the meeting notes below; apologies if I missed
> something important.
>
> I also uploaded the slides which I received so far to the agenda:
> http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09
> Bob, Matt, please send me yours, I'll include them too as soon
> as I get them.
>
> Cheers,
> Michael
>
> --------
>
>
> Matt Mathis talk: touched upon various issues; discussion about window
> scaling - apparently Windows Vista uses an 8meg buffer and larger TCP
> window scaling for everything except for the web browser. This will
> change the network and show people that AIMD doesn't work well, e.g.
> with current home modems that have large queues.

can matt say more on this?

>
> Michael Scharf talk: quick-start algorithms: discussion with bob briscoe
> about details of the proposed algorithm.
>
> Kevin Mills talk: in-depth evaluation of some TCP protocols. FAST
> behavior stands out; some discussion about the underlying model.

are slides available?

thanks,
saverio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090525/bb18dc65/attachment.html
>From [email-masked]  Mon May 25 23:13:52 2009
From: [email-masked] ([email-masked])
Date: Mon May 25 23:14:49 2009
Subject: [Iccrg] Notes from the meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

>> Michael Scharf talk: quick-start algorithms: discussion with bob briscoe
>> about details of the proposed algorithm.
>>
>> Kevin Mills talk: in-depth evaluation of some TCP protocols. FAST
>> behavior stands out; some discussion about the underlying model.
>
>
> are slides available?

these two, yes. here's what I wrote in my previous
email, once again:

>> I also uploaded the slides which I received so far to the agenda:
>> http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09
>> Bob, Matt, please send me yours, I'll include them too as soon
>> as I get them.

:-)

cheers
michael

From: [email-masked] (Michael Welzl)
Date: Mon May 25 13:39:51 2009
Subject: [Iccrg] Notes from the meeting
Message-ID: <[email-masked]>

Hi all,

Please find the meeting notes below; apologies if I missed
something important.

I also uploaded the slides which I received so far to the agenda:
http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09
Bob, Matt, please send me yours, I'll include them too as soon
as I get them.

Cheers,
Michael

--------

Meeting minutes of the ICCRG meeting in Akihabara, Tokyo, 22. 7. 2009

Participants: Michael Welzl, Michael Scharf, Bob Briscoe, Le Hieu Hanh,
Kevin Mills, Takashi Takesue, Matt Mathis, Ilpo Jarvinen, Ryousei
Takano, Michio Honda, Yoichi Inanaga, Yusuke Miyoshi, Kazuya Tsukamoto,
Kaysosli Kabayashi

Michael Welzl talk: agenda bashing - Discussion about
draft-housley-iesg-rfc3932bis stopping progress of
draft-irtf-iccrg-cc-rfcs (together with several other IRTF drafts). Bob:
A survey becomes less and less useful as time goes by. Lars: This issue
has just been discussed in an IAB meeting, things will probably move
ahead now.

Michael Welzl talk: open issues draft
( draft-irtf-iccrg-welzl-congestion-control-open-research-04
 ) - no discussion happened. Matt: this is a useful document. The
authors believe that this draft is ready for "last call", people should
(re-)read and comment.

Matt Mathis talk: touched upon various issues; discussion about window
scaling - apparently Windows Vista uses an 8meg buffer and larger TCP
window scaling for everything except for the web browser. This will
change the network and show people that AIMD doesn't work well, e.g.
with current home modems that have large queues.

Michael Scharf talk: quick-start algorithms: discussion with bob briscoe
about details of the proposed algorithm.

Kevin Mills talk: in-depth evaluation of some TCP protocols. FAST
behavior stands out; some discussion about the underlying model.

"Beyond TCP-friendliness" design team discussion. Bob introduced the
plan with slides. Discussion: realistic ways to get this deployed,
relationship to / service provided by re-ecn, ...

This design team is not the same as, but connected to, Bob's Re-ECN IETF
effort called congestion exposure ("congestion transparency"). It is the
goal of re-ecn to expose congestion.

The ICCRG design team:
* should discuss issues around weighting of congestion controls and
provide
  a direction for the ietf regarding different views on resource sharing
* is connected to congestion exposure as one use case. Michael Welzl:
implementing
  something like Re-ECN on the end system only could be a second use
case (more tangible,
  because it doesn't require ISP involvement). Agreement.

Michael Scharf: how does congestion charging relate to volume
charging? answered by Bob with slides.

Michael Scharf also mentioned two use cases that are related to
congestion
exposure and that are maybe interesting use cases beyond congestion
control, even though he is not sure whether it is possible to come up
with a simple solution, and whether they are indeed within the scope
of the design team:
- From the user perspective: Detecting capacity overbooking by ISPs
  (Bob: Re-ECN could help here)
- From a business customer perspective: SLA verification and performance
  problems root cause analysis (e. g., if application performance is
poor,
  is this due to congestion on the path, and if so, on which part
  on the path?)

The design team will use the main ICCRG list. its charter should be
discussed in
the list. it should have a simple web page, maintained by Bob and Matt,
which has the charter and some key information / documents about the
team.

---

This meeting was supported by the JSPS 163rd committee on Internet
Technology (ITRC). 

From: [email-masked] (Bob Briscoe)
Date: Thu May 21 09:38:55 2009
Subject: [Iccrg] Congestion Exposure (re-ECN): to BoF or to Bar BoF?
Message-ID: <[email-masked]>

TSV Area folks,

[Please continue this discussion on tsvarea]

I'd like to launch a concrete protocol-specification activity on 
congestion exposure (with re-ECN as a candidate solution) in 
Stockholm? Here at the ICCRG in Tokyo, we've just agreed that this 
doesn't conflict with the new IRTF ICCRG  design team in this space 
or prejudge any consensus on direction (see background below). The 
question is purely about timing...

I'm finding that re-ECN seems to feature somewhere in the plans of 
those expressing an opinion in the ICCRG discussions. My concern: the 
protocol that will take longest needs to be finished soonest. E.g. 
ECN took 7 years from first research paper to proposed standard.

Therefore, I'd like to propose we get started on a specific protocol 
specification activity, in parallel to the ICCRG design team. We have 
to set this up so it doesn't imply it is the *official and only* way 
forward. But it's a good punt to be starting on.

My questions are:
* Do you think discussions should start on building a BoF on 
"Congestion Exposure" in Stockholm (getting late but still do-able)?
* Or less ambitiously should we arrange another ad hoc BoF (bar BoF) 
in Stockholm, building on ICCRG work in Tokyo this week, to get a 
community together to form a BoF later?
* Or do people actively oppose anyone doing anything yet on 
congestion exposure or re-ECN in the IETF or IRTF?

Background on TCP-unfriendly and on re-ECN
-------------------------------------------
You may be aware that, in San Francisco we had discussions in TSVArea 
(prompted by Matt Mathis's talk) on whether to move beyond 
TCP-friendliness as a comprehensive direction for both sharing 
Internet capacity and future congestion controls. In the IRTF ICCRG 
the same week it was decided to set up a design team to work on the 
way forward and propose it in an informational RFC - Matt Mathis has 
kicked off a first shot <draft-mathis-iccrg-unfriendly-00.txt>. We 
just had the launch meeting of that design team at the ICCRG here in Tokyo.

Re-ECN is a change to IP to make congestion as transparent to the 
network as it is to the endpoints (hence congestion exposure). Then:
i) causes of excessive congestion can be kept in check if ISPs choose 
- but at the bulk packet level like the Internet architecture should 
be - agnostic to behaviour of individual flows;
ii) and ISPs that under-provision can be held to account as well.
(see the end for the status of re-ECN).

Re-ECN status
-------------
We've been keeping a draft spinning on this proposed change to IP 
since 2005. It's still an individual contribution waiting for the right time.
<draft-briscoe-tsvwg-re-ecn-tcp-07>
<draft-briscoe-tsvwg-re-ecn-tcp-motivation-00>

When we first presented it and had subsequent ad hoc BoFs, the idea 
fell on stony ground. I think because back then few could see the 
limitations of TCP-friendly. Even if you still think there's 
something in TCP-friendly, it was apparent from the lack of any hum 
it received in SF that we at least need something wider.

It seems re-ECN is one of those things people want someone else to 
have already done. It gives a permit to be able to work on protocols 
that are really safe and fair, but they're not strictly TCP-friendly 
(e.g. mTCP, relentless, etc). For instance, re-ECN would allow ISPs 
to count how little congestion LEDBAT traffic was causing, so they 
need not count it against the user's allowance, etc.

We've now implemented it. There's now a great amount of security 
analysis on trying to game it and attack it and how it defends 
itself. People are working on using it as a basis for other DDoS 
protection mechanisms. Another is trying to build traffic engineering 
over it. Others are interested in deploying it using proxies. It's 
potential impact on net neutrality etc is being analysed by 
regulatory and economics people. So has it's time come?

Cheers

Bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  

From: [email-masked] (=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=)
Date: Thu May 14 06:35:23 2009
Subject: [Iccrg] Tokyo ICCRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 14 May 2009, Katsushi Kobayashi wrote:

> I am arranging the ICCRG meeting in Tokyo.
> 
> Though anybody having interest in ICCRG is welcome,
> we would like to count the number of participants due to
> the arrangements.
> 
> If you would like to join the ICCRG meeting, please send e-mail to
> 
> [email-masked].

I'll be participating in the iccrg meeting (I did already earlier inform 
Michael about my participation).

-- 
 i.

From: [email-masked] (Katsushi Kobayashi)
Date: Thu May 14 06:13:49 2009
Subject: [Iccrg] Tokyo ICCRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I am arranging the ICCRG meeting in Tokyo.

Though anybody having interest in ICCRG is welcome,
we would like to count the number of participants due to
the arrangements.

If you would like to join the ICCRG meeting, please send e-mail to

[email-masked].

Note that people registered PFLDNeT workshop held after ICCRG are
not required the notification. You are already counted as attendee.

Thanks,
----
Katsushi Kobayashi

On 2009/05/08, at 21:00, Michael Welzl wrote:

> Dear all,
>
> I just made a minor update to the agenda of the upcoming ICCRG
> meeting in Tokyo:
> http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09?version=3
>
> as you can see, there is still room - so if you have something
> to present, let me know until next Monday. After that, I will
> finalize it.
>
> Cheers,
> Michael
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Matt Mathis)
Date: Wed May 13 03:04:30 2009
Subject: [Iccrg] Tokyo ICCRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Oops, the last URL send out had ?version=3 on the end of it, which gives a 
different agenda...

Well I was hoping for 30 minutes, but 15 will do.  I don't think it is my role 
to juggle other presentations.  Some of it really does flow from your draft 
(which may not mean that it will flow from your presentation).   I guess I 
would prefer to be before some sort of break.

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 Tue, 12 May 2009, [email-masked] wrote:

>> Can I have the 11:15 slot to talk about the big picture?
>> For the moment I would like to go with the rather stodgy title "What is
>> the
>> real problem, and how many dimensions is the solution space?".
>>
>> It will be structured as a follow on to your open research draft and
>> include
>> a discussion of updating draft-mathis-iccrg-unfriendly-00.txt along the
>> way.
>
> That's very welcome, but there's no 11:15 slot anymore - see
> the updated agenda at
> http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09
> and tell me what exactly you'd suggest to shift where, and
> how long your talk should be.
>
>
>> BTW I am quite humbled by your open research draft.  I have been working
>> with
>> blinders on, and have overlooked many cool papers.  It is an awesome
>> summary
>> of the state of the art.
>
> Good to hear that! - but let me say out loud that
> I don't deserve the credit. My contribution has declined,
> and declined, and declined, and now I am thankful to
> still be onboard, yet ashamed by the draft carrying my
> name in its document title.
>
> Cheers,
> Michael
>
>

From: [email-masked] (Matt Mathis)
Date: Tue May 12 22:33:26 2009
Subject: [Iccrg] Tokyo ICCRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Can I have the 11:15 slot to talk about the big picture?

For the moment I would like to go with the rather stodgy title "What is the 
real problem, and how many dimensions is the solution space?".

It will be structured as a follow on to your open research draft and include 
a discussion of updating draft-mathis-iccrg-unfriendly-00.txt along the way.

BTW I am quite humbled by your open research draft.  I have been working with 
blinders on, and have overlooked many cool papers.  It is an awesome summary 
of the state of the art.

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 Fri, 8 May 2009, Michael Welzl wrote:

> Dear all,
>
> I just made a minor update to the agenda of the upcoming ICCRG
> meeting in Tokyo:
> http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09?version=3
>
> as you can see, there is still room - so if you have something
> to present, let me know until next Monday. After that, I will
> finalize it.
>
> Cheers,
> Michael
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Michael Welzl)
Date: Fri May  8 13:07:36 2009
Subject: [Iccrg] Tokyo ICCRG meeting
Message-ID: <[email-masked]>

Dear all,

I just made a minor update to the agenda of the upcoming ICCRG
meeting in Tokyo:
http://trac.tools.ietf.org/group/irtf/trac/wiki/AgendaMay09?version=3

as you can see, there is still room - so if you have something
to present, let me know until next Monday. After that, I will
finalize it.

Cheers,
Michael

From: [email-masked] (Lawrence Stewart)
Date: Mon May  4 20:25:30 2009
Subject: [Iccrg] TCP analysis, research and debugging tools: SIFTR v1.2.1 released
Message-ID: <[email-masked]>

Hi All,

I'm very pleased to announce the release of a significantly improved
version of our SIFTR (Statistical Information For TCP Research) tool
for FreeBSD. It can be obtained from [1], along with other papers,
patches and software useful for protocol analysis, debugging and
experimental research.

SIFTR is a loadable kernel module supporting FreeBSD 6.2+ that logs a
range of statistics on active TCP connections to a log file. It provides
the ability to make highly granular, event-driven measurements of TCP
connection state. More details are available in the readme and changelog
available at [1].

Work on SIFTR v1.2.0 and v1.2.1 has been sponsored by the FreeBSD
Foundation [2] as part of the "Enhancing the FreeBSD TCP Implementation"
project [3]. SIFTR development prior to v1.2.0 was supported in part by
a grant from the Cisco University Research Program Fund at Community
Foundation Silicon Valley.

SIFTR's functionality will be merged into the FreeBSD base system in one
of the next steps in this project, and will hopefully ship with FreeBSD 8.0.

Cheers,
Lawrence

http://caia.swin.edu.au

[1] http://caia.swin.edu.au/urp/newtcp/tools.html

[2] http://www.freebsdfoundation.org/

[3] http://caia.swin.edu.au/freebsd/etcp09/