Subject: Draft agenda for the IETF-87 TSV Area meeting uploaded

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 Jul 2013 08:48:16 +0200

Hi,

Here is the draft agenda for the IETF-87 TSV Area meeting:
Transport Area Open Meeting (tsvarea) -- IETF-87
THURSDAY, August 1, 2013
09:00-11:30

Draft Agenda:
09:00 Note Well and agenda bashing (5 minutes)
09:05 TSV/NOMCOM (15 minutes)
09:20 MPTCP Update (30 minutes)
09:50 QUIC protocol introduction (45 minutes) -- tentative
10:35 Online Games Tutorial (45 minutes)

The link to the current version:
http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea

Let Spencer and me know if you have something that should be on the agenda.

   Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 4 Jul 2013 10:25:00 -0400

Hi,

What is QUIC? Is there a draft?

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Stiemerling
> Sent: Thursday, July 04, 2013 2:48 AM
> To: [email-masked]
> Subject: Draft agenda for the IETF-87 TSV Area meeting uploaded
> 
> Hi,
> 
> Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013
> 09:00-11:30
> 
> Draft Agenda:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 4 Jul 2013 17:10:33 +0200 (CEST)

> What is QUIC? Is there a draft?

https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true
http://blog.chromium.org/2013/06/experimenting-with-quic.html
http://en.wikipedia.org/wiki/QUIC

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jul 2013 17:37:56 -0700

A link to a draft would be useful.

A slot should not be granted if there isn't a draft.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 5 Jul 2013 07:42:10 +0200 (CEST)

> A slot should not be granted if there isn't a draft.

Why? Is there some really important principle I'm missing here?

Yes, I'm sure this document could be reformatted into a draft without 
excessive work and it must be if the work is to take place in an IETF WG, 
but do you really want to deny the presentation on this (I guess formal?) 
requirement?

I am not in any way affiliated with QUIC development, I have just read the 
document and find it interesting.

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 5 Jul 2013 09:24:18 +0200

Hi, Martin.

Regarding the "Online Games Tutorial", Mirko and I are adjusting the
presentation in order to spend just 45 minutes. We have received some
interesting suggestions after announcing it in the IETF87attendees mailing
list. We think we will show and capture the traffic of 3 different games:
- A UDP-based "First person shooter"
- A UDP-based car racing game, including a 2-minutes car race in which some
people in the room (and some remote ones) will be able to participate.
- A TCP-based "Massively Multiplayer Online Role Play Game (MMORPG)

One question: the tutorial is scheduled at 10.35. It lasts 45 minutes.
Should we understand that from 11.20 to 11.30 we will have some time for
questions and answers?

Thanks!

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En
> nombre de Martin Stiemerling
> Enviado el: jueves, 04 de julio de 2013 8:48
> Para: [email-masked]
> Asunto: Draft agenda for the IETF-87 TSV Area meeting uploaded
> 
> Hi,
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 5 Jul 2013 10:36:33 +0200

> Should we understand that from 11.20 to 11.30 we will have some time for

The 10 minutes are the end are reserved as buffer and you should not 
plan this for Q&A.

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 5 Jul 2013 10:40:01 +0200

Hi Joe,

> A link to a draft would be useful.

There is no draft but this is of interest to the transport community at 
large. And it is tentative right now as we do not know if there will be 
this presentation, i.e., waiting for the confirmation.

> A slot should not be granted if there isn't a draft.

That's true for working groups, but area meetings should have the 
possibility to talk about topics that are not (yet) documented in an 
Internet draft.
This has also been done in the past, e.g., at IETF-77 for the RTMFP 
protocol:
http://www.ietf.org/proceedings/77/slides/tsvarea-1.pdf

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: <[email-masked]>
Date: Sat, 6 Jul 2013 04:15:15 +0100

Joe's assertion is wrong.

The IETF is not the place where new transport protocols are developed. Transport is
recognised as an underresourced area; David Harrington's "Thoughts from a past
experimental Nomcom selection for TSV Area Director"
http://www.ietf.org/mail-archive/web/ietf/current/msg77880.html
discusses that, but did not at any point mention new protocols. The IETF has no time
for them, as it's too busy maintaining and finetuning and documenting the existing ones.

First deploy, then tell the IETF about it, and let the IETF put the documentation into
the preferred 1970s ASCII format. draft-ietf-http-v10-spec-00 being the classic case
in point, written up several years after global web domination.

Setting up httpbis to tweak http, after spdy et al were developed outside the IETF
and proven successful, is where the IETF  is at - and httpbis isn't even in the transport
area, despite http increasingly looking like a transport and protocol hourglass waist.

The IETF should be grateful that Google wants to tell it about a new transport protocol
that it has deployed worldwide. Demanding that it be written up as an internet-draft
beforehand is unreasonable, and arguably a waste of effort.

imho.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: 05 July 2013 01:37
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 6 Jul 2013 06:00:27 +0000

Hi,

