Re: [tcmtf] Next steps with TCM-TF

Manuel Gorius <gorius@nt.uni-saarland.de> Tue, 17 September 2013 00:21 UTC

Return-Path: <gorius@nt.uni-saarland.de>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0511E8168 for <tcmtf@ietfa.amsl.com>; Mon, 16 Sep 2013 17:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa7et-bMLT9h for <tcmtf@ietfa.amsl.com>; Mon, 16 Sep 2013 17:21:24 -0700 (PDT)
Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8B11E8160 for <tcmtf@ietf.org>; Mon, 16 Sep 2013 17:21:19 -0700 (PDT)
Received: from com.intel-vci.uni-saarland.de (com.intel-vci.uni-saarland.de [134.96.18.58]) by triton.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id r8H0LD49032103; Tue, 17 Sep 2013 02:21:13 +0200
Received: from localhost (localhost [127.0.0.1]) by com.intel-vci.uni-saarland.de (Postfix) with ESMTP id BD41D972001; Tue, 17 Sep 2013 02:21:13 +0200 (CEST)
Received: from com.intel-vci.uni-saarland.de ([127.0.0.1]) by localhost (com.intel-vci.uni-saarland.de [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id V0Q8asonb4WG; Tue, 17 Sep 2013 02:21:10 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by com.intel-vci.uni-saarland.de (Postfix) with ESMTP id 8705B972002; Tue, 17 Sep 2013 02:21:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at intel-vci.uni-saarland.de
Received: from com.intel-vci.uni-saarland.de ([127.0.0.1]) by localhost (com.intel-vci.uni-saarland.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id okyageT-bKPj; Tue, 17 Sep 2013 02:21:10 +0200 (CEST)
Received: from com.intel-vci.uni-saarland.de (localhost [127.0.0.1]) by com.intel-vci.uni-saarland.de (Postfix) with ESMTP id 5096E972001; Tue, 17 Sep 2013 02:21:10 +0200 (CEST)
Date: Tue, 17 Sep 2013 02:21:10 +0200
From: Manuel Gorius <gorius@nt.uni-saarland.de>
To: jsaldana@unizar.es
Message-ID: <917683638.212231.1379377270245.JavaMail.zimbra@nt.uni-saarland.de>
In-Reply-To: <00ec01ceafbc$692c5ab0$3b851010$@unizar.es>
References: <017d01cead79$25240a10$6f6c1e30$@unizar.es> <AA275F59-30E3-4671-B1A5-3E808DC73EE0@nt.uni-saarland.de> <002d01ceae30$0e3460e0$2a9d22a0$@unizar.es> <EE48F51E-FFCF-4ADD-9C34-B4E131834844@nt.uni-saarland.de> <00ec01ceafbc$692c5ab0$3b851010$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [192.55.60.72]
X-Mailer: Zimbra 8.0.4_GA_5739 (zclient/8.0.4_GA_5739)
Thread-Topic: Next steps with TCM-TF
Thread-Index: AQHuvPs5z3YNAt6hhH28PKho2tIgMgDdQFaPAxTcTRUBRZLleJlYOgnwsFl5IMk=
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Tue, 17 Sep 2013 02:21:14 +0200 (CEST)
X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.99.164; host: AntiVir3)
Cc: tcmtf@ietf.org
Subject: Re: [tcmtf] Next steps with TCM-TF
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 00:21:38 -0000

Hi Jose,

Indeed the efficiency of the proposed error control scheme increases for higher data rates. I was assuming that the multiplexing of several flows would result in a reasonably high rate. The mechanisms deployed in our protocol, however, also scale down to lower rates. 

My idea after reading the notes taken during the BoF session was that this scheme could provide transparent error control on the multiplexed link segment so as to mitigate the impact of lost aggregated frames on ent-to-end error control of higher layers. I think delay-constrained error control is essential for those multiplexed flows. Simple, reactive packet repetitions might induce too much of unpredictable latency.

Best regards,
Manuel


----- Ursprüngliche Mail -----
Von: Jose Saldana <jsaldana@unizar.es>
An: 'Manuel Gorius' <gorius@nt.uni-saarland.de>
CC: tcmtf@ietf.org
Gesendet: Thu, 12 Sep 2013 15:31:38 +0200 (CEST)
Betreff: Re: [tcmtf] Next steps with TCM-TF

Hi, Manuel.

 

I have been reading some of your papers. This is the idea I have got:

 

- You have proposed and implemented a new transport protocol (Predictably
Reliable Realtime Transport protocol, PRRT), which would be useful for
providing the reliability required by multimedia services under their
specific delay constraint.

 

- It is "designed for high-rate and low-latency media services over lossy
network infrastructures".

 

- So the first use is video transmission, I think.

 

 

Can some of the ideas be useful for TCM-TF?

 

As a first question, TCM-TF can only optimize small-packet flows (VoIP,
online games, sensor networks, M2M), which usually have low bandwidth
requirements, and at the same time require low latency.

 

So the considered services are not the same.

 

You talk about "the question of transport reliability for such multiplexed
packet flows". So, are you proposing the possibility of using some of these
ideas for improving the reliability of multiplexed flows?

 

Thanks!

 

Jose

 

De: Manuel Gorius [mailto:gorius@nt.uni-saarland.de] 
Enviado el: martes, 10 de septiembre de 2013 17:08
Para: jsaldana@unizar.es
CC: tcmtf@ietf.org
Asunto: Re: [tcmtf] Next steps with TCM-TF

 

Jose, Thank you for your interest. We had set up a project website providing
literature and a Linux kernel module implementing our "Predictably Reliable
Real-time Protocol": 

http://www.nt.uni-saarland.de/en/projects/running-projects/prrt.html

 

For a quick technical overview I'd like to point you on a poster
presentation available under: 

http://www.nt.uni-saarland.de/fileadmin/file_uploads/projects/prrt/PRRT_Post
er.pdf

 

Please let me know if any of the implemented ideas are suitable for the
TCM-TF.

 

Best regards,

 Manuel

 

On 10.09.2013, at 16:14, "Jose Saldana" <jsaldana@unizar.es> wrote:





Manuel,

 

It sounds good. Could you please provide the link to some documentation
(e.g. a paper, a report) about the "predictably reliable" error control
scheme?

 

Thanks!

 

Jose

 

De: Manuel Gorius [mailto:gorius@ <http://nt.uni-saarland.de> nt.uni-sa
<http://nt.uni-saarland.de> arland.de] 
Enviado el: martes, 10 de septiembre de 2013 14:30
Para: <mailto:jsaldana@unizar.es> jsaldana@unizar.es
CC: <mailto:tcmtf@ietf.org> tcmtf@ietf.org
Asunto: Re: [tcmtf] Next steps with TCM-TF

 

Dear Jose,

 

It was nice to follow the ideas brought up during the TCM-TF BoF. I think
that a related standard might become important in near future since besides
online gaming there is also a plenty of upcoming interactive and sensor
applications that would be sending small parameter updates (think of smart
factory applications for instance or even e-health services). I highly
appreciate the decision to move the focus away from TCP. Given TCP's limited
efficiency for interactive applications, the concerns of potential impact on
its performance should not put an innovation bottleneck in front of new
ideas improving transport efficiency.

 

During the BoF session the question of transport reliability for such
multiplexed packet flows was raised. This would be a point where our lab
could contribute. We developed a "predictably reliable" error control scheme
that operates under strict delay constraints. The scheme would particularly
benefit from the larger packets and the higher aggregate data rate of the
multiplexed packet flows. If such error control would be considered
beneficial in TCM-TF, I'd be happy to become active.

 

Best regards,

 Manuel Gorius

 

On 09.09.2013, at 18:25, Jose Saldana < <mailto:jsaldana@unizar.es>
jsaldana@unizar.es> wrote:






Dear all,

 

As you may know, we had a TCM-TF BoF in IETF87 Berlin (
<http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf>
http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf).

 

As a result of the BoF, it was clear (IMHO) that there is some interest on
the topic. There were a number of people who thought that a WG should be
created, and several people also volunteered for reviewing documents.

 

However, in the BoF it was also clear that there are some concerns that have
to be issued before chartering. The main one is the interaction between TCM
optimization and TCP mechanisms. Since TCP controls its rate depending on
the RTT, the addition of a multiplexing delay may modify and even harm TCP
behavior.

 

As a consequence, we are going to redefine the Charter, removing the
optimization of TCP. So RTP/UDP and UDP will be the considered options for
optimization.

 

We would like to get more people involved in the discussion, so we would
like to invite those who actively participate on Transport Area discussion
to join the mailing list <https://www.ietf.org/mailman/listinfo/tcmtf>
https://www.ietf.org/mailman/listinfo/tcmtf, in order to get their feedback.

 

Thanks in advance,

 

Jose Saldana

_______________________________________________
tcmtf mailing list
 <mailto:tcmtf@ietf.org> tcmtf@ietf.org
 <https://www.ietf.org/mailman/listinfo/tcmtf>
https://www.ietf.org/mailman/listinfo/tcmtf

 

_______________________________________________
tcmtf mailing list
 <mailto:tcmtf@ietf.org> tcmtf@ietf.org
 <https://www.ietf.org/mailman/listinfo/tcmtf>
https://www.ietf.org/mailman/listinfo/tcmtf