qinxiaowei@cnnic.cn | 14 May 10:49 2015
Picon

Upload Acceleration Transport Network for Upstream Traffics Generated by End Users

hi,folks

       Since many popular cloud computing services, such as YouTube, Facebook, Online Storage, etc., are proliferating rapidly these days, photos, videos and other upstream traffics generated by end users are rapidly increasing and expected to continue doing so in the future. 
       In the face of this growth, many NSPs have deployed or are deploying their own acceleration system for upload traffics. It is generally desirable that a given content item generated by End Users can be uploaded to data center accelerated by the caches which likes their downstream counterparts for maximizing throughput. 
      A given cache server in charge of receiving a given content generated by EUs may be close enough to the EU's current location or attachment network, and the content is actually delivered to the data center by the cache server on behavior of the EU. 
      End Users, NSPs and Telecommunication Service Providers (TSPs) may benefit from this arrangement:  reduced delivery cost, improved quality of experience for EUs, bottlenecks avoided, and increased robustness of delivery. Thoughts?

 regards

 Xiaowei Qin 
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
----------------------------------------------------


Gmane