Re: [tcmtf] BoF preparation: Improvements in TCM-TF according to the received comments

"Jose Saldana" <jsaldana@unizar.es> Thu, 13 February 2014 16:37 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9421A033B; Thu, 13 Feb 2014 08:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSuuPb7_hXyi; Thu, 13 Feb 2014 08:37:32 -0800 (PST)
Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB41A0371; Thu, 13 Feb 2014 08:36:45 -0800 (PST)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s1DGaPqc007592; Thu, 13 Feb 2014 17:36:26 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: <philip.eardley@bt.com>, <tcmtf@ietf.org>
References: <007101cf226a$8d4ff8e0$a7efeaa0$@unizar.es> <A2E337CDB7BC4145B018B9BEE8EB3E0D40AAA4584C@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To: <A2E337CDB7BC4145B018B9BEE8EB3E0D40AAA4584C@EMV67-UKRD.domain1.systemhost.net>
Date: Thu, 13 Feb 2014 17:36:28 +0100
Message-ID: <002201cf28d9$bee7cbb0$3cb76310$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CF28E2.20ADBA50"
X-Mailer: Microsoft Outlook 14.0
Content-language: es
Thread-index: AQI6CeT4IDFaGdsww7592SxpMtbs7AJ9QgoCmcm0iDA=
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: tsv-area@ietf.org
Subject: Re: [tcmtf] BoF preparation: Improvements in TCM-TF according to the received comments
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 13 Feb 2014 16:37:36 -0000

Phil,
 
Thanks for the ideas.
 
With the “migration problem”, do you mean that a TCM-TF tunnel including a
number of flows could be useful for connecting two “domains” using different
protocols?
 
Thanks for the link to RFC5218. It contains good tips of advice.
 
Jose
PS: Regarding SCTP, DCCP, TCP, UDP, etc., a BoF proposing an API that would
automatically select the best one for an application is being held in London
(Transport Services)
https://sites.google.com/site/transportprotocolservices/
 
De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de philip.eardley@bt.com
Enviado el: miércoles, 12 de febrero de 2014 11:59
Para: jsaldana@unizar.es; tcmtf@ietf.org
CC: tsv-area@ietf.org
Asunto: Re: [tcmtf] BoF preparation: Improvements in TCM-TF according to the
received comments
 
<< Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and
the LEDBAT congestion control mechanism offer a large number of services to
applications in addition to the long-standing two services provided by TCP
and UDP. For an application programmer, using protocols other than TCP or
UDP is hard>>
 
One thing I think would be useful is to analyse this as a migration problem.
I know lots of people have thought about why migration is hard. My take is
that the crucial issues are to make sure there is incremental benefit (the
party migrating gets a benefit now and not when everyone else has migrated)
and to try and ensure migration can be one party at a time (so others don’t
have to care – ‘party’ is most obviously one end host, but in some
circumstances can be eg ‘Apple iOS’). There’s some quite nice stuff in
RFC5218. 
 
Best wishes
Phil
 
From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Saldana
Sent: 05 February 2014 12:05
To: tcmtf@ietf.org
Cc: tsv-area@ietf.org
Subject: BoF preparation: Improvements in TCM-TF according to the received
comments
 
Hi all,
 
In order to prepare the BoF in London, I have tried to summarize the
questions that have been discussed, in order to include the improvements in
the charter and in the two drafts.
 
On behalf of clarity, I will send different messages with the solutions for
each problem.
 
If you think there are other problems, please start a new thread.
 
 
Problems discussed in the BoF:
 
1) TCP multiplexing and effect on TCP dynamics. (I think this was the main
problem).
 
2) Path MTU discovery issues
 
3) Are we adding latency and complexity to save relatively little bandwidth?
 
4) Do vendors want standards in this space?
 
 
Problems discussed in the list:
 
5) Why is ROHC not a solution?
 
 
Jose