IETF Logo Mail Archive

Re: [tcmtf] BoF feedback

Wesley Eddy <wes@mti-systems.com> Mon, 05 August 2013 18:16 UTC

Return-Path: <wes@mti-systems.com>
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 1A6A121F944C for <tcmtf@ietfa.amsl.com>; Mon, 5 Aug 2013 11:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 xVG2fkI0kKKY for <tcmtf@ietfa.amsl.com>; Mon, 5 Aug 2013 11:16:11 -0700 (PDT)
Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14E21F9EC4 for <tcmtf@ietf.org>; Mon, 5 Aug 2013 11:16:10 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r75IG85S020045 for <tcmtf@ietf.org>; Mon, 5 Aug 2013 14:16:08 -0400
Received: (qmail 10111 invoked by uid 0); 5 Aug 2013 18:16:07 -0000
X-TCPREMOTEIP: 108.99.38.55
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@108.99.38.55) by 0 with ESMTPA; 5 Aug 2013 18:16:06 -0000
Message-ID: <51FFEBCB.5020201@mti-systems.com>
Date: Mon, 05 Aug 2013 14:15:39 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
References: <A5638BF5-0636-4277-B845-69252B131FD0@gigix.net> <E721D8C6A2E1544DB2DEBC313AF54DE2241CFE0C@xmb-rcd-x02.cisco.com> <009801ce9026$bc402340$34c069c0$@unizar.es> <51FCC957.6000100@erg.abdn.ac.uk> <3152C5BE-50E1-4A70-A655-ADDD56C77725@gigix.net> <51FFE8A8.6000401@gmail.com>
In-Reply-To: <51FFE8A8.6000401@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Luigi Iannone <ggx@gigix.net>, gorry@erg.abdn.ac.uk, tcmtf@ietf.org
Subject: Re: [tcmtf] BoF feedback
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: Mon, 05 Aug 2013 18:16:17 -0000

On 8/5/2013 2:02 PM, Spencer Dawkins wrote:
> 
> So, Martin and I were talking this morning, and a question came up that
> you folks might want to ponder, if you haven't already done so ...
> 
> Re: UDP/IP flows, the theory here would be to say that UDP/IP flows are
> more like RTP flows than TCP flows, so the concerns about TCP in TCM-TF
> don't apply, but the nice people in RTCWeb are defining their data
> channel over SCTP/DTLS/UDP, and my guess would be that their data
> channel would behave exactly like TCP for bulk transfers.
> 
> Have people already considered that?
> 


I think the answer is that instead of searching for particular
protocol layerings that could be harmed, the rules for invoking
TCMTF on a flow would be such that it only operates on things
that it is configured to (e.g. UDP to a game server IP and port),
and that it would "fail off" and not do anything for types of
flows that it isn't sure how to optimize, time release for, or
otherwise not break.

That should be the answer for TCP, UDP, SCTP, DCCP, SCTP over UDP,
etc etc etc.

-- 
Wes Eddy
MTI Systems

v2.23.0 | Report a Bug | By Email