Re: [tcmtf] BoF feedback

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Mon, 05 August 2013 18:03 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 49F9E21F9DF6 for <tcmtf@ietfa.amsl.com>; Mon, 5 Aug 2013 11:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 KSK3cc1kD8rx for <tcmtf@ietfa.amsl.com>; Mon, 5 Aug 2013 11:03:19 -0700 (PDT)
Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5897F21F9DFA for <tcmtf@ietf.org>; Mon, 5 Aug 2013 11:03:19 -0700 (PDT)
Received: by mail-oa0-f42.google.com with SMTP id i18so7093235oag.29 for <tcmtf@ietf.org>; Mon, 05 Aug 2013 11:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KZJUXc/AJgA59KztGmKy/xxThvWvwd99Vywa1fWdjFw=; b=EuoESPkC/KHYjamMWQ5DrIthDND/OuKkYBtI0x6V07j254TLTC1VGcrL+8kSIv0y7I bHlgbfDq98sQ8L8nKMDGyd0O33OXtwJqnF9nEORXWs5+lZpBnt832YjWCeEeElPHwj1d HtrliZg/BltbzfMTAHL2mBwglms/nsfQLFKN5qT278eFy5NWXZNHee03buXaITKmDCHo RN8HslZ3TrY7D8zXoapRtaW34LwOX6umhQ4Ocmt80KL/+6KvdGtWj00KVPVVQfSQ+d69 8zj0k37iYKXGYc5jrUGX9wQ5l/uDmpb6llh/bh693xKiAY6+HdYVptXVFJWTZorivDiJ LI1Q==
X-Received: by 10.42.68.75 with SMTP id w11mr865940ici.117.1375725797715; Mon, 05 Aug 2013 11:03:17 -0700 (PDT)
Received: from [192.168.0.23] (173-97-116-174.pools.spcsdns.net. [173.97.116.174]) by mx.google.com with ESMTPSA id r6sm137991igp.8.2013.08.05.11.03.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 11:03:16 -0700 (PDT)
Message-ID: <51FFE8A8.6000401@gmail.com>
Date: Mon, 05 Aug 2013 13:02:16 -0500
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Luigi Iannone <ggx@gigix.net>
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>
In-Reply-To: <3152C5BE-50E1-4A70-A655-ADDD56C77725@gigix.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 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:03:20 -0000

Way down in the thread ...

On 8/5/2013 8:28 AM, Luigi Iannone wrote:
> Hi,
>
> I also support the creation of a different document for TCP/SCTP.
>
> As Gorry points out, this would help  to separate the issues. I think that on this side there is much more work to do in understanding where and how TCMTF can be applied.
>
> Work on RTP/UDP/IP can advance faster since there are already clear scenarios.
>
> I would also re-iterate my point of view. To be blunt I do not believe in a "generalised" use of TCMTF, yet I believe that there are strong benefits (already demonstrated) in various scenarios. So, IMHO, TCMTF should provide the community with the right set of tools to take advantage of those benefits.
>
> ciao
>
> Luigi
>
>
> On 3 Aug. 2013, at 11:11 , Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
>> 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.

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?

Thanks,

Spencer