> A slot should not be granted if there isn't a draft.

when Magnus and me started TSVAREA, the intent was that it be an information dissemination session, and that IDs were not going to be published through TSVAREA. (We have TSVWG for that.) That's different from other area meetings, such as INTAREA, that do push drafts.

We had many presentations such as QUIC which did not come with drafts at the time (SMT, SPDY, RTFMP, etc.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Sat, 6 Jul 2013 15:15:42 +0900

Thanks - the area vs wg distinction makes sense. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 6 Jul 2013 16:03:16 +0900

On Jul 6, 2013, at 12:15 PM, <[email-masked]> wrote:

> the preferred 1970s ASCII format.

Unless drone revoked RFC 2780, that's the wrong sequence.  First develop and test, then tell the IETF in a standards- track RFC, then get that RFC approved, then get a transport number, then deploy.  

I don't mind general info about stuff in the area meetings, but feedback requires participation, which requires a draft. And deployment of transports requires approved standards to get assigned numbers. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 6 Jul 2013 16:15:25 +0900

s/drone/someone/

set autocorrect=false

:-)

---

From: <[email-masked]>
Date: Sat, 6 Jul 2013 10:20:55 +0100

Well, that's the wrong sequence, too. IANA can allocate numbers at draft stage long before RFC - as it did for Saratoga http://saratoga.sf.net

But even your sequence says 'tell the IETF', not 'participate in an IETF WG with all the drones'.

Since QUIC is already deployed worldwide, I am reminded of King Canute.

Lloyd Wood

________________________________________
From: Joe Touch [[email-masked]]
Sent: 06 July 2013 08:03
To: Wood L  Dr (Electronic Eng)
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 6 Jul 2013 11:33:32 -0700

And where in your sequence did a standard appear? Outside a wg?

---

From: <[email-masked]>
Date: Sat, 6 Jul 2013 22:52:53 +0100

Few RFCs are standards track.

IETF transport focuses on maintaining its existing standards; that's
my point. It's not really set up for experimental work not directly 
related to those standards.

Lloyd Wood

Sent: 06 July 2013 19:33
Cc: <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Sat, 6 Jul 2013 15:30:49 -0700

> Few RFCs are standards track.

But only those qualify for new transport numbers. 

> related to those standards.

Early experimental work can come through the IRTF but new standards track transports can easily start in tsv wg. That wg isn't just for changes to existing standards. 

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 06 Jul 2013 22:10:30 -0400

> related to those standards.

I'm not really sure how TSV could be setup any better to do this type
of work.  It could be a matter of opinion how "directly related" the
experimental work is.  For instance, CONEX is built on ECN, MPTCP is
built on TCP, and RMCAT is building on RTP ... but all are such
significant developments that they can't be classed as simply
"maintenance".  In Berlin, TSV has 2 BoFs planned in Berlin which are
not jst maintenance of existing standards (TCMTF and AQM). Clearly,
there are also important existing protocols (TCP, SCTP, etc) that a lot
of TSV energy goes into maintaining, but that's certainly not all that
we do.

The community focuses on what it chooses to, by individuals (and
companies sponsoring them) investing time and energy into the WGs and
drafts that they have shared interests in.  For some experimental
things, that can be difficult because it requires a critical mass, and
people have to be willing to work together at whatever pace the group
adapts.  Larger groups will have slower paces.

The hope is that we wind up with better specs, less flaws, and stronger
interop between multiple codebases as a result of working together, and
create a better Internet.  Those are not the priority for every protocol
development effort, and a lot of people have good reasons for doing
things on their own.  This does not signal a problem with the IETF.

-- 
Wes Eddy
MTI Systems

---

From: "ietfdbh" <[email-masked]>
Date: Sun, 7 Jul 2013 13:52:30 -0400

Hi,

The IETF has always stressed a bottom-up approach, taking ideas and "running
code" contributed by the community for new networking functionality, ranging
from disruptive to purely maintenance, and deciding whether there was IETF
consensus to work on standardizing the functionality.

Typically contributed functionality is described in Internet-drafts so the
IETF community can better understand the technology being proposed. This
approach also helps to ensure the IETF doesn't become a forum for marketing
press releases or other inappropriate usage of scarce IETF face-to-face
time.

Originally, BOFs were simply side meetings, often in bars, for an informal
discussion of a new idea. There were no IPR rules, no requirements for an
internet-draft first, and so on. Meeting in a bar allowed people to discuss
*ideas* without the formality of requesting an IETF session. But there is a
practical limit to the size of audience who can meet in a bar, to exchange
ideas on bar-napkins.

To  supplement bar-bofs [rfc6771],  the IETF standardized BOFs explicitly
designed to allow the presentation of new ideas to the community, permitting
larger audiences to gather in a room and have their meeting announced. BOFs,
however, grew very quickly to meetings that might include food and alcohol
provided by the idea proponents, and became more formal over time, with
officially scheduled sessions, BOF chairs, microphones, and the whole
shebang. Internet-drafts are typically required before a BOF session will be
approved. 

