R. Peon: = “application can sometimes send multiple packets with the same = message so that they have unique probability of loss (not correlated), = this is an application choice that needs to be known by a = tunnel.”

If there are people =
willing to write the specs *and* people =
are

also able to express =
interest in writing/deploying/selling code =
and

products that use those =
specs, then we should certainly be =
doing

this work in the =
IETF.

 This will =
allow:
- multiple vendor boxes to =
interoperate on different sides of a
  challenged network/link =
(currently this is beyond the state of
  the =
art!)
- simplified/standardized =
management of such boxes
- well-understood behavior =
profiles of such middleboxes and =
their
  protocols =
algorithms
 If the IETF does not do =
this work, then I don't believe any of =
those
three benefits/results are =
likely at all, and the (poor) status =
quo
will =
continue.
 <=
p class=3DMsoNormal> <=
p class=3DMsoNormal>Jose =

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: 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 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 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 X-Mailman-Approved-At: Wed, 12 Feb 2014 03:02:16 -0800 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" 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: 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" To: , References: <007101cf226a$8d4ff8e0$a7efeaa0$@unizar.es> In-Reply-To: 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" 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 Mon Feb 17 10:29:52 2014 Return-Path: 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 F21C61A03FB for ; Mon, 17 Feb 2014 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] 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 RRr1i7aaKaLp for ; Mon, 17 Feb 2014 10:29:48 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id AD5C11A0239 for ; Mon, 17 Feb 2014 10:29:48 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 67EB06010C; Mon, 17 Feb 2014 19:29:45 +0100 (CET) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 64A706010B; Mon, 17 Feb 2014 19:29:45 +0100 (CET) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: tcmtf@ietf.org Date: Mon, 17 Feb 2014 19:29:45 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201402171929.45227.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/lvwHXm2KAKTTdoB09tz7tuvar64 Cc: Brian Trammell Subject: [tcmtf] Draft agenda X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:29:51 -0000 Hi everybody, we uploaded a draft agenda for the BoF: https://datatracker.ietf.org/meeting/89/agenda/tcmtf/ We tried to keep the presentation time short such that we will have enough time for discussion. Please let us know, if you think there is something missing or if something needs to be changed. Brian & Mirja From nobody Tue Feb 18 00:39:23 2014 Return-Path: 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 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: 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/tcmtf/NsUczmc-QRpA2MpLk7kDRyYtraQ Cc: tcmtf@ietf.org, tsv-area@ietf.org Subject: Re: [tcmtf] Improvements in TCM-TF according to the received comments: Problem 2: Path MTU X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion 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:23 2014 Return-Path: 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 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> 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/tcmtf/XtS94h1ByDAercdHp18O_9uNfe0 Cc: tcmtf@ietf.org, tsv-area@ietf.org, 'Joe Touch' Subject: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion 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:56 2014 Return-Path: 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 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'" 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/tcmtf/HsntNawZ4c0fG5PBnVrti_QdVs0 Cc: tcmtf@ietf.org, tsv-area@ietf.org Subject: Re: [tcmtf] Using the concept of "latency budget" for TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:21:54 -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 >> >