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
> >