Subject: Draft minutes from TSVAREA meeting at IETF 88

From: Spencer Dawkins <[email-masked]>
Date: Sat, 09 Nov 2013 11:04:53 -0600

Dear TSVAREA,

Linda Dunbar has sent us her notes as part of preparing minutes for this 
session (thanks, Linda! every meeting that doesn't start with chairs 
recruiting note-takers while everyone pretends to read e-mail is a good 
meeting).

If you could take a look and send changes to the mailing list by Friday, 
November 22, that would be GREAT. It would keep Martin and I from being 
minutes laggards, and that's always a challenge for area meetings ...

We'd especially appreciate matching names to the small number of ???s 
when Linda wasn't sure who was speaking at the mikes.

Thanks!

Spencer

Linda's notes follow ...

Transport Area Open Meeting (TSVAREA)
IETF-88, Vancouver
THURSDAY, November 7, 2013
0900-1130 PST

Evolving the TSV AD role

Emphasize – We are talking changes the next year

- 2013 Nomcom already TSV Ad description
- 2013 Nomcom is already talking to willing nominees
IESG-level changes: more shepherd involvement, on telechats
Recruiting a TSVarea secretary
We are discussion starting a TSV-ART: soliciting coordinator for it.

What we need to hear:
What makes you unwilling /unable to server?
- Time commitment, travel commitment, review commitment, management 
commitment?
We need to make change to enable more people willing to volunteer.

- Reducing Internet Latency workshop report (15 minutes + 5 minutes Q&A)
Mat Ford (Internet society co-chair)
-- http://www.internetsociety.org/latency2013

Summary of 2 days discussion in London (Sept 2013).

30 submissions

Scope:
- Surveys of latency across all layers

Major goal: identify metric for (access) network latency; develop an 
action plan to educate industry, identity gap

Taxonomy:
- Sources of latency
o Delay between a physical event and availability of data; transmission; 
processing; multiplexing; grouping
- Mitigating sources of latency
o Relocation, speedup, dedicating resources,
- Discussion:
o Careful and look in a lot of places for potential optimizations and 
potential conflicts.
- LOLA Use case: musicians play in different places and seamlessly 
integrate them together.
- Discoveries with LOLA
- Only work on high bandwidth/ low latency

Incentivizing the market
- What is the latency budget

What to measure:
- Minimum upload latency

Some suggestions:
- Easily defined tests which are simple
- Quantifying queue-related latency

More discussion is clearly needed:

What is fair anyway?
- Need for latency is application dependent + all stream

What about ECN?
- Potential benefits, but current semantics is not good enough.

Delay based congestion control:

Discussion:

Fundamentals:
- Local content hosting
- Peering
- More tools, in the hands of end users, generating more data already 
preferable

Roles for regulators?

Bob Briscoe:
“Dedicated network is better for latency” is not a good message to public.

Larry Massenta: the measurement you are talking about does not align 
with protocol design

Jim Getty:
remember when the network is only one piece of element?
Now the latency is sources from everywhere

Roberta (Google):
The measurement doesn’t say any anything about user experience.

??: please watch the video

Matt Mathis:
Bandwidth doesn’t always help latency. Optimized CPU doesn’t help 
network, but accurately hurt network.

- Google QUIC protocol (25 minutes + 10 minutes Q&A)
Jim Roskind

-effectively replace TCP and TLS out from under SPDY (predecessor of 
HTTP/2.0)
- push all the way to application space
-

Overview: predecessor of HTTP/2.0

Why is SPDY fast?
- It is all about latency (time till response)
- SPDY multiplexes requests over on TCP connection
- Send multiple requests

Issues: SPDY runs over TCP
- Lose one SPDY packet; all the streams wait : HOL blocking
- SPDY maybe slow to connect
o TCP connect may cost 1-round trip-time (RTT)
- When one packet lost, all sessions stall

TCP connection: some countries are 400 ms. A lot of time goes by before 
any action can be exchanged.

QUIC goals:
- Deploy in today’s internet
- When one stream block, you don’t want other stream to be blocked.
- Mobile is taking over the world.

QUIC Success criteria:
- Two paths:
o QUIC makes headway reducing latency

Field Data, plus applications needs drive development

Lars: Your QUIC is closed system.
Are you going to bring the protocol to IETF?

