Re: [tcmtf] BoF feedback
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 03 August 2013 09:12 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 A52AE11E8163 for <tcmtf@ietfa.amsl.com>;
Sat, 3 Aug 2013 02:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.568
X-Spam-Level:
X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 EuIckzd0vl-z for
<tcmtf@ietfa.amsl.com>; Sat, 3 Aug 2013 02:12:01 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by
ietfa.amsl.com (Postfix) with ESMTP id 0C55211E815F for <tcmtf@ietf.org>;
Sat, 3 Aug 2013 02:11:55 -0700 (PDT)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 579172B44B4;
Sat, 3 Aug 2013 10:11:54 +0100 (BST)
Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk
[139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id
73E852B439A for <tcmtf@ietf.org>; Sat, 3 Aug 2013 10:11:52 +0100 (BST)
Message-ID: <51FCC957.6000100@erg.abdn.ac.uk>
Date: Sat, 03 Aug 2013 11:11:51 +0200
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland,
No SC013683.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: tcmtf@ietf.org
References: <A5638BF5-0636-4277-B845-69252B131FD0@gigix.net>
<E721D8C6A2E1544DB2DEBC313AF54DE2241CFE0C@xmb-rcd-x02.cisco.com>
<009801ce9026$bc402340$34c069c0$@unizar.es>
In-Reply-To: <009801ce9026$bc402340$34c069c0$@unizar.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [tcmtf] BoF feedback
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Sat, 03 Aug 2013 09:12:05 -0000
Indeed, I suspect a separate draft on TCP/SCTP would be helpful. There are separate issues that emerge if this is important to consider. A separate draft could help capture the key issues, present experience of using this, results from implementation, etc. RFC 3449 already gives some guidance on compression methods for TCP return streams, especially the "compaction" approach, and section 5.3.3 hints at the problem of forming bursts of TCP segments. A separate document would also help divide the problem into activities where expertise can be focused. Gorry On 03/08/2013 10:52, Jose Saldana wrote: > Muthu, Luigi, > > Perhaps you are right. The inclusion of the TCP branch of the protocol > raised many objections. But perhaps if we remove that branch (or leave it > for further study), we can carry on with RTP/UDP/IP and UDP/IP flows. In > fact, RTP/UDP/IP is already a standard (RFC4170, 2005) and nobody objected. > At least we should replace ECRTP with ROHC in RFC4170. > > Another option would be to create a specific document about the things to > take into account when multiplexing TCP flows. Or perhaps this could be > included in the "TCM-TF recommendations" draft. > > Thanks, > > Jose > > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de > Muthu Arul Mozhi Perumal (mperumal) > Enviado el: viernes, 02 de agosto de 2013 22:25 > Para: Luigi Iannone; tcmtf@ietf.org > Asunto: Re: [tcmtf] BoF feedback > > TCMTF has clear and demonstrated benefits for VoIP and online gaming. > CRTP/ECRTP has already enjoyed some success in reducing VoIP bandwidth over > point-to-point WAN links, especially in those regions where access bandwidth > is considerably expensive. TCMFT is a natural extension that encompasses > better compression and tunneling technologies to achieve similar goals. > > The concerns raised during the BoF seemed in relation to generalizing it for > other kinds of traffic and TCP in particular. This generalization though > important (especially in the context of Internet of Things as echoed by > Michael Ramalho during the BoF) could probably be deferred for future work > (TCMTF2.0?) and the scope limited to VoIP and online gaming to begin with, > IMO. As we work through the limited scope, how (and how not) to apply it for > other kinds of traffic should become more clear, I think. > > Muthu > > |-----Original Message----- > |From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf > |Of Luigi Iannone > |Sent: Friday, August 02, 2013 4:05 PM > |To: tcmtf@ietf.org > |Subject: [tcmtf] BoF feedback > | > |Hi, > | > |I was thinking a little bit about the turn the BoF took yesterday, going a > bit off topic IMHO. > | > |At a certain point people were going to the mic to explain yet another > |scenario where TCMTF would not work or is not useful. > | > |It is obvious to me that such scenarios exist, but the goal of TCMTF > |is not to provide something that will be applied to all packets under a > certain size. > | > |It is also obvious to me that scenarios where TCMTF is beneficial exist > |as well. Goal of TCMTF should be to provide the right mechanism for those > scenarios. > | > |A key point to discuss in TCMTF is how we identify and select the flow > |we want to be multiplexed on a single compressed tunnel. > | > |All of this to say that we should not focus or scenarios where TCMTF > |doesn't help but rather to answer the following question: > | > |Are there scenarios and use cases where TCMTF provides benefits? > | > |The answer IMHO is YES so some work should be done. > | > |Just let me add that, before thinking how to encapsulate we should > |answer: How do we select the flows we want to encamp? > | > |So that we are sure that we do not touch traffic that will suffer because > of TCMTF. > | > |Just my thoughts after the BoF. > | > |ciao > | > |Luigi > | > | > |_______________________________________________ > |tcmtf mailing list > |tcmtf@ietf.org > |https://www.ietf.org/mailman/listinfo/tcmtf > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf >
- [tcmtf] BoF feedback Luigi Iannone
- Re: [tcmtf] BoF feedback Joe Touch
- Re: [tcmtf] BoF feedback Muthu Arul Mozhi Perumal (mperumal)
- Re: [tcmtf] BoF feedback Jose Saldana
- Re: [tcmtf] BoF feedback Gorry Fairhurst
- Re: [tcmtf] BoF feedback Luigi Iannone
- Re: [tcmtf] BoF feedback Spencer Dawkins
- Re: [tcmtf] BoF feedback Wesley Eddy
- Re: [tcmtf] BoF feedback Spencer Dawkins
- Re: [tcmtf] BoF feedback Jose Saldana
- Re: [tcmtf] BoF feedback Jose Saldana
- Re: [tcmtf] BoF feedback Spencer Dawkins