Subject: Area Merging: A Transport Perspective

From: "Black, David" <[email-masked]>
Date: Sun, 28 Dec 2014 01:31:07 +0000

As noted earlier, I'm strongly supportive of the creative out-of-the-box
thinking that's lead to this area merge proposal:

>> III.  MERGING OF UPPER LAYER PROTOCOL AREAS
>>
>> As previously noted [1], a significant amount of the work that is going on in
>> the APP area pertains to the web protocols, but that has a good deal of
>> crossover with work in RAI. There is also some crossover work between the APP
>> and TSV areas. To accommodate these overlaps and provide better WG management
>> across these three areas, the IESG is proposing to merge the APP, RAI, and TSV
>> areas into one combined Network Applications (NAPP) area. From March
>> 2015-March 2016, this combined area would be overseen by the five remaining
>> ADs from APP, RAI, and TSV, with some redistribution of WG shepherding
>> responsibilities among them to balance workloads. DISPATCH, TSVWG, and APPSAWG
>> would continue to function much as they currently do.

However, after some more thought, I find myself sharing Brian Carpenter's
concerns (from the main IETF list) about whether TSV should be part of this):

http://www.ietf.org/mail-archive/web/ietf/current/msg91031.html

> However, the merge with Transport is technically strange. Agreed, there
> are four or five WGs in Transport that could equally well be in Apps, and
> there are some in RAI that could equally well be in Transport. But beyond
> that, I just don't see the synergy. (Where we need synergy, we know how
> to create it, e.g. the DART WG.) Wouldn't it be better to rebalance by
> moving a few groups from RAI to Transport, and the solve the RAI/Apps
> problem on its own? (Since I assume that everything is on the table,
> there are 2 or 3 Apps WGs that could move to Security, for example.)

To a first approximation, the core transport protocol work (TCP, SCTP,
congestion control, DiffServ, etc.) constitutes about half of an area's
worth of WGs (8-10), leaving about half a dozen WGs that are in TSV for
other reasons, e.g., history, convenience.  I happen to be a chair of one
TSV WG in each category (tsvwg does core transport protocol work, storm
is in TSV for other reasons).

IMHO, the IETF absolutely needs an AD with technical depth and focus on
the core transport work, but that's only about one AD's worth of WGs,
whereas the minimum IETF area size is now apparently two AD's worth.

OTOH, I'm not at all sure that lumping TSV into a new super-area is
a good way to retain the important focus on core Transport topics - if
anything, given the ongoing difficulty in finding Transport ADs, it
invites a future situation in which the IESG has no Transport expert.

As an alternative, suppose:

	- APP and RAI were merged into a 3-AD area.
	- The non-core TSV WGs were considered/included in the grand
		reshuffling of WGs that will result (could include WG
		moves both into and out of TSV).

Then, to the extent that the resulting TSV Area is smaller than other
areas, the TSV ADs could set a good example that an AD position doesn't
have to be a full-time job, or close to it (hint) and/or help out w/select
WGs in other areas (e.g., split time between APP/RAI and TSV).

It might be a good idea to see how the two-way area merge works out (e.g.,
what the AD slot descriptions look like for the NomCom) before making more
changes.
 
Thanks,
--David

---

From: [email-masked]
Date: Mon, 29 Dec 2014 09:07:01 -0000

As David's Co-Chair in TSV WG, I agree with most of what has been said
about transport work by Brian and David.

At one time the role of transport may have been largely about using
existing transports, that's not the case right now. There's quite a bit of
work on new transport protocol mechanisms now in progress, and the level
of new work does not look like reducing in the near future. While some of
the TSV work could move elsewhere (if expertise is greater), I can't see a
general amalgamating this with upper layer work would help.

Gorry

---

From: Aaron Falk <[email-masked]>
Date: Mon, 29 Dec 2014 16:10:43 -0500

I'm also a bit concerned about broadening TSV into too many more
directions.  I'd like to see any structural changes (minimally to the
Transport Area) as organizational experiments with an explicit expiration
date where we take stock of their effectiveness.

As (I think) Kathleen suggested, there's a lot to be said for Directorates
as a mechanism identifying cross-disciplinary communities who share
concerns.  Maybe we should be using directorate grouping for some of the
items on Jari's list of how areas are used, e.g., conflict avoidance?

--aaron

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 29 Dec 2014 15:48:20 -0600

Hi, Aaron,

> items on Jari's list of how areas are used, e.g., conflict avoidance?

Some of the ADs put together a matrix of what they regrettably called
"clusters", showing how various working groups clumped together. I wasn't
one of those ADs, but agreed with their characterization of any of the
working groups I might reasonably have opinions about.

FWIW, most of the WGs in most of the clusters are in the same area today,
but not all are - probably 20 percent of the clusters had working groups
from two areas.

At a macro level, there were considerably more clusters than areas today -
in various versions of the matrix, TSV had two or three clusters, which you
can roughly guess the members of.

There were considerably more clusters than directorates today, too.

But I wonder if directorates + clusters might be the beginning of something
helpful, if fully implemented.

Spencer

>> >>> As previously noted [1], a significant amount of the work that is
>> going
>> >>> on in

---

From: Melinda Shore <[email-masked]>
Date: Mon, 29 Dec 2014 12:53:48 -0900

On 12/29/14 12:48 PM, Spencer Dawkins at IETF wrote:
> At a macro level, there were considerably more clusters than areas today
> - in various versions of the matrix, TSV had two or three clusters,
> which you can roughly guess the members of. 

So many clustering algorithms, so little time ...

Melinda

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Dec 2014 18:22:22 -0500

Black, David <[email-masked]> wrote:
    > other reasons, e.g., history, convenience.  I happen to be a chair of
    > one TSV WG in each category (tsvwg does core transport protocol work,
    > storm is in TSV for other reasons).

I am curious, in the context of the "SEMI" work to what extend Transport is
*really* still that seperate from APP and RAI.  My observation is that I
think we are doing various kinds of congestion control in HTTP (hybi is APP
area...).

That there is still no clear way for my end user application to speak to my
ISPs' QoS infrastructure to prioritize the traffic I care about (and
de-prioritize the DDoS), seems like a major tragedy of the commons: is it
APP, INT, TSV or SEC that should solve this problem?  (15 years ago, I had
high hopes that DiffEdge would go somewhere...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Black, David" <[email-masked]>
Date: Tue, 30 Dec 2014 04:54:50 +0000

> think we are doing various kinds of congestion control in HTTP (hybi is APP

SEMI does not encompass everything going on in Transport.  By analogy, just
for grins, uta is a strongly security-focused WG in the APP area - surely we
should not be thinking about adding SEC to the new proposed mega-area :-).

Anyhow, see draft-ietf-mpls-in-udp, a RTG area draft that contains significant
Transport content on both congestion control and UDP zero checksum usage for
IPv6.  This is an example of Transport concerns that show up in the middle
of networks, away from endpoints that support APP and RAI technologies.

There are other examples, e.g., the aqm WG.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: Monday, December 29, 2014 6:22 PM
> To: Black, David
> Cc: [email-masked]; Jari Arkko
> Subject: Re: Area Merging: A Transport Perspective
> 
>