On 5 Feb. 2014, at 13:06 , = Jose Saldana <jsaldana@unizar.es> = wrote:

Problem:

Gorry: Perhaps we = should also look at PMTU = issues?

In TCMTF? = I would avoid that. MTU is a common problem for any tunnelling = mechanism I would more support a =93tunnel-spefici-independent=94 = solution (probably to be discussed = elsewhere).

ciao

Al: Yes. The operations considerations = should be thought about.

Solution: (see = this thread: = http://www.ietf.org/mail-archive/web/tcmtf/current/msg00422.html)
=
The current = charter talks about MTU in number 7.

Jose =

______________________________________= _________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org/= mailman/listinfo/tcmtf

= --Apple-Mail=_AE1CA7E8-E472-4CFF-AEA0-9A18D34B9EEB-- From philip.eardley@bt.com Wed Feb 12 02:59:23 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322231A0947; Wed, 12 Feb 2014 02:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 lJxWJx4cXPUL; Wed, 12 Feb 2014 02:59:19 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 091AC1A092F; Wed, 12 Feb 2014 02:59:18 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 12 Feb 2014 10:59:19 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 12 Feb 2014 10:59:12 +0000 From: To: , Date: Wed, 12 Feb 2014 10:59:11 +0000 Subject: RE: BoF preparation: Improvements in TCM-TF according to the received comments Thread-Topic: BoF preparation: Improvements in TCM-TF according to the received comments Thread-Index: Ac8iaoBRyix1kdDRTtm12MWuQs1b5AFdRlGA Message-ID: References: <007101cf226a$8d4ff8e0$a7efeaa0$@unizar.es> In-Reply-To: <007101cf226a$8d4ff8e0$a7efeaa0$@unizar.es> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAA4584CEMV67UKRDdoma_" MIME-Version: 1.0 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:59:23 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAA4584CEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable << 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 i= s that the crucial issues are to make sure there is incremental benefit (th= e party migrating gets a benefit now and not when everyone else has migrate= d) and to try and ensure migration can be one party at a time (so others do= n't have to care - 'party' is most obviously one end host, but in some circ= umstances 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 questi= ons that have been discussed, in order to include the improvements in the c= harter 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 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAA4584CEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<< Conjoin= tly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT= congestion control mechanism offer a large number of services to applicati= ons 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 har= d>>

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. M= y take is that the crucial issues are to make sure there is incremental ben= efit (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 o= thers don’t have to care – ‘party’ is most obviousl= y one end host, but in some circumstances can be eg ‘Apple iOS’= ). There’s some quite nice stuff in RFC5218.

Best wishes

Phil

&= nbsp;

From: ts= v-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Saldana<= br>Sent: 05 February 2014 12:05
To: tcmtf@ietf.org
C= c: tsv-area@ietf.org
Subject: BoF preparation: Improvements i= n TCM-TF according to the received comments

Hi all,

On behalf of clarity, I will send different messages with th= e solutions for each problem.

If you think there are other problems, please start a new thre= ad.

&nb= sp;

Problems discussed= in the BoF:

1) = TCP multiplexing and effect on TCP dynamics. (I think this was the main pro= blem).

2) Path = MTU discovery issues

3) Are we adding latency and complexity to save relatively little ban= dwidth?

4) Do vendors want standar=
ds in this space?

Pr= oblems discussed in the list:

5) Wh=
y is ROHC not a solution?

Jose

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAA4584CEMV67UKRDdoma_-- From jsaldana@unizar.es Thu Feb 13 08:37:36 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@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" To: , References: <007101cf226a$8d4ff8e0$a7efeaa0$@unizar.es> In-Reply-To: Subject: RE: [tcmtf] BoF preparation: Improvements in TCM-TF according to the received comments 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 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:37:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0023_01CF28E2.20ADBA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, =20 Thanks for the ideas. =20 With the =93migration problem=94, do you mean that a TCM-TF tunnel = including a number of flows could be useful for connecting two =93domains=94 using = different protocols? =20 Thanks for the link to RFC5218. It contains good tips of advice. =20 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/ =20 De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de = philip.eardley@bt.com Enviado el: mi=E9rcoles, 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 =20 << 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>> =20 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=92t have to care =96 =91party=92 is most obviously one end host, but in some circumstances can be eg =91Apple iOS=92). There=92s some quite nice = stuff in RFC5218.=20 =20 Best wishes Phil =20 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 =20 Hi all, =20 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. =20 On behalf of clarity, I will send different messages with the solutions = for each problem. =20 If you think there are other problems, please start a new thread. =20 =20 Problems discussed in the BoF: =20 1) TCP multiplexing and effect on TCP dynamics. (I think this was the = main problem). =20 2) Path MTU discovery issues =20 3) Are we adding latency and complexity to save relatively little = bandwidth? =20 4) Do vendors want standards in this space? =20 =20 Problems discussed in the list: =20 5) Why is ROHC not a solution? =20 =20 Jose=20 =20 ------=_NextPart_000_0023_01CF28E2.20ADBA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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=E9rcoles, 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.or= g] 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 =

