Spencer Dawkins at IETF | 28 Jun 16:20 2016

TSV AD Office Hours at IETF 96

Dear TSV Chairs and TSV Fans,

Mirja and I have scheduled TSV AD Office Hours in the IESG breakout room (listed as Chess) on Sunday afternoon. The precise coordinates are:

- 1400 - 1530: TSV AD Office Hours (Spencer and Mirja)

Please let us know if you would like to come by and talk about TSV topics.


Spencer and Mirja
Spencer Dawkins at IETF | 20 Jun 18:43 2016

IETF 96 BOFs and new topics

Just so TSV people are aware of things you may not already be tracking ...

See you in Berlin,

Martin Stiemerling | 14 Jun 09:17 2016

Fwd: Help needed: TSV Triage team: Review of IETF LC documents (as of 06/14)

Dear all,

Please find below the list of drafts just before IESG review.

We actually are in need for review of these drafts:
-URGENT: draft-ietf-avtext-splicing-notification (additional review 
request by Mirja)
- draft-ietf-dnsop-dnssec-roadblock-avoidance
- draft-ietf-forces-interfelfb

Volunteers picking a draft for review would be highly appreciated! :)



-------- Weitergeleitete Nachricht --------
Betreff: Help needed: TSV Triage team: Review of IETF LC documents (as 
of 06/14)
Datum: Tue, 14 Jun 2016 06:38:31 +0200
Von: Martin Stiemerling <mls.ietf <at> gmail.com>
An: Tsv-triage <at> ietf.org

Dear ADs, triage team members,

I did work through all documents that are in IETF LC, IESG processing or 
being requested publication as of 06/14, 04:30 am UTC.

I would appreciate either Allision or Wes to assign the docs under 
"require TSV attention" to somebody in the ART. I won't be able to get 
to this until Friday, as my day job is eating up my time until then.

Please find below all documents checked and what to do with these documents.

Documents that require TSV attention:
- draft-ietf-dnsop-dnssec-roadblock-avoidance
- draft-ietf-forces-interfelfb

Documents that may require attention:
- draft-ietf-ospf-transition-to-ospfv3

Documents that do not require TSV attention:
- draft-ietf-alto-deployments
- draft-ietf-avtext-splicing-notification
- draft-ietf-calext-extensions
- draft-ietf-ccamp-additional-signal-type-g709v3
- draft-ietf-cdni-metadata
- draft-ietf-dmarc-interoperability
- draft-ietf-idr-ix-bgp-route-server
- draft-ietf-mile-implementreport
- draft-ietf-mmusic-msid
- draft-ietf-sidr-rfc6485bis
- draft-ietf-teas-rsvp-te-srlg-collect
- draft-ietf-trill-irb
- draft-pal-eidr-urn-2016
- draft-pd-dispatch-msrp-websocket
- draft-sweet-rfc2910bis

Brian Trammell | 19 May 17:04 2016

Possible WG-forming follow-on to SPUD BoF

Greetings, all,

We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common
substrate protocol for encrypted transports based on the requirements derived from experimentation
with the SPUD prototype.

First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working
group should have a different name. We're using the derived requirements, not starting for the
prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in
the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point.

The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter
in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there
work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work?

Thanks, cheers,

Brian and Mirja

Path Layer UDP Substrate (PLUS)

The PLUS working group’s goal is to enable the deployment of new, encrypted
transport protocols, while providing a transport-independent method to signal
flow semantics under transport and application control.

The current Internet protocol stack has no layer for explicit signaling of
flow semantics and characteristics to network elements, nor an integrated
signaling mechanism from network elements to back to endpoints and
applications. This layer never evolved within the stack, because middleboxes
and other devices on path could simply inspect and modify headers and payload
of unencrypted traffic at every layer. This implicit use of information from
the transport and application layers is a key origin of the ossification that
makes it hard or impossible to deploy new protocols.

In order to support more ubiquitous deployment of encryption, explicit
signaling must be added to the stack, and it must be transport protocol
independent. While IP would seem to be the natural home for this facility,
both IPv4 and IPv6 options and extensions have deployment problems on their
own, which makes it hard to include any additional information in these
protocols.  Additionally, a feedback channel that provides information from
on-path devices back to endpoints and applications, e.g. for error handling,
is essential for the deployment and success of an explicit cooperation

The PLUS working group will specify a new protocol as a Path Layer User
Substrate (PLUS), to support experimental deployment of explicit cooperation
between endpoints and devices on path, with the following goals:

- enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of similar
semantics to existing protocols (e.g. TCP) to devices on path (e.g. NATs and firewalls)

- allow applications and transport protocols to explicitly provide limited information to devices on path

- allow devices on path to provide feedback and information about the path to sending endpoints, under
sending endpoint control

- allow devices on path to provide information about the path to receiving endpoints, with feedback to the
sending endpoint, under sending endpoint control

Note that this approach explicitly gives the control of information exposure
back the application and/or transport layer protocol on the end host. It is
the goal of PLUS to minimize the information exposed at the level of detail
that is useful for the network, while encrypting everything else. This is
important to avoid future implicit treatment and the resulting ossification,
as well as to leverage the principle of least exposure to minimize privacy
risks presented by explicit cooperation.

