Subject: Re: FYI draft text desired expertise TSV AD (NOMCOM 2015 cycle)

From: Martin Stiemerling <[email-masked]>
Date: Tue, 02 Jun 2015 07:44:25 +0200

Hi Joe,

Am 29.05.15 um 20:11 schrieb Joe Touch:
> Hi, all,
>
> I don't disagree with anything in the text, but it seems to omit a few
> key areas that I think are also aspects of transports besides
> flow/congestion control-ish. These might also be listed among the
> topics/examples:
>
> 	- segmentation, MTU, and message boundary issues
> 	- connection state management
> 	- deep-packet inspection interactions
> 	- interactions with timing and latency
> 	- end-to-end error detection and correction

I fully agree that the set of service TSV ADs must know about this, but 
I wonder if this level of detail is needed in the desired expertise 
description for the NOMCOM.

The current text aims at keeping the balance between naming a number of 
must haves, but is deliberately not going into more details.

Is there a good term that would cover most of the points, i.e., the text 
says core transport topics, but indeed lacks an item that covers the 
transport 101 points, like MTU issues.

Thanks,

   Martin

>
> Joe
>
> On 5/29/2015 1:09 AM, Eggert, Lars wrote:
>> Looks spot on
>>
>> On 2015-5-29, at 07:42, Martin Stiemerling <[email-masked]> wrote:
>>>
>>>
>>> Dear all,
>>>
>>> Spencer and I have finished editing the draft text for the desired expertise for the TSV AD in the NOMCOM 2015 cycle.
>>>
>>> This is currently under discussion in the IESG and not yet the final text which will be sent to the NOMCOM
>>>
>>> It is available here:
>>> https://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise
>>>
>>> Let Spencer and me know your comments about this until June 3rd, 2015, 8pm CEST.
>>>
>>>
>>> Thanks,
>>>
>>>   Spencer and Martin
>>>
>>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 02 Jun 2015 07:50:23 +0200

Hi David,

Am 31.05.15 um 01:09 schrieb Black, David:
> DiffServ is definitely still relevant, as there's current DiffServ-related work.
> Suggested rephrasing:
>
>     QoS (including Differentiated Services and reservation signaling), and
>     congestion control for unresponsive flows.

Thanks for the suggestion and fixed in the wiki. Plus expanded QoS to 
Quality of Service.

   Martin

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 10:14:13 -0700

Hi, Martin,

> transport 101 points, like MTU issues.

I really wish there were. My point is that "transport" is more than
"congestion and flow control".

To say the above in a more generic format:

	- connection state coordination
	- interaction with path properties
	- interaction of with router data plane
	- error detection and recovery
	- data boundary coordination

The current list states the same concept too many different ways and can
be condensed:

WAS:
	- congestion, control loops and hysteresis,
	flow control, queuing and latency
MAYBE:
	- congestion and flow control

WAS:
	- transport connection and reliability issues
IMO SHOULD BE:
	- connection state coordination
	- error detection and recovery

WAS:
	- interactions with the network layer,
	the application layer, and middleboxes.
(IMO OK)

The full list, IMO, should be (in no particular order):

	- connection state coordination
	- interaction with path properties
	- interaction of with router data plane
	- error detection and recovery
	- data boundary coordination
	- congestion and flow control
	- interactions with the network layer,
	the application layer, and middleboxes

IMO that should appear in one paragraph, not split across two paragraphs
that are not adjacent.

Finally, the last paragraph should compress down the congestion/flow
control issues to one item (not 4) and should also specifically list MTU
interactions and ICMP interactions.

Joe

---

From: John Leslie <[email-masked]>
Date: Tue, 2 Jun 2015 16:48:27 -0400

> "congestion and flow control".

   Most assuredly it does.

