Subject: [conex] giving up as editor of use draft-ietf-conex-concepts-uses

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 4 Apr 2011 17:43:19 +0100

All,

During Thursday's meeting, Marcelo made it pretty clear that he felt no
progress was being made on the concepts and use cases document. I am the
main editor of the document and have had the pen for most of the past 4
months. This means that the problems with the document must be a failure on
my part. 

I am keen that ConEx should progress smoothly through the IETF and that
requires the working group chairs to be confident in the editor. I also know
that I haven't been able to contribute as much time and energy as I might
have hoped. With that in mind I am resigning as editor of the document.
Hopefully Marcelo and Nandita will be able to find a replacement they have
more confidence in and who is able to make better progress with this
surprisingly difficult document.

I would still like to contribute as an author and WG member and I wish any
successor as editor good luck in what is a largely thankless task,

Yours,

Toby Moncaster

---

From: ken carlberg <[email-masked]>
Date: Tue, 5 Apr 2011 05:05:11 -0400

Toby,

Confidence in this arena is a two way street -- the confidence in the editors as well as the confidence in the chairs.  Waiting until the end of a meeting to express significant concerns about a draft certainly grabs the attention of the authors and the rest of the working group.  However, the lack of a detailed explanation of these concerns (ie, what is exactly broken, and why) is equally frustrating to come across.  Given such a general sweeping statement, time should have been allotted by the chairs to provide more specific insight of these concerns to the group.

If a new lead editor is chosen, I would hope we would see a more detailed discussion of the perceived problems on this list, and relatively soon.

-ken

On Apr 4, 2011, at 12:43 PM, Toby Moncaster wrote:

> All,
>  
> During Thursday’s meeting, Marcelo made it pretty clear that he felt no progress was being made on the concepts and use cases document. I am the main editor of the document and have had the pen for most of the past 4 months. This means that the problems with the document must be a failure on my part.
>  
> I am keen that ConEx should progress smoothly through the IETF and that requires the working group chairs to be confident in the editor. I also know that I haven’t been able to contribute as much time and energy as I might have hoped. With that in mind I am resigning as editor of the document. Hopefully Marcelo and Nandita will be able to find a replacement they have more confidence in and who is able to make better progress with this surprisingly difficult document.
>                                                                                                                                                                                  
> I would still like to contribute as an author and WG member and I wish any successor as editor good luck in what is a largely thankless task,
>  
> Yours,
>  
> Toby Moncaster
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 5 Apr 2011 12:37:36 +0200

Hi all
 
I have just submitted the following Conex related draft entitled 
"Calculating Exposed Congestion by using TCP Throughput Changes", see below:
 
http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation-00.txt

This document describes a possible implementation complexity problem 
associated with the current Conex concept defined by the ConEx WG 
and it proposes a solution to this. This problem occurs due 
to the fact that it is complex to measure the congestion rate 
at the sender side.
 
The solution proposed in  draft-briscoe-tsvwg-re-ecn-tcp-09 to calculate 
the exposed congestion rate at the sender seems to be quite complex 
to be implemented, since protocol changes need to be accomplished in 
order to modify the semantics of the TCP header, i.e., the semantics of the
flags:
NS, CWR and ECE.
 
This document provides a solution to this problem as follows.
When the sender needs to reduce its sending rate, then the sender can 
calculate the exposed congestion rate by subtracting the TCP 
throughput calculated during a a Round Trip Time (RTT), i.e., (RTTi) 
from the TCP throughput calculated at the same sender side during the 
previous RTT, i.e., (RTTi-1), where i is an integer equal or higher 
than 1.
The TCP throughput at the sender side can be calculated using, e.g., 
the TCP throughput equation specified in [RFC5348].
 
Comments are welcome!
 
Best regards,
Georgios

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 06 Apr 2011 16:45:48 +0100

Toby,

I'd like to publicly thank you for your contribution and I'm glad to 
see that you are still open to contributing in future. This is an 
unfortunate situation we have got into.

The problem we have here is far from simple. Not least, there are 
different misconceptions that different readers hold with great 
conviction, which we somehow have to negate before we actually get to 
what we want to say.

Thank you again.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design