[tcmtf] TCM-TF: Path MTU

"Jose Saldana" <jsaldana@unizar.es> Fri, 27 September 2013 13:56 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 7AC1611E814F; Fri, 27 Sep 2013 06:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.277
X-Spam-Level:
X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, 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 1XBPq8BrsKJi; Fri, 27 Sep 2013 06:56:53 -0700 (PDT)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFE21F9D66; Fri, 27 Sep 2013 06:56:48 -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 r8RDuaH8007030; Fri, 27 Sep 2013 15:56:36 +0200
From: Jose Saldana <jsaldana@unizar.es>
To: "'Reinaldo Penno (repenno)'" <repenno@cisco.com>, tsv-area@ietf.org, tcmtf@ietf.org
Date: Fri, 27 Sep 2013 15:56:44 +0200
Organization: Universidad de Zaragoza
Message-ID: <00d801cebb89$6948b790$3bda26b0$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac67iGausLwrFaprRJeUtk1utH2csw==
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Subject: [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 13:56:59 -0000

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

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.

What do you think?

Jose