Spencer Dawkins at IETF | 17 Apr 17:28 2015
Picon

TSV thoughts for the upcoming IESG retreat

Dear TSV maevens, 

Martin and I will be meeting with the rest of the IESG during the first week in May, and the IESG and IAB spend one day together. 

It's worth your ADs asking if there are things that the TSV area needs the IESG to think about.

Martin and I have collected significant input about what we should ask Nomcom for in the position description for TSV ADs, so I think you can take that as read (and, in any case, we'll be sending the position description to TSV-Area for comments prior to launching it Nomcom-ward).

Is there anything else we should be aware of? If so, please reply on the TSV-Area list.

Thanks,

Your humble ADs
Martin Stiemerling | 18 Mar 22:04 2015
Picon

meet your Area Directors: TSV AD "office hours" at IETF-92

Dear all,

This is the announcement of the TSV AD "office hours" at the IETF-92 
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

WEDNESDAY, March 25, 2015
1520-1620 CDT 	Afternoon Session II

in French room on the Banquet level

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

Thanks,

   Spencer & Martin

Spencer Dawkins at IETF | 27 Jan 09:54 2015
Picon

Agenda items for TSVAREA in Dallas

Just to keep the TSV folk in the loop, we are planning that TSVAREA will meet in Dallas.

The agenda we're thinking of, looks like this:
  • Feedback about the area for Nomcom
  • Status update on the proposed area(s) reorg
  • Report on the IAB SEMI workshop
  • Figuring out how a browser downloaded onto an arbitrary host on an arbitrary network knows what DSCPs are available (this is a follow-on to the observation that in an opportunistic security world, the boxes in the network that set DSCPs today may not have enough information to do that in the future, because so much of the packets will be encrypted)
If you've been meaning to tell us that you have an appropriate topic for TSVAREA, please let us know really soon.

Thanks,

Spencer and Martin
Spencer Dawkins at IETF | 27 Jan 09:44 2015
Picon

IETF 92 BOF cutoff date is Friday, February 6

I pointed this out at the IAB SEMI workshop, but http://www.ietf.org/meeting/important-dates-2015.html#ietf92 says the cutoff date for IETF 92 BOF requests is fast approaching. 

I note that there are currently no BOF requests in http://trac.tools.ietf.org/bof/trac/wiki :-)

If you're thinking of requesting a BOF for Dallas, letting people know really soon would be spectacular. 

Spencer
Martin Stiemerling | 16 Oct 21:55 2014
Picon

meet your Area Directors: TSV AD "office hours" at IETF-91

Dear all,

This is the announcement of the TSV AD "office hours" at the IETF-91 
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

1730-1830 HST 	Monday Afternoon Session III

The room will be announced on Sunday, November 9.

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

Thanks,

   Spencer & Martin

Carsten Bormann | 21 Jul 17:09 2014

CoAP Congestion Control Wed 15:23–15:43 Territories

We are planning to discuss the current proposal for adding “advanced” congestion control to CoAP at
the Wednesday CoRE meeting.

Draft:	http://tools.ietf.org/html/draft-bormann-core-cocoa-02

To enable TSV people to come in and leave after the segment, we have allocated 20 minutes right at the start of
the meeting for this.
So I hope to see some transport people, even if you go on to watch the sparks at the DTNWG BOF afterwards.

Grüße, Carsten

Martin Stiemerling | 15 Jul 08:49 2014
Picon

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

Dear all,

This is the announcement of the TSV AD "office hours" at the IETF-90 
meeting in Toronto.

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

Thursday, July 24th, from 11:45 am to 12:45 pm.

The room will be announced on Monday, July 21st.

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

Thanks,

   Spencer & Martin

Jose Saldana | 10 Jun 10:38 2014
Picon

New version (v7) of TCM-TF draft

Hi all.

 

A new version (v7) of the main TCM-TF draft has been submitted to the IETF web page.

 

http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model, draft-saldana-tsvwg-tcmtf-07

 

 

Some of the improvements are:

 

- Stating that TCM-TF must keep backwards compatibility with RFC4170. Some people suggested it on the last BoF, because some devices already implement it.

- Adding some new information about Community Networks.

- Adding the possibility of optimizing UDP traffic of Constrained RESTful Environments (http://datatracker.ietf.org/wg/core/).

- Adding three new references.

- Slightly improving some figures.

 

Your comments will be welcome.

 

Best regards,

 

Jose Saldana

-----------------------------------------

A new version of I-D, draft-saldana-tsvwg-tcmtf-07.txt has been successfully submitted by Jose Saldana and posted to the IETF repository.

 

Name:             draft-saldana-tsvwg-tcmtf

Revision:         07

Title:                Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model

Document date:         2014-06-10

Group:             Individual Submission

Pages:                        26

URL:            http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-tcmtf-07.txt

Status:         https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

Htmlized:       http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-07

Diff:           http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-tcmtf-07

 

Abstract:

   Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a

   method for improving the bandwidth utilization of network segments

   that carry multiple flows in parallel sharing a common path.  The

   method combines standard protocols for header compression,

   multiplexing, and tunneling over a network path for the purpose of

   reducing the bandwidth.  The amount of packets per second can also be

   reduced.

 

   This document describes the TCM-TF framework and the different

   options which can be used for each layer (header compression,

   multiplexing and tunneling).

 

                                                                                 

 

 

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

 

The IETF Secretariat

 

 

Stefan Winter | 5 Jun 15:35 2014
Picon

Review of draft-ietf-radext-radius-fragmentation?

Hello tsv-area,

I'm co-chair of radext and the document shepherd for the above document,
and it's currently awaiting its PROTO write-up.

As I went through the latest revision, it occured to me that there are
quite some transport considerations in this, which are beyond my
technical knowledge.

In short:

A protocol that previously had no fragmentation support (RADIUS over
UDP, max size 4096 per datagram, max one datagram in flight, may be
"routed" via RADIUS proxies in a kind of overlay network) now gets some;
the fragmentation is done in a way which is "far away" from the usual
way - no sequence numbers, duplicate detection is based on a randomly
chosen State attribute, there is no explicit NAK for missing chunks and
instead the RADIUS timeout is the only way to detect and correct
fragments gone AWOL. There may be fragmentation-aware and -unaware
RADIUS proxies on the path between sender and ultimate recipient of the
payload.

I'm thinking that this warrants a closer look by TSV experts. Am I
asking at the right place?

The draft is here:
https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

Greetings,

Stefan Winter

--

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Attachment (0x8A39DC66.asc): application/pgp-keys, 3249 bytes
Black, David | 14 May 22:52 2014

Fragmentation and Path MTU text in nvo3 dataplane reqts draft

<WG chair hat off>

Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains
some text on dealing with the fragmentation and MTU effects of tunnels.
I thought I'd ask for some early review of this text, given recent IESG
excitement around fragmentation and Path MTU topics in another draft:

http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/ 

I believe that the nvo3 draft is in better shape in these areas.  Nonetheless,
I've included its current text on fragmentation and path MTU below, and (on
behalf of the draft authors and nvo3 WG chairs) I'm looking for input on
what that text should say and why.

In nvo3 terminology, an overlay network is an inner network that is tunneled
over an outer underlay network.  The nvo3 WG also uses "Tenant System" as
the term for a sender/receiver of network traffic because multi-tenancy is
an important motivation for the WG's activities in network virtualization.

--------------------------------------

3.5. Path MTU

       The tunnel overlay header can cause the MTU of the path to the
       egress tunnel endpoint to be exceeded.

       IP fragmentation SHOULD be avoided for performance reasons.

       The interface MTU as seen by a Tenant System SHOULD be adjusted such
       that no fragmentation is needed. This can be achieved by
       configuration or be discovered dynamically.

       Either of the following options MUST be supported:

          o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
            Extended MTU Path Discovery techniques such as defined in
            [RFC4821]

          o Segmentation and reassembly support from the overlay layer
            operations without relying on the Tenant Systems to know about
            the end-to-end MTU

          o The underlay network MAY be designed in such a way that the MTU
            can accommodate the extra tunnel overhead.

--------------------------------------

</WG chair hat off>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Spencer Dawkins | 13 May 17:21 2014
Picon

Fwd: [irtf-discuss] Call for Nominations: 2015 Applied Networking Research Prize (ANRP)

It's worth noting that several previous winners worked in the TSV space, so I'd love to see plenty of good nominee papers.

Spencer

-------- Original Message -------- Subject: Date: From: Reply-To: To:
[irtf-discuss] Call for Nominations: 2015 Applied Networking Research Prize (ANRP)
Tue, 13 May 2014 09:23:45 +0000
Eggert, Lars <lars <at> netapp.com>
anrp <at> irtf.org <anrp <at> irtf.org>
irtf-discuss <at> irtf.org <irtf-discuss <at> irtf.org>


CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2015 http://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2015 award period of the *** *** Applied Networking Research Prize until October 31, 2014! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: • cash prize of $500 (USD) • invited talk at the IRTF Open Meeting • travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) • recognition at the IETF plenary • invitation to related social activities • potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: • the name and email address of the nominee • a bibliographic reference to the published (or accepted) nominated paper • a PDF copy of the nominated paper • a statement that describes how the nominated paper fulfills the goals of the award • a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety • a brief biography or CV of the nominee • optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2015/. In exceptional cases, nominations may also be submitted by email to anrp <at> irtf.org. IMPORTANT DATES Applications close: October 31, 2014 (hard) Notifications: December 1, 2014 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2015-flyer.pdf


Gmane