> 	- data boundary coordination

   This describes (in general terms) what TSV WGs do (and does so pretty
well). My point (beyond making the NomCom's job possible) is that no
TSV _participant_ needs to know all these things: even the things s/he
does need to know can generally be learned while participating in the WG.

   Surely an AD doesn't need to know _everything_...

> The current list states the same concept too many different ways and can

   I don't agree that such condensation will help the NomCom.

   (Indeed, the NomCom "need-to-know" list doesn't cover how to evaluate
expertise in all topics -- it's more like "who to ask"...

> 	- congestion and flow control

   IMHO, bad idea to condense these. "congestion" by itself is too broad
a topic -- what is it about congestion we're asking ADs to know? (I've
been alarmed to find how little the average IETF participant understands
about hyteresis.)

   Likewise, "queuing and latency" are moving targets which it seems
helpful to have ADs try to follow. I wouldn't ask for _much_ expertise
there; but these are topics where outdated information may be less than
helpful...

> 	- error detection and recovery

   This may be an improvement. We generally think in terms of state
transitions at the two ends of a connection -- though I'm not certain
that _all_ transports must work that way...

   The details of error detection can overwhelm _any_ of us. I really
don't know what level of knowledge of error detection is reasonable
to expect of ADs.

> 	the application layer, and middleboxes.

   (I'd rather let sleeping dogs lie...)

> 	  the application layer, and middleboxes

   I truly worry that expecting all that will be too severe a limit
on available candidates. Remember that ADs aren't expected to do the
work: they're expected to manage the WGCs and coordinate discussion
of issues that arise during IETF-wide LastCall. They will have access
to expertise in the Area Directorate -- they need to know what questions
to ask; not the answers to all those questions.

   (And conversely, I'm not convinced that a NomCom reading that list
would actually ask candidates about, e.g., hysteresis or latency.)

> IMO that should appear in one paragraph, not split across two paragraphs

   No strong opinion there: NomComs have proven very skilled at reading
these job descriptions carefully.

> interactions and ICMP interactions.

   Sounds like we're going to disagree there.

   I see nothing wrong with four items within "congestion/flow-control".
But I'm ready to agree that "MTU interactions" is probably worth adding.
I honestly don't know whether it's good to expect expertise in "ICMP
interactions". That is a moving target: granted, we've ignored it more
often than we should; but I believe implementers react to these problems
during testing -- thus I wouldn't require ADs to field such issues.

   Perhaps I'm more sensitive than I need to be about limiting the field
of candidates. But I've watched NomComs struggle for too long to quietly
agree to increasing the requiriments for Transport ADs. And I've watched
the chaos which ensues when they fail to find a nominee to recommend.

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 13:53:35 -0700

On 6/2/2015 1:48 PM, John Leslie wrote:
...
> on available candidates. 

We should list the set of things we expect expertise in AND clearly
indicate that we're looking for good overlap but not necessarily
complete coverage.

And "familiarity with" is enough; "deep knowledge" isn't needed per se.

...
> during testing -- thus I wouldn't require ADs to field such issues.

I could say the same thing about congestion control, and IMO it'd be
equally absurd ;-)

> the chaos which ensues when they fail to find a nominee to recommend.

I think that can be addressed as noted above. The list isn't the issue;
it's the expectation of how much and how deeply it is known.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Jun 2015 16:34:50 -0700

Some thoughts.

When i was in Nomcom i found these area specific writeups frustrating,
because they where mixing a mayority of common requirements for ADs
with area specific expertise.

What i'd like to see:

a) a cross-area writeup for AD requirements in te NomCom area.

b) In every area wiki a decription of the technical responsibilities
   and interactions of the area - with mapping to WGs as much as
   possible. Aka: an expanded version of what is right now the TSV
   specific part of the AD expertise requirements.

With b) in the area wiki the writeup helps a lot more folks: every IETF
participant trying to understand the area, folks pondering if they should
participate in directorate, nomcom, what have you.

Cheers
   Toerlesss

On Fri, May 29, 2015 at 07:42:52AM +0200, Martin Stiemerling wrote:
> Dear all,
> 
> Spencer and I have finished editing the draft text for the desired 
> expertise for the TSV AD in the NOMCOM 2015 cycle.
> 

-- 
---
Toerless Eckert, [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 17:54:19 -0700

On 6/2/2015 4:34 PM, Toerless Eckert wrote:
...
> participate in directorate, nomcom, what have you.

"pondering"?

You do realize, I presume, that the largest factor in determining who is
available as a *candidate* for AD is financial support by their employer?

I.e., you've already winnowed the pool down to 1% just from that.
Everything else (i.e., a description of the area or expertise expected
therein) is noise, IMO.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Jun 2015 21:46:16 -0700

> available as a *candidate* for AD is financial support by their employer?

I think the biggest limiting factors for available candidates are 
willingness to do the job and self-assessment of winning chances:
If all IETF participants with employer support would run, we would have
a lot more candidates.

I do think missing employer is holding back some *qualified* candidates,
but i am not sure how many of them would really be available if money
was no matter.

> Everything else (i.e., a description of the area or expertise expected

I am sure the upcoming NomCom will be happy when you explain to them
how they can have a good time ignoring their job assignment and just
draw straws at the end.

Toerless

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 3 Jun 2015 07:39:29 +0000

> but i am not sure how many of them would really be available if money

A lot more, esp. in transport. Pretty much all academic people are excluded because of the time commitment and the need to fund that time commitment. Plus, no brownie points that help with tenure for junior faculty from IETF involvement, at least in the US.

Lars

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 3 Jun 2015 07:29:30 -0700

> A lot more, esp. in transport. Pretty much all academic people are excluded because of the time commitment and the need to fund that time commitment. Plus, no brownie points that help with tenure f…

Right,

I think in transport there are just relatively more qualified academics
because there are fewer qualified industry people - because most
industry careers would be more centered closer to app/realtime or network
layer.

The brownie point problem was what i had in mind when i said "really be
available".

Given where we stand, i'd start with trying to figure out how to
make the role of technical reviewer (eg: in directorate) more attractive
to academics though.

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2015 10:04:05 -0700

...
> how they can have a good time ignoring their job assignment and just

The NomCom does its best to pick from among the available candidates.

Until they can conclude "no candidate qualifies", their decisions will
always include noise that renders much of their careful deliberation
irrelevant.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 3 Jun 2015 10:13:56 -0700

> always include noise that renders much of their careful deliberation

Was that your feeling when being NomCom and looking at the NomCom
decisions from the outside ?

My NomCom experience was not one of noice rendering decisions irrelevant.

I think in the opposite, NomCom members try to assess which input they
consider to be noise and can therefore ignore.

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2015 10:18:16 -0700

> decisions from the outside ?

It's the feeling I get from seeing the NomCom decisions, certainly.

> consider to be noise and can therefore ignore. 

Again, NomCom can try to reduce *its* noise to zero, but that doesn't
mean they're not picking "the best of the best of a set picked by
another very noisy, random process".

I.e., carefully tuning your radio to 101.3 FM based on a very precise
consideration of the desired frequency won't help unless there's a
station there. It's very easy to precisely tune to white noise.

Joe