------=_NextPart_000_0023_01CF28E2.20ADBA50-- From nobody Fri Feb 14 01:10:08 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9A31A0125 for ; Fri, 14 Feb 2014 01:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 R-q_KGfxCnor for ; Fri, 14 Feb 2014 01:10:01 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 32AA51A0115 for ; Fri, 14 Feb 2014 01:10:01 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 14 Feb 2014 09:10:08 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.146]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 14 Feb 2014 09:09:58 +0000 From: To: , Date: Fri, 14 Feb 2014 09:09:57 +0000 Subject: Transport services BoF Thread-Topic: Transport services BoF Thread-Index: Ac8pZE1jHZgRHslUR9uU9CeZjqsCWA== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE983EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/PACCAe-cFrIbTWYUUhEabjdeYkI X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:10:07 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE983EMV67UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jose, all - sorry, (as I think you guessed!) my comment was about the trans= port services bof, not TCM-TF phil De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de philip.eardley@bt.co= m Enviado el: mi=E9rcoles, 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 th= e 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 i= s that the crucial issues are to make sure there is incremental benefit (th= e party migrating gets a benefit now and not when everyone else has migrate= d) and to try and ensure migration can be one party at a time (so others do= n't have to care - 'party' is most obviously one end host, but in some circ= umstances 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 questi= ons that have been discussed, in order to include the improvements in the c= harter 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 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE983EMV67UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jose, all – so= rry, (as I think you guessed!) my comment was about the transport services = bof, not TCM-TF

phil

= De:= tcmtf [mailto:tcmtf-bounces@ietf= .org] En nombre de phil= ip.eardley@bt.com
Enviado el: mi=E9rcoles, 12 de febrero de 2= 014 11:59
Para: jsaldana@un= izar.es; tcmtf@ietf.org
CC:= tsv-area@ietf.org
Asunt= o: 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 ap= plications in addition to the long-standing two services provided by TCP an= d UDP. For an application programmer, using protocols other than TCP or UDP= is hard>>
<= /p>
One thing I think would be useful is to analyse this as a mi= gration 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 incremen= tal benefit (the party migrating gets a benefit now and not when everyone e= lse has migrated) and to try and ensure migration can be one party at a tim= e (so others don’t have to care – ‘party’ is most o= bviously one end host, but in some circumstances can be eg ‘Apple iOS= ’). There’s some quite nice stuff in RFC5218.

Best wishes
Phil
<= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";color:blue'= >
<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f";mso-fareast-language:EN-GB'>From: tsv-area [mailto:tsv-area= -bounces@ietf.org] On Behalf Of Jose Saldana
Sent: 05 = February 2014 12:05
To: tcmtf@i= etf.org
Cc: tsv-area@iet= f.org
Subject: BoF preparation: Improvements in TCM-TF accord= ing to the received comments

Hi = all,
&n= bsp;
In order to = prepare the BoF in London, I have tried to summarize the questions that hav= e been discussed, in order to include the improvements in the charter and i= n the two drafts.

On behalf of clarity, I will send different messages with the solutions fo= r each problem.

I= f you think there are other problems, please start a new thread.=

Problems discussed in the BoF:

1) TCP multiplexin= g and effect on TCP dynamics. (I think this was the main problem).

2) Path MTU discovery iss= ues
&nb= sp;
3) Are we add= ing latency and complexity to save relatively little bandwidth?<= /span>

4) Do vendors want standards in this space?<= o:p>
= ;

Problems discussed i= n the list:
=
5) Why is ROHC not a = solution?
=

