Re: [tcmtf] TCM-TF: Path MTU
"Jose Saldana" <jsaldana@unizar.es> Fri, 27 September 2013 14:51 UTC
Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3921F9703; Fri, 27 Sep 2013 07:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.531
X-Spam-Level:
X-Spam-Status: No, score=-5.531 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKvG683NJ6WU; Fri, 27 Sep 2013 07:50:59 -0700 (PDT)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id E9ABF21F9D7C; Fri, 27 Sep 2013 07:50:55 -0700 (PDT)
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 r8REohQu008990; Fri, 27 Sep 2013 16:50:43 +0200
From: Jose Saldana <jsaldana@unizar.es>
To: "'Reinaldo Penno (repenno)'" <repenno@cisco.com>, tsv-area@ietf.org, tcmtf@ietf.org
References: <00d801cebb89$6948b790$3bda26b0$@unizar.es> <45A697A8FFD7CF48BCF2BE7E106F06040B6E9D71@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B6E9D71@xmb-rcd-x04.cisco.com>
Date: Fri, 27 Sep 2013 16:50:51 +0200
Organization: Universidad de Zaragoza
Message-ID: <00e201cebb90$f66d3540$e3479fc0$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFjK2R8LreIbggnmzfUdkoGE13ykpqwyljw
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Subject: Re: [tcmtf] TCM-TF: Path MTU
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: jsaldana@unizar.es
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 14:51:05 -0000
> -----Mensaje original----- > De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > Enviado el: viernes, 27 de septiembre de 2013 16:12 > Para: jsaldana@unizar.es; tsv-area@ietf.org; tcmtf@ietf.org > Asunto: Re: TCM-TF: Path MTU > > > > On 9/27/13 6:56 AM, "Jose Saldana" <jsaldana@unizar.es> wrote: > > >Just my opinion about the MTU problem when TCM-optimizing: > > > > > >(Š) > >>>>>3) Path MTU discovery issues > > > >>>>[RP] Very important issue. There are some gaming consoles that > >>>>just by > >putting their packets in a lightweight UDP tunnel you get a message > >>>>saying you have MTU issues and everything stops. Debugging is up to > >>>>the > >user. > > > >>>[Jose] Which game genre are you talking about? Perhaps this only > >>>happens > >when the console is sending MTU packets. Real-time games usually send > >>> very small ones, but this is a very interesting topic we have to study. > > > >>[RP2] The console itself (not a game) does MTU probing. If there is a > >>MTU > >problem you get a network error. > > > > (Š) > > > >[Jose] TCM is deployed inside the network (within a network segment), > >and the end machines do not know that it is being deployed. > > > >TCM only makes sense for small-packet flows. > > [RP] Yes, but how TCM would know that before hand about the flow ? Is that > a run time decision based on packet size inspection? > > >Obviously, a TCM optimizer will > >not multiplex packets if they are big. Those packets will travel in > >their native form, and the tunnel is not required. So if a console does > >that test, a good TCM implementation should not do anything. > > [RP] If you have a mix of large packets (close to MTU, no tunneling) and small > packets, that would cause reordering, no? > [Jose] Yep. If an application generates big and small packets, they could arrive reordered at the end machine. Perhaps we should also take this into account in the "recommendations draft": only optimizing flows that generate small (and no big) packets. Currently we are considering those kinds of flows in fact. > > > >There is another question: we are talking about multiplexing based on a > >time period. However, the MTU is another limitation. I mean, if the > >period has not expired yet, but you are near the MTU, you'd better send > >the packet and begin a new period. > > [RP] Agree. > > > > >What do you think? > > > >Jose > >
- [tcmtf] TCM-TF: Path MTU Jose Saldana
- Re: [tcmtf] TCM-TF: Path MTU Reinaldo Penno (repenno)
- Re: [tcmtf] TCM-TF: Path MTU Jose Saldana