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

From: Martin Stiemerling <[email-masked]>
Date: Fri, 29 May 2015 07:42:52 +0200

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: "Eggert, Lars" <[email-masked]>
Date: Fri, 29 May 2015 08:09:11 +0000

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:
> Let Spencer and me know your comments about this until June 3rd, 2015, 8pm CEST.
> 
> 
> Thanks,
> 
>  Spencer and Martin
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2015 11:11:16 -0700

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

Joe

---

From: John Leslie <[email-masked]>
Date: Fri, 29 May 2015 16:38:58 -0400

> 	- end-to-end error detection and correction

   All of these are "nice to have" -- understanding of MTU is especially
nice-to-have.

   But none of them are critical to a TSV AD doing his/her job.

   IMHO, of course.

   YMMV...

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2015 13:42:19 -0700

IMO, these are as critical to many transport discussions as knowledge of
congestion control.

Joe

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 29 May 2015 21:06:18 +0000

Today's network is layers of layers of overlay (multiple layers of encapsulation). A communication between two end points traverses multiple administrative domains.  

The TSV-Area AD should have the knowledge of BGP, the domain demarcation across different administrative domains.  

Linda
-----Original Message-----
From: tsv-area [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Friday, May 29, 2015 3:42 PM
To: John Leslie
Cc: [email-masked]
Subject: Re: FYI draft text desired expertise TSV AD (NOMCOM 2015 cycle)

IMO, these are as critical to many transport discussions as knowledge of congestion control.

Joe

On 5/29/2015 1:38 PM, John Leslie wrote:
>> 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 
>    All of these are "nice to have" -- understanding of MTU is 
> especially nice-to-have.
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2015 14:13:09 -0700

Linda,

On 5/29/2015 2:06 PM, Linda Dunbar wrote:
> Today's network is layers of layers of overlay (multiple layers of encapsulation).

It always has been - the encapsulation layers and number of layers have
changed, but it's not clear how that affects transport except via MTU
interactions.

> A communication between two end points traverses multiple
administrative domains.

Yes, but transport protocols don't interact with AD properties per se.

> The TSV-Area AD should have the knowledge of BGP, the domain demarcation across different administrative domains.  

Can you give an example of a case where this has been useful?

Joe

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 29 May 2015 21:44:06 +0000

See inline below:

-----Original Message-----

administrative domains.

[Linda] Some congestion work done or proposed in TSV area assumed nodes in the network actually "see" the data flows between end points and do something about it. But the reality is that most nodes in the core only see the aggregated traffic,  don't have visibility of the end point traffic.

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2015 14:51:02 -0700

On 5/29/2015 2:44 PM, Linda Dunbar wrote:
> [Linda] Some congestion work done or proposed in TSV area assumed
> nodes in the network actually "see" the data flows between end points
> and do something about it. But the reality is that most nodes in the
> core only see the aggregated traffic, don't have visibility of the end
> point traffic.

Agreed, but I'm not knowledge of BGP is needed to appreciate this.

Joe

---

From: John Leslie <[email-masked]>
Date: Fri, 29 May 2015 19:39:03 -0400

Linda Dunbar <[email-masked]> wrote:
> 
> Today's network is layers of layers of overlay (multiple layers of
> encapsulation). A communication between two end points traverses
> multiple administrative domains.  

   Quite true.

> The TSV-Area AD should have the knowledge of BGP, the domain
> demarcation across different administrative domains.  

   It's hard enough to find Routing ADs that understand BGP. To repeat
myself and others: We must make it possible for the NomCom to do its
job.

   TSV ADs should know how to talk to routing experts; but I see no
reason for them to be BGP experts themselves.

   Indeed, even if we consider what happens to packets as they cross
Administrative Domains to be in-scope for Transport documents (alas,
sometimes it is), that doesn't mean TSV ADs need to understand the
details of that issue.

   Also, please note that our TSV ADs are seriously trying to organize
the work so that they don't need to review all documents themselves.

---

From: [email-masked]
Date: Sat, 30 May 2015 10:35:39 +0100

I agree, to me BGP isn't a protocol that needs to be understood by a  TSV
AD. Like many protocols from other areas, it is one where we need to be
aware of issues so that other groups can determine whether something needs
to be done.

Gorry

---

From: "Black, David" <[email-masked]>
Date: Sat, 30 May 2015 22:55:01 +0000

And to Linda's original point, which was about "multiple administrative domains",
an appreciation of the Autonomous System (AS) structure of the Internet would
certainly be helpful in working with both Routing and Operations folks, but that
in no way requires serious knowledge of how BGP works.

Thanks,
--David

> From: tsv-area [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, May 30, 2015 5:36 AM
> To: John Leslie
> Cc: [email-masked]

---

From: "Black, David" <[email-masked]>
Date: Sat, 30 May 2015 23:09:18 +0000

>> 	- segmentation, MTU, and message boundary issues

MTU issues come up on a regular basis, especially discovery and what to do
about a discovered MTU that's smaller than ideal, and at least MTU discovery
is currently viewed as a Transport Area responsibility.  At least one of the
two Transport ADs should have a solid command of MTU discovery, as that's
needed every so often to keep others honest.

Also, I noticed this buried in the description of managing Transport Area
work:

   QoS and reservation signaling, DiffServ? and congestion control for
   unresponsive flows,

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,
--David

> Sent: Friday, May 29, 2015 4:42 PM
> To: John Leslie
> Cc: [email-masked]

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 30 May 2015 20:21:56 -0700

top posting: 

1/ I agree with John that we need to make it possible for nomcom to find technically qualified transport candidate

2/ I must also agree with Linda regarding how complex today’s network system has become, which raised the expertise requirement bar — would the picture getting even worse over next few years, or are we doing anything to get out of this ever increasing complexity?

Lixia

> On May 29, 2015, at 4:39 PM, John Leslie <[email-masked]> wrote:
>