Area directors realized there was a real downside to the increasing
formality of BOFs - interesting ideas in the real world were not being
brought into the IETF because the requirements to get a BOF session had
become a hurdle. The IETF ignores what is happening around it in the real
world at its own peril. Ignoring important new relevant technologies,
especially potentially disruptive technologies, risks the IETF being
"overtaken by events". 

If we want to stay relevant to the industry we support, we must be willing
to listen to new ideas even if they do not come in the form of
internet-drafts. Area meetings then became a venue for what some directors
refer to as "mini-BOFs" - a larger audience than the bar-napkin discussions
afford, but less formal than BOFs. An internet-draft would be nice so people
knew where to look to find a discussion of the technology. However, the real
goal is to get the industry to come into the IETF to talk about interesting
and relevant technologies they have been working on outside the IETF.

David Harrington
[email-masked]
+1-603-828-1401

> Behalf Of Wesley Eddy
> Sent: Saturday, July 06, 2013 10:11 PM
> To: [email-masked]
> Cc: [email-masked]
> I'm not really sure how TSV could be setup any better to do this type of
work.
> It could be a matter of opinion how "directly related" the experimental
work
> is.  For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT
is
> building on RTP ... but all are such significant developments that they
can't be
> classed as simply "maintenance".  In Berlin, TSV has 2 BoFs planned in
Berlin
> which are not jst maintenance of existing standards (TCMTF and AQM).
> Clearly, there are also important existing protocols (TCP, SCTP, etc) that
a lot
> of TSV energy goes into maintaining, but that's certainly not all that we
do.
> 
> The community focuses on what it chooses to, by individuals (and companies
> sponsoring them) investing time and energy into the WGs and drafts that
> they have shared interests in.  For some experimental things, that can be
> difficult because it requires a critical mass, and people have to be
willing to
> work together at whatever pace the group adapts.  Larger groups will have
> slower paces.
> 
> development effort, and a lot of people have good reasons for doing things
> on their own.  This does not signal a problem with the IETF.
> 
> --
> Wes Eddy
> MTI Systems

---

From: Spencer Dawkins <[email-masked]>
Date: Sun, 07 Jul 2013 22:39:35 -0500

The notes I've read in this thread have been very helpful to me. Thank 
you for sharing.

At this point, the only thing I'm obsessing about is that we get decent 
IPR declarations when IPR exists. Our BCPs define a contribution broadly 
enough to include presentations. The *IRTF* now has an IPR policy that's 
roughly equivalent to the IETF's policy; if people can't talk about 
research without disclosing, we should have the same stance for 
presentations on engineering topics.

If the presenters are clear on that, I'm over the biggest hurdle.

Spencer

---

From: Scott Brim <[email-masked]>
Date: Mon, 8 Jul 2013 12:37:17 +0000

>presentations on engineering topics.

Spencer, we don't need IPR disclosures if a contribution is not expected
to affect IETF outputs.  "Participants who realize that the IPR will be or
has been incorporated into a submission to be published in an Internet
Draft, or is seriously being discussed in a working group, are strongly
encouraged to make at least a preliminary disclosure."

---

From: <[email-masked]>
Date: Mon, 8 Jul 2013 13:39:36 +0100

But if it's not expected to have any effect on IETF outputs, why bother presenting it at TSVAREA to the IETF?

Oh wait, QUIC isn't in an internet-draft, so it won't have any effect on IETF outputs.

We don't need IPR disclosures. We're good.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/http-dtn

has previously presented to TSVAREA to zero effect.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scott Brim [[email-masked]]
Sent: 08 July 2013 13:37
To: Spencer Dawkins; ietfdbh
Cc: [email-masked]
Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 08 Jul 2013 10:10:06 -0500

> But if it's not expected to have any effect on IETF outputs, why bother presenting it at TSVAREA to the IETF?

FWIW, Martin and I have chatted privately about possible reasons to have 
a presentation about a technology which isn't described in a draft, in 
TSVAREA. I came away from that discussion thinking that it's really hard 
to know that an idea won't affect IETF outputs in the future.

I wasn't there, but I believe a similar question came up most recently 
from the audience during a non-draft presentation to SAAG - "is there 
IPR on the fascinating topic you're presenting?" Without regard to 
anything else, what I heard was that the question pretty much derailed 
the conversation, because IETF participants require little prompting to 
hypothesize about IPR instead of talking about a technology. So, at 
least one reason for me to ask now, is to avoid someone else asking the 
same question in a roomful of people when we could be learning from 
someone who cared enough to share with us.

Spencer

p.s. Scott, I'm more than somewhat sympathetic to your point of view, 
but after the IRSG decided to require disclosures just in case someone 
contributed something in a research group that was interesting enough to 
take it to the IETF eventually, I'm having a hard time being less 
curious in what is, after all, an IETF working group.