Brian Trammell | 19 May 17:04 2016
Picon

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
(Continue reading)

Spencer Dawkins at IETF | 12 May 19:17 2016
Picon

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
Picon

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
Picon

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)
http://bobbriscoe.net/presents/1604ietf/1604briscoe-tsvwg-ecn-l4s-id.pdf

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:
http://bobbriscoe.net/presents/1604ietf/tcp-prague-todo.pdf

Cheers

Bob

--

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

Martin Stiemerling | 21 Mar 06:37 2016
Picon

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 
meeting.

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.

Thanks,

   Mirja, Spencer & Martin

Picon

UDP zero-checksum in IPv4

Hi,

 

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.

 

Kris

 

Spencer Dawkins at IETF | 24 Nov 22:03 2015
Picon

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.

Thanks! 

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

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 :-)

Spencer
Martin Stiemerling | 17 Aug 07:14 2015
Picon

Meeting minutes of TSVAREA <at> IETF-93 online

Hi all,

You can find the meeting minutes of TSVAREA session  <at> IETF-93 here:
https://www.ietf.org/proceedings/93/minutes/minutes-93-tsvarea

Let Spencer and me know if you catch something that is inaccurate or 
missing.

Thanks to Andrew McGregor for taking the minutes!

Regards,

   Martin

Jose Saldana | 21 Jul 16:50 2015
Picon

Bar-BoF about Simplemux and TCM moved to Thursday

Hi all,

 

In order to avoid interference with the QUIC Bar-BoF on Wednesday, the Bar-BoF about traffic optimization with Simplemux has been moved to:

 

Thursday 20:15. (You may lose half the bits & bytes) We will meet near the Registration Desk.

 

A summary about Simplemux is here: http://www.slideshare.net/josemariasaldana/simplemux-a-generic-multiplexing-protocol. In fact, these are the slides to be used in the presentation at GAIA session in Prague next Wednesday 9.00: https://datatracker.ietf.org/meeting/93/agenda/gaia/

 

Simplemux is a lightweight protocol designed for creating a tunnel of multiplexed packets. We have built an implementation: https://github.com/TCM-TF/simplemux.

 

When combined with ROHC compression, significant savings can be obtained as e.g. a 45% bandwidth reduction when multiplexing a number of RTP VoIP flows together.

 

The idea of the Bar-BOF is to give a more detailed explaining about Simplemux, and to show the protocol running between a set of (virtual) machines.

 

The implementation has been built in C, and it can even run in a low-cost Access Point running OpenWRT.

 

Best regards,

 

Jose Saldana

 

Jana Iyengar | 20 Jul 11:20 2015
Picon

QUIC BarBoF this Wednesday

Hello all,

We will be running a BarBoF on QUIC this week, where we will be presenting the current state of QUIC and gauging interest in other implementations of QUIC, with an eye towards kicking off a standardization effort in the near future.

When: Wednesday (July 22), from 8:20PM to 10:00PM.
Where: Congress Hall 1.
There will be light snacks, etc.

Relevant drafts:
These are works-in-progress, and we very much appreciate any feedback on the docs!

Hope to see you there!
- jana

Gmane