Jim: it is implemented on Chrome. It is open source. To be discussed 
with Firefox.

??: happy to see it being presented. I hope it will come to IETF.

Lars: that makes me happy.

Can we really deploy a UDP in a similar fashion?

Stewart:
Jim: we have to go to reserve port

Stewart (Apple): For Chrome: It is typically home computer, but not on 
mobile device.
Jim: It is hard to dictate what browser to use, but there are people 
using this on Mobile

Michael Wetzel: UDP

Jim:

NAT unbinding: how unfriendly it is?
How much idle until unbinding?
Peak around 80%.
QUIC time out after 30 seconds.

Lars: have you done it for TCP?
Jim: no, I haven’t done it for TCP.

How does QUIC achieve 0-RTT connection cost?

Congestion avoidance via packet packing:
We worried of melting internet.
TCP cubic is baseline
Working on packing “plus” TCP cubic

Also monitor inter-packet spacing, to measure queue in the network.

Does packet pacing really reduce packet loss?
We see recognizable less amount of packet loss.
Predominated determined by the access link.

Jim Gettes: it encourages good behavior in the internet

How might QUIC connection survive a mobile network change?
- Possible to use second IP address.
- See QUIC do better to handle mobility than traditional TCP.

??: QUIC is more like 4 tuple

?? it is not globally unique
Jim:

?? can you talk about trade off? If it is only 4 tuples

Jim: it is nice to return back to the same site.

How can a Forward Error correction (FEC) packet help?
- 20 packets: about 18% retransmission. More packets with higher 
re-transmission rate.

Solicit people to contribute: [email-masked]

Matt:
I was invited to participate in this project, but I turned it down. I 
think that protocol should be independent of applications. At the end of 
the days, those things are back to TCP. I support this project, because 
it is an experiment for internet, but not replacing TCP.

Dan Frost (Cisco): this work is very interesting. My concern is what is 
your intention on how to develop it? Do you intend to publish this as 
IETF draft?

Jim: being a new comer, I am not familiar with the process. The answer 
should be yes.

??: I hope we can learn from this. Here are the experts.

Dan Frost (Cisco): there are a lot of avenues for you get feedback to 
this protocol. You can publish it as independent experiential ID.

Jim: we have a server side demo version.

Michael Ramalho (Cisco): I am the one who asked Google to present it. 
What you presented has been developed. Most of my concerns are: this is 
a massive layer violation. But it is beneficial to end users. Second: I 
am scared of congestion control. I encourage you to work with other WGs.

Lady from Ericsson: everything presented here have been discussed by 
some IETF WGs. Maybe should consider reference those items being 
standardized by IETF.

??: we are not claiming that what we do is new. However,

Jim: we did look at the HTTP, we believe that we can prototype something 
faster than bring a new protocols to standard body.

??(Ericsson): bring your protocol to IETF to have more eyes to check on it.

- Evolution of IETF Transport Protocols (60 minutes) by Spencer D
-- http://www.ietf.org/mail-archive/web/tsv-area/current/msg00973.html

Purpose: check if the current IETF transport protocols up to speed with 
what is needed by today’s hosts:

RUTs at IETF 43:

Michael : congestion comes more important in the transport

(Ericsson): SCTP is just TCP without header. It is a streaming concept. 
It is TCP with congestion control.

??: SCTP is more than TCP with congestion control.

Matt:

Eric (EKR): WebRTC uses SCTP over DTLS for data channels
Proposed optimization: reduce inter-layer redundancy; combine 
inter-layer messages (piggbacking).

Work Items: TLS

Matt: Layer is not optimizating on clarity. Mixing layer is for 
optimizing performance.

Wes Eddy: Saratoga Update
Saratoga is in operational use: disaster monitoring: to download 
pictures from satellite.
- 400 mgb/s download

Cisco has an implementation of Saratoga. They funded congestion control 
to Saratoga.

Background to Saratoga: file transfer protocol.
- NASA and Cisco co-develop the protocol.

Characteristics relevant to evolution of IETF transport protocols.
- Make it work on more paths.
- Work with high bandwidth asymmetry

We get magnitude faster than TCP

You can scale up to triple computers.

Evolving IETF transport protocols:
- TCP, UDP, SCTP, DCCP: it is not about protocol, but what is in the 
protocol. The end to end capability. It is not layering.
- Saratoga is not a clean transport layer protocol. But it has great 
performance.
- Scale to high throughput and low delay. It is possible by looking at 
Saratoga.

Carstein: there is a whole WG (RMT) to work on the transport protocol. A 
lot of concepts developed can be the building blocks.

Jana Lyenyar: Some thoughts from a disarrayed mind on the evolution of 
transport abstractions

What is our perview: new features or bug fixing?

Do Apps need new abstractions?
- Apps (things that human interact with ) today

What is in the gap?
- Common design patterns
- Performance optimizations
- New transport
-
We do a lot of work in mechanisms, as building blocks.

(Ericsson): what do you mean by the second bullet: (Improvements to 
congestion control seem hidden under TCP’s bytestream API)

Jana: this is to point that most of work is all around TCP.

Matt: there is fundamental limitation on TCP, there is no time stamp. A 
lot of little details in TCP that can’t be fixed.

Jana:

??: looking at stack: I can say that a lot of problems are that we build 
excellent mechanisms, but we hide how application using them. We should 
focus on that API to those mechanisms should be the fundamental thing to 
look at. We invent something new, but applications can’t see it.

YuShenChen: the current congestion we build is ill fitted for 
applications. There is no good congestion control mechanism (algorithms) 
that browsers can use.

Jana: Our network is hiding, focusing so much on the bits on the wire.

Reberto P: There are a lot of streams: hundreds of them. Our current 
scheme doesn’t consider them. Hiding the mechanism force us to create 
other mechanisms.

Jim: There is no way for people to test if things are done correctly. A 
lot of designs are not done in a unified way.

TCPcrypt: by Stanford Andrea:

Maximize the security for everything.
- 0 configuration, work with NAT
- Integrate with app-level authentication
- High performance
- Avoid double encryption

Does it matter if I send thousands of connection?

??: If this is good, people don’t need to use TLS.
Andrea: this is not intended to replace TLS. If

Brain T: how many lines of code do I need to use?
Andrea: just one line

Dan Frost: Is there an attempt to have an IETF draft for this?
Andrea: the intension is to have an IETF draft. We want to
Dan Frost: we would like to see what you have done, and have IETF to 
work on it.

Dan F: What is it from implementation point of view? Is it from kernel 
implementation?
Andrea: you don’t have to change the Apps.

??: in the multi-path TCP group, we are working on security. This come 
up as a good candidate. We would like to work on this.

Andrea: I would like to hear more.

Philip (BT):

YuShenChen: Can you compare this with QUIC. When we talk about low 
latency, QUIC is a good example.

Andrea: QUIC is on a clean slate. But we are working with existing 
applications, i.e. using TCP.

Rut B: the intent of QUIC is to make it work. That is why we implement 
it and try it. We don’t want to leave it just like experimental.

Jim: I believe if more is given to transport layer, transport layer can 
do better. If it is possible for Transport to switch to different port 
depending on the underlay network and performance.

Rut B: when people say “why don’t you use this”. The intent of everyone 
here is to enhance people experience. There is also need to work from 
Transport to link layer. We don’t have well established mechanism across 
layers, e.g. some transport layer doesn’t require lower layer to 
re-transmit.

YuChenCheng: it is all about passing information across layers. If we 
have those information, the transport layer can be much faster.

Brain Tramall: more on interfaces from Applications to transport layer, 
and transport layer to lower layers. We need take those works.
Brain Tramall volunteer to bring in more work in this domain.

??: there is lot of emphasis on zero startup. That problem might not be 
important as it was.

Jana: We should eliminate the latency. Don’t be afraid of congestion 
control will melt internet. People do congestion control. TCP Cubic is 
the congestion running today. If we document those, then we are doing 
our job.

Lars: Cubic is a terrible example because there is still no document on 
it. It is quite exciting to see so many things in transport area. Just 
dropping the code is not solution. As a community, we need to do it 
together. It is Ok to experiment on Chrome. How fast can you go without 
burning CPU cycles. Think about 100G.

Jim: preliminary experiment with UDP doesn’t have significant difference 
from TCP.

David Black: like the ADs to look at the process. The problem has been 
based on what does it mean by interoperability of API. Should bring it 
to IAB.

Spencer: make sure to continue the discussion on emails and hallway on 
the topics.