Given that the primary goal of PLUS is to enable the deployment of arbitrary,
fully encrypted transport protocols, we assume that the higher layer protocol
can provide an encryption context that can be used by PLUS to provide
authentication, integrity, and encryption where needed. The primary threat
model to defend against will be modification or deletion of exposed
information by middleboxes and other devices on path, by allowing a remote
endpoint to detect modifications.

The working group will start with an initial set of use cases (see
draft-kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req),
taken from experience with the Substrate Protocol for User Datagrams prototype.
The working group's main output will be an experimental protocol specification,
together with an initial registry of types of information that can be exposed
using PLUS, clearly aligned to these use cases and requirements. The working
group will close if it is not able to come to consensus on a protocol design
to meet these requirements.

The working group will additionally aim to identify other working groups that
could or should address parts of these requirements within existing protocols,
e.g. by specifying new protocol extensions or as input for on-going
standardization work. It will aim to work with working groups defining
encryption protocols (e.g. TLS) which could be used for encryption of
transport protocols running over PLUS.

Spencer Dawkins at IETF | 12 May 19:17 2016

2016 Nomcom TSV AD position description - please review

From our discussion at IETF 95 ...
  • We noted that Spencer’s AD position is up for review in this Nomcom cycle. 
  • We made changes to the TSV AD position for Nomcom in the previous Nomcom cycle, and do not plan to make more changes for this Nomcom cycle, but we are always happy to listen to suggestions. 
  • The current position description is at https://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise, and comments are welcome at tsv­area <at> ietf.org,
If you could take a look at this and comment by next Friday, May 20, that would be most helpful.

Spencer and Mirja
Spencer Dawkins at IETF | 7 May 03:59 2016

IETF 95 TSVAREA Minutes are FINALLY posted (whew!)

I finally went through Brian Trammell's excellent notes and the MEETECHO session for TSVAREA, and the result is at https://www.ietf.org/proceedings/95/minutes/minutes-95-tsvarea

If you see errors or omissions, please let us know - the cutoff for finalized minutes is May 27, so if you could let us know before that, even better ...

Spencer and Mirja
Bob Briscoe | 6 Apr 00:39 2016

current and future hot topics in TSV

TSV ADs, TSV-Area follks,

Apologies, I missed tsvarea this afternoon (preparing slides, and I 
missed my alarm).
I understand the session on current and future hot topics in TSV was 
rather short.
Maybe the two sentences above are related ;)

1. I think the DualQ Coupled AQM is an important development, not just 
cos we've got cool low queuing delay for all traffic out of it, but...

...because it is an "incrementally deployable clean slate" that is 
interesting enough to network operators that it could get deployed.

What I mean is, it's a incrementally deployable queue isolated from 
existing traffic in which we could develop new congestion control 
together with new network behaviour.
Obviously, new host & network capabilities have to be deployable 
independent of the other, but there is a window of deployment 
opportunity for new ideas....

For instance, if a new slow-start needs a new signal from the 
bottleneck, that could be included in the initial spec for the L4S 
queue, so there would be no need to cater for L4S queues without that 
signal. Of course, you would have to cater for non-L4S bottlenecks 
still, but if you were getting signs you were in an L4S bottleneck, this 
could be powerful.

2. The L4S activity itself would involve new TSV standardisation 
activity across 3 WGs (not to mention new implementation activity).
We're planning on outlining this in the L4S Bar Bof on Thu 9am 
(advertised earlier today on this ML).

Slide 4 of our slides about L4S (tomorrow in tsvwg) shows the three 
areas needing standardisation (AQM, TSVWG & TCPM)

There's also potential for loads of new activity evolving scalable TCP 
(TCP Prague/DCTCP).
I prepared the following table for the TCPM chairs listing all this:




Bob Briscoe                               http://bobbriscoe.net/

Martin Stiemerling | 21 Mar 06:37 2016

Meet your Area Directors: TSV AD "office hours" at IETF-95

Dear all,

This is the announcement of the TSV AD "office hours" at the IETF-95 

The office hours are for the case there are things that you need to 
discuss with the Transport Area Directors in person and aren't able to 
pin us down any other time.

The time slot reserved for the office hours is

Tuesday, April 5, 2016
16:20-17:20 	Tuesday Afternoon session II
Room is to be announced.

Please let us know in advance if you are planning to meet us, so that we 
can plan a bit ahead, if possible.


   Mirja, Spencer & Martin


UDP zero-checksum in IPv4



Does anyone have any info on the percentage of UDP packets with zero-checksum

for IPv4 packets in today’s networks (enterprise, internet, any network). 

Seems like there is not a whole lot of info about this on the WEB. Anyone has any firsthand/realworld experience with this? Thanks.




Spencer Dawkins at IETF | 24 Nov 22:03 2015

Starting up TSV-ART

Martin and I mentioned that we will be closing TSV-DIR and starting up a TSV Area Review Team (TSV-ART), but we didn't actually solicit members when we talked in Yokohama. 

If you're willing to serve on TSV-ART (and a couple of people have already stepped forward), please let Martin and I know by December 4.


Spencer, for Spencer and Martin
Spencer Dawkins at IETF | 21 Oct 19:23 2015

Transport AD office hours

Just to make sure people have seen this, Martin and I are doing office hours in Yokohama. 

The details are in https://datatracker.ietf.org/meeting/94/agenda.html, but it's Monday, 17:10-18:30, in Room 312.

This is what it looks like when your ADs are awake enough to arrange this in time to include it in the formal agenda :-)