Jose

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40AAABE983EMV67UKRDdoma_-- From nobody Fri Feb 14 03:46:03 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584551A021B for ; Fri, 14 Feb 2014 03:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 DGhA1R_JXhmL for ; Fri, 14 Feb 2014 03:45:58 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id E314E1A0203 for ; Fri, 14 Feb 2014 03:45:57 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WEHDJ-0002cz-Qj; Fri, 14 Feb 2014 12:45:49 +0100 Received: from 1x-193-157-207-116.uio.no ([193.157.207.116]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WEHDJ-000697-3j; Fri, 14 Feb 2014 12:45:49 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: Transport services BoF From: Michael Welzl In-Reply-To: Date: Fri, 14 Feb 2014 12:45:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: philip.eardley@bt.com X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 6 sum msgs/h 2 total rcpts 12583 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.501, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 756E3381E4EB4A52A5A038E24129D24EBB7CA15F X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 193.157.207.116 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 28 max/h 4 blacklist 0 greylist 1 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/hFCQSEw2BEkn3LUoBJga45gG-9A Cc: "transport-services@ifi.uio.no" , tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 11:46:01 -0000 Hi, Indeed this discussion should probably take place at the = transport-services@ifi.uio.no mailing list - see https://sites.google.com/site/transportprotocolservices/ for more info =85 but I'll answer here anyway: there was this workshop arranged around RFC5218: http://www.iab.org/activities/workshops/itat/ where I presented, the slides are at: https://sites.google.com/site/transportprotocolservices/activities This is the short paper I had there, where I tried to make the point = regarding beneficial incremental deployment: = http://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_8.p= df =3D> it's about using the "best effort" model: you wish for more, but = live with less, potentially. At least that's one out of a few possible = ways ahead. As for who the "party" is: I think one possibility is to focus on user = space implementations for a while=85 e.g. see = http://tools.ietf.org/html/draft-hurtig-tsvwg-transport-apis =3D> one rather straightforward deployment path is to do an update of a = middleware like ZeroMQ to use different things than just TCP whenever = possible in some reasonable way. Since the main goal of TAPS is just to define the services and specify = examples, it's not limiting to only one way of implementing things - = from the point of view of "updating ZeroMQ", the RFCs that would come = out of a TAPS-WG would just serve as implementation guidance. Cheers, Michael On Feb 14, 2014, at 10:09 AM, philip.eardley@bt.com wrote: > Jose, all =96 sorry, (as I think you guessed!) my comment was about = the transport services bof, not TCM-TF > =20 > phil > =20 > De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de = philip.eardley@bt.com > Enviado el: mi=E9rcoles, 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 > =20 > << 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>> > =20 > 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=92t have to care =96 =91party=92 is most obviously = one end host, but in some circumstances can be eg =91Apple iOS=92). = There=92s some quite nice stuff in RFC5218. > =20 > Best wishes > Phil > =20 > 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 > =20 > Hi all, > =20 > 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. > =20 > On behalf of clarity, I will send different messages with the = solutions for each problem. > =20 > If you think there are other problems, please start a new thread. > =20 > =20 > Problems discussed in the BoF: > =20 > 1) TCP multiplexing and effect on TCP dynamics. (I think this was the = main problem). > =20 > 2) Path MTU discovery issues > =20 > 3) Are we adding latency and complexity to save relatively little = bandwidth? > =20 > 4) Do vendors want standards in this space? > =20 > =20 > Problems discussed in the list: > =20 > 5) Why is ROHC not a solution? > =20 > =20 > Jose > =20 From nobody Fri Feb 14 15:11:49 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B481A01E0 for ; Fri, 14 Feb 2014 15:11:46 -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 RWeKvUdL_Kxh for ; Fri, 14 Feb 2014 15:11:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 79A081A03C7 for ; Fri, 14 Feb 2014 15:11:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD53867; Fri, 14 Feb 2014 23:11:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 23:11:18 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 23:11:39 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 15:11:35 -0800 From: Linda Dunbar To: "tsv-area@ietf.org" Subject: Agenda for TSV area meeting in London 89th IETF Thread-Topic: Agenda for TSV area meeting in London 89th IETF Thread-Index: Ac8p2hsnmV5qv6fUQaSP00m2PDDXUQ== Date: Fri, 14 Feb 2014 23:11:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C8072E@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.147] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C8072Edfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/4pksAJZD5dQ11jPTGy5NQDy3DRc Cc: "tsv-ads@tools.ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:11:46 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C8072Edfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At London 89th IETF meeting, the TSV area meeting will be 9am~11:30am on Th= urs March 6 at Viscount. Here is the draft agenda: - TSV AD/NOMCOM (20 minutes) - ANRP talk - Keith Winstein -- (20 + 10 minutes) - How to train other protocol designers about UDP Design Considerations (10 + 20 minutes) - Foo over UDP tunneling discussion - what recommendations does TSV make (a= nd why)? (15 minutes) - New ideas about ECN (15 + 15 + 30 minutes) Linda (the secretary) --_000_4A95BA014132FF49AE685FAB4B9F17F645C8072Edfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At London 89^th IETF meeting, the TSV area= meeting will be 9am~11:30am on Thurs March 6 at Viscount.

Here is the draft agenda:

- TSV AD/NOMCOM (20 minutes)

- ANRP talk - Keith Winstein -- (20 + 10 minu= tes)

- How to train other protocol designers about UDP= Design Considerations

(10 + 20 minutes)

- Foo over UDP tunneling discussion - what recomm= endations does TSV make (and why)? (15 minutes)

- New ideas about ECN (15 + 15 + 30= minutes)

Linda (the secretary)

--_000_4A95BA014132FF49AE685FAB4B9F17F645C8072Edfweml701chmchi_-- From nobody Fri Feb 14 22:45:49 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4051A1A006A for ; Fri, 14 Feb 2014 22:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SuECVJQ3JqZo for ; Fri, 14 Feb 2014 22:45:45 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6CA1A0065 for ; Fri, 14 Feb 2014 22:45:45 -0800 (PST) Received: from [193.109.255.147:10921] by server-1.bemta-14.messagelabs.com id A7/D0-15438-61D0FF25; Sat, 15 Feb 2014 06:45:42 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1392446742!10707137!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17723 invoked from network); 15 Feb 2014 06:45:42 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 15 Feb 2014 06:45:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sat, 15 Feb 2014 06:45:41 +0000 From: To: , Date: Sat, 15 Feb 2014 06:44:56 +0000 Subject: RE: Agenda for TSV area meeting in London 89th IETF Thread-Topic: Agenda for TSV area meeting in London 89th IETF Thread-Index: Ac8p2hsnmV5qv6fUQaSP00m2PDDXUQAP1T7/ Message-ID: <290E20B455C66743BE178C5C84F1240847E6334719@EXMB01CMS.surrey.ac.uk> References: <4A95BA014132FF49AE685FAB4B9F17F645C8072E@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C8072E@dfweml701-chm.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/wQ7y-apVidoyY-WqCVmkqVQRdxE Cc: tsv-ads@tools.ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 06:45:48 -0000 yes 45 minutes in design and tunnelling should be just enough to cover UDP = checksum issues, and why zero checksum is a bad idea. Lloyd Wood http://about.me/lloydwood ________________________________________ From: tsv-area [tsv-area-bounces@ietf.org] On Behalf Of Linda Dunbar [linda= .dunbar@huawei.com] Sent: 14 February 2014 23:11 To: tsv-area@ietf.org Cc: tsv-ads@tools.ietf.org Subject: Agenda for TSV area meeting in London 89th IETF At London 89th IETF meeting, the TSV area meeting will be 9am~11:30am on Th= urs March 6 at Viscount. Here is the draft agenda: - TSV AD/NOMCOM (20 minutes) - ANRP talk - Keith Winstein -- (20 + 10 minutes) - How to train other protocol designers about UDP Design Considerations (10 + 20 minutes) - Foo over UDP tunneling discussion - what recommendations does TSV make (a= nd why)? (15 minutes) - New ideas about ECN (15 + 15 + 30 minutes) Linda (the secretary) From nobody Sun Feb 16 14:58:21 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08B61A02F7 for ; Sun, 16 Feb 2014 14:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 MF5fgQXImDWI for ; Sun, 16 Feb 2014 14:58:18 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 886851A0145 for ; Sun, 16 Feb 2014 14:58:18 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so23109965qcz.3 for ; Sun, 16 Feb 2014 14:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=56v39D0ffjZpX6FWbhw308uABcllJgFQ9+sKCyx9Njk=; b=SmbnprfSAHwlgUMIMIxIr4t+QSsvbGH7Zvm6nIVpb/ekxXwBC2ktEm55JyNCX1560G Gg+sGBBRvVe6cixDZGXZT2+LbrQ+1m2moBNfzUL+pwAWhn4pJOW1BAtYYgyRaeip5XkO MD+bqYPc7FtVLYuWNFjCJ+Uq8UucunIV1UFEFwIGSwGvhOugUME6cFuMmmk5dmU2cETa BmFEJY0YU0nF6PD6DfE7c1sg5qBa+hxn5jhzwwNFqO+sg46gYjuZ2LySeQrbVvb2rhyd 5HdnW6c7BnORvAdQOCYolbcxpc88A4nbS0+huMt8u6/FAFkYOjhxHLKY8bxVE+8Url/0 Z3FQ== MIME-Version: 1.0 X-Received: by 10.140.87.204 with SMTP id r70mr29082317qgd.23.1392591496151; Sun, 16 Feb 2014 14:58:16 -0800 (PST) Sender: bittau@gmail.com Received: by 10.224.198.5 with HTTP; Sun, 16 Feb 2014 14:58:16 -0800 (PST) Date: Sun, 16 Feb 2014 14:58:16 -0800 X-Google-Sender-Auth: wPViYKDwOfjU8_uqfnZZqAPkYe8 Message-ID: Subject: new tcpcrypt draft available From: Andrea Bittau To: tsv-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/o1bg0Bo5j1nfA2oTisIP6l90gCQ X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 22:58:20 -0000 Hi, For those interested, we posted a revised version of the tcpcrypt draft (opportunistic TCP encryption): http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt This will be discussed on Monday morning in tcpm, at the end of Session 1 (09:00--11:30). All comments are welcome, including any points that you'd like us to address in our presentation. thanks! From nobody Mon Feb 17 06:20:27 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE681A01FE for ; Mon, 17 Feb 2014 06:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KedBWGNw3p4v for ; Mon, 17 Feb 2014 06:20:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAA511A01D8 for ; Mon, 17 Feb 2014 06:20:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF36858; Mon, 17 Feb 2014 14:20:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 14:20:10 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 14:20:16 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 06:20:12 -0800 From: Linda Dunbar To: "l.wood@surrey.ac.uk" , "tsv-area@ietf.org" Subject: RE: Agenda for TSV area meeting in London 89th IETF Thread-Topic: Agenda for TSV area meeting in London 89th IETF Thread-Index: Ac8p2hsnmV5qv6fUQaSP00m2PDDXUQAP1T7/AHR3WAA= Date: Mon, 17 Feb 2014 14:20:11 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C80D9A@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C8072E@dfweml701-chm.china.huawei.com> <290E20B455C66743BE178C5C84F1240847E6334719@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E6334719@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/k_MrBTcEHnrPmcQhcYdpfYIA_Oo Cc: "tsv-ads@tools.ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:20:25 -0000 Lloyd,=20 Can you elaborate why zero checksum is bad on the email before the session = (to get people prepared)?=20 Linda -----Original Message----- From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk]=20 Sent: Saturday, February 15, 2014 12:45 AM To: Linda Dunbar; tsv-area@ietf.org Cc: tsv-ads@tools.ietf.org Subject: RE: Agenda for TSV area meeting in London 89th IETF yes 45 minutes in design and tunnelling should be just enough to cover UDP = checksum issues, and why zero checksum is a bad idea. Lloyd Wood http://about.me/lloydwood ________________________________________ From: tsv-area [tsv-area-bounces@ietf.org] On Behalf Of Linda Dunbar [linda= .dunbar@huawei.com] Sent: 14 February 2014 23:11 To: tsv-area@ietf.org Cc: tsv-ads@tools.ietf.org Subject: Agenda for TSV area meeting in London 89th IETF At London 89th IETF meeting, the TSV area meeting will be 9am~11:30am on Th= urs March 6 at Viscount. Here is the draft agenda: - TSV AD/NOMCOM (20 minutes) - ANRP talk - Keith Winstein -- (20 + 10 minutes) - How to train other protocol designers about UDP Design Considerations (10 + 20 minutes) - Foo over UDP tunneling discussion - what recommendations does TSV make (a= nd why)? (15 minutes) - New ideas about ECN (15 + 15 + 30 minutes) Linda (the secretary) From nobody Tue Feb 18 00:39:30 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B961A0454; Tue, 18 Feb 2014 00:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 yl7B1GXxxlL5; Tue, 18 Feb 2014 00:39:17 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id CAE481A0388; Tue, 18 Feb 2014 00:39:16 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s1I8cjCW011405; Tue, 18 Feb 2014 09:39:05 +0100 From: "Jose Saldana" To: "'Luigi Iannone'" References: <007b01cf226a$a41cc3a0$ec564ae0$@unizar.es> In-Reply-To: Subject: RE: [tcmtf] Improvements in TCM-TF according to the received comments: Problem 2: Path MTU Date: Tue, 18 Feb 2014 09:38:53 +0100 Message-ID: <00ef01cf2c84$e6724f30$b356ed90$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CF2C8D.48383DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXehMp81FSHWhIgWYyoPZ5krjLqALVRsfymRJuFAA= Content-Language: es Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/T4ajnp-jl55f8Qpt9a4U3npDauE Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 08:39:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F0_01CF2C8D.48383DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Luigi, In some research papers we have somewhat considered the problem of the MTU. I mean, let' suppose you have a high number of flows to be optimized together. Then, you define a period to multiplex them. But it may happen that, before ending the period, you have enough small packets so as to fill an MTU-sized multiplexed one. At that point, you should end that period, send the packet and start a new period. If you include a size threshold in addition to the period, the method is better. However, perhaps this is just an implementation issue. Do you think we should recommend this in the documents: - know the maximum MTU - use it in addition to the Period in order to trigger the sending of the multiplexed packet. Thanks! Jose De: Luigi Iannone [mailto:ggx@gigix.net] Enviado el: lunes, 10 de febrero de 2014 16:40 Para: Jose Saldana CC: tcmtf@ietf.org; tsv-area@ietf.org Asunto: Re: [tcmtf] Improvements in TCM-TF according to the received comments: Problem 2: Path MTU Hi, On 5 Feb. 2014, at 13:06 , Jose Saldana < jsaldana@unizar.es> wrote: Problem: Gorry: Perhaps we should also look at PMTU issues? In TCMTF? I would avoid that. MTU is a common problem for any tunnelling mechanism I would more support a "tunnel-spefici-independent" solution (probably to be discussed elsewhere). ciao L. Al: Yes. The operations considerations should be thought about. Solution: (see this thread: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00422.html) The current charter talks about MTU in number 7. Jose _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf ------=_NextPart_000_00F0_01CF2C8D.48383DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Luigi,

In some research papers we = have somewhat considered the problem of the MTU. I mean, let’ = suppose you have a high number of flows to be optimized together. Then, = you define a period to multiplex them. But it may happen that, before = ending the period, you have enough small packets so as to fill an = MTU-sized multiplexed one. At that point, you should end that period, = send the packet and start a new period. If you include a size threshold = in addition to the period, the method is better.

However, perhaps this is = just an implementation issue. Do you think we should recommend this in = the documents:
- know the maximum = MTU
- use it in addition to = the Period in order to trigger the sending of the multiplexed = packet.

Thanks!

Jose
<= p class=3DMsoNormal>
De: Luigi Iannone [mailto:ggx@gigix.net]
Enviado = el: lunes, 10 de febrero de 2014 16:40
Para: Jose = Saldana
CC: tcmtf@ietf.org; tsv-area@ietf.org
Asunto:= Re: [tcmtf] Improvements in TCM-TF according to the received comments: = Problem 2: Path = MTU

Hi,

On 5 Feb. 2014, at 13:06 , Jose Saldana = <jsaldana@unizar.es> = wrote:

Problem:

Gorry: Perhaps we should also look at PMTU = issues?
=
In TCMTF? = I would avoid that. MTU is a common problem for any tunnelling mechanism I would more support a = “tunnel-spefici-independent” = solution (probably to be discussed = elsewhere).
=
ciao
=
L.
=
=

Al: Yes. The operations considerations = should be thought about.

Solution: (see this thread: ht= tp://www.ietf.org/mail-archive/web/tcmtf/current/msg00422.html= )
The current charter talks about MTU in = number 7.

Jose

_________________= ______________________________
tcmtf = mailing list
tcmtf@ietf.org
https://www.ietf.= org/mailman/listinfo/tcmtf
=
------=_NextPart_000_00F0_01CF2C8D.48383DD0-- From nobody Tue Feb 18 00:45:26 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776F41A02FF; Tue, 18 Feb 2014 00:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H3gA3BzVynNC; Tue, 18 Feb 2014 00:45:20 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id E08DD1A009E; Tue, 18 Feb 2014 00:45:19 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s1I8jABn019449; Tue, 18 Feb 2014 09:45:10 +0100 From: "Jose Saldana" To: "'Luigi Iannone'" References: <007601cf231c$f7c78be0$e756a3a0$@unizar.es> <52F412AF.5030203@isi.edu> <006f01cf23e0$c926bf80$5b743e80$@unizar.es> <6692A7F3-1B2C-488C-93C4-5C4BE3F2E7C4@gigix.net> In-Reply-To: <6692A7F3-1B2C-488C-93C4-5C4BE3F2E7C4@gigix.net> Subject: RE: [tcmtf] Using the concept of "latency budget" for TCM-TF Date: Tue, 18 Feb 2014 09:45:20 +0100 Message-ID: <010301cf2c85$c1d97440$458c5cc0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPuVkuoGxnd6nNfAS2ET+wNDYJAwLz5ck/AR31gr8B4B6m1JqKB91A Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/oz-9zFHa4ef-0PIhbbhT_epCs_s Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 08:45:22 -0000 Sure. We have studied the effect of the added delay (and jitter) on different services: VoIP, games. We have even used subjective quality estimators in order to see the degradation as a function of the period. We can include some ideas in the second draft (Delay Limits and Multiplexing Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows, http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ Thanks, Jose PS: A paper about the effect on VoIP: Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Jenifer Murillo, Eduardo Viruete, Jose I. Aznar, "Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP Conversation Quality," Computer Networks (Elsevier), Volume 56, Issue 7, Pages 1893-1919, May 2012. doi 10.1016/j.comnet.2012.02.004 Another one about the effect on a game: Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Eduardo Viruete Navarro, Luis Casadesus, "Online FPS Games: Effect of Router Buffer and Multiplexing Techniques on Subjective Quality Estimators," Multimedia Tools and Applications, Springer. doi 10.1007/s11042-012-1309-4 > -----Mensaje original----- > De: Luigi Iannone [mailto:ggx@gigix.net] > Enviado el: lunes, 10 de febrero de 2014 16:38 > Para: Jose Saldana > CC: Joe Touch; tcmtf@ietf.org; tsv-area@ietf.org > Asunto: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF > > Hi, > > On 7 Feb. 2014, at 09:44 , Jose Saldana wrote: > > [snip] > > > > The only question that is different in TCM-TF is that we have to > > multiplex packets, so for certain services we must define a > > "multiplexing period" (the added delay is half the period in average). > > In this case, we can control this portion of the added delay. We can > > tune the period if the latency gets modified. > > > > Will this be documented in the documents produced by the WG? > > I mean, it would be useful to have something that describes performances > with different multiplexing period and may be a recommended setup > depending of the traffic type (e.g. gaming vs voip). > > What do you think? > > L. > > > > > This is why I thought that was interesting here: we can control and > > tune a part of the latency in this case. > > > >> > >> Joe > > > > Thanks! > > > > Jose > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf > From nobody Tue Feb 18 10:21:58 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03181A0438; Tue, 18 Feb 2014 10:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 lu7GDl0H3iaR; Tue, 18 Feb 2014 10:21:52 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 71B741A0408; Tue, 18 Feb 2014 10:21:52 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1IIKoeO019608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 10:20:50 -0800 (PST) Message-ID: <5303A483.3060406@isi.edu> Date: Tue, 18 Feb 2014 10:20:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jose Saldana , "'Luigi Iannone'" Subject: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF References: <007601cf231c$f7c78be0$e756a3a0$@unizar.es> <52F412AF.5030203@isi.edu> <006f01cf23e0$c926bf80$5b743e80$@unizar.es> <6692A7F3-1B2C-488C-93C4-5C4BE3F2E7C4@gigix.net> <010301cf2c85$c1d97440$458c5cc0$@unizar.es> In-Reply-To: <010301cf2c85$c1d97440$458c5cc0$@unizar.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/0-U_XDSm_iky3InDAOLjw8pkhnE Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:21:55 -0000 On 2/18/2014 12:45 AM, Jose Saldana wrote: > Sure. > > We have studied the effect of the added delay (and jitter) on different > services: VoIP, games. We have even used subjective quality estimators in > order to see the degradation as a function of the period. There's several decades of work - much of this ongoing - studying this effect. You might look into it and cite some of the existing understanding. > We can include some ideas in the second draft (Delay Limits and Multiplexing > Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows, > http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ AFAICT, this implies you assume that the HCI latency budget is yours to consume; you need to account for the rest of the system. Joe > > Thanks, > > Jose > PS: > A paper about the effect on VoIP: > > Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Jenifer Murillo, > Eduardo Viruete, Jose I. Aznar, "Evaluating the Influence of Multiplexing > Schemes and Buffer Implementation on Perceived VoIP Conversation Quality," > Computer Networks (Elsevier), Volume 56, Issue 7, Pages 1893-1919, May 2012. > doi 10.1016/j.comnet.2012.02.004 > > > Another one about the effect on a game: > > Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Eduardo Viruete > Navarro, Luis Casadesus, "Online FPS Games: Effect of Router Buffer and > Multiplexing Techniques on Subjective Quality Estimators," Multimedia Tools > and Applications, Springer. doi 10.1007/s11042-012-1309-4 > >> -----Mensaje original----- >> De: Luigi Iannone [mailto:ggx@gigix.net] >> Enviado el: lunes, 10 de febrero de 2014 16:38 >> Para: Jose Saldana >> CC: Joe Touch; tcmtf@ietf.org; tsv-area@ietf.org >> Asunto: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF >> >> Hi, >> >> On 7 Feb. 2014, at 09:44 , Jose Saldana wrote: >> >> [snip] >>> >>> The only question that is different in TCM-TF is that we have to >>> multiplex packets, so for certain services we must define a >>> "multiplexing period" (the added delay is half the period in average). >>> In this case, we can control this portion of the added delay. We can >>> tune the period if the latency gets modified. >>> >> >> Will this be documented in the documents produced by the WG? >> >> I mean, it would be useful to have something that describes performances >> with different multiplexing period and may be a recommended setup >> depending of the traffic type (e.g. gaming vs voip). >> >> What do you think? >> >> L. >> >> >> >>> This is why I thought that was interesting here: we can control and >>> tune a part of the latency in this case. >>> >>>> >>>> Joe >>> >>> Thanks! >>> >>> Jose >>> >>> _______________________________________________ >>> tcmtf mailing list >>> tcmtf@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcmtf >> > From nobody Fri Feb 28 01:06:35 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00421A06B7 for ; Fri, 28 Feb 2014 01:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 PcTDjEZW1w7o for ; Fri, 28 Feb 2014 01:06:32 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 72BBA1A0184 for ; Fri, 28 Feb 2014 01:06:32 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so306556wes.30 for ; Fri, 28 Feb 2014 01:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qpQEscj3BeUGikqGF+S8wk0JkuioW/jGHPGTT7k/CIU=; b=vZb4+QxJdnD4D6UWTyLiL3QgRD1hxXlnYkPTTIL8NiupdhWmX1mfGUXZWZe6uBhtFF kIq1zJi3GLYJ6n7oEBiLHwz7mmRfBHycAwT+MHkBCUHYugHC6lk0V968IwTZ0iTG65bw fC4lxI+3zBq8xfhpUFvPY7+OPQsPc5AkODdabioFBJcTsMrPtWWk072C+k1KWOGf/rFt ICIqLowW2gP+ahJkpugPj+fApfHMBrnAu86QNCGCSwPQyLlLP9A/z1O68SUjUc162nrH PT4vq4exwGeMYhW6MZetqBHC21g7JYMs44Tg/YNPxaI3EVIEAdWJ/m1iFlNpb6Hsdcuc pkBA== X-Received: by 10.180.207.10 with SMTP id ls10mr2292248wic.4.1393578389997; Fri, 28 Feb 2014 01:06:29 -0800 (PST) Received: from [10.1.1.139] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id n3sm3115914wix.10.2014.02.28.01.06.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 01:06:29 -0800 (PST) Message-ID: <53105193.7020803@gmail.com> Date: Fri, 28 Feb 2014 10:06:27 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tsv-area@ietf.org" Subject: Meet your Area Directors: TSV AD "office hours" at IETF-89 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tsv-area/Nac8taGdWpTl_eDPMx-UnlDxueQ X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 09:06:34 -0000 Hi there, This is the announcement of the TSV AD "office hours" at the IETF-89 meeting in London. The office hours are for the case there are things that you need to discuss with the Transport Area Directors in person and aren't able to pin us down any other time. The time slot reserved for the office hours is Thursday, March 6, from 11:45 am to 12:45 pm. The room will be announced soon. Please let us know in advance if you are planning to meet us, so that we can plan a bit ahead. Thanks, Spencer & Martin