Subject: [tcmtf] TCM-TF: Path MTU

From: "Jose Saldana" <[email-masked]>
Date: Fri, 27 Sep 2013 15:56:44 +0200

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

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 27 Sep 2013 14:11:41 +0000

On 9/27/13 6:56 AM, "Jose Saldana" <[email-masked]> wrote:

>(Š) 
> (Š)
>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

[RP] If you have a mix of large packets (close to MTU, no tunneling) and
small packets, that would cause reordering, no?

>not expired yet, but you are near the MTU, you'd better send the packet

[RP] Agree.

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 27 Sep 2013 16:50:51 +0200

> -----Mensaje original-----
> De: Reinaldo Penno (repenno) [mailto:[email-masked]]
> Enviado el: viernes, 27 de septiembre de 2013 16:12
> Para: [email-masked]; [email-masked]; [email-masked]
> Asunto: Re: TCM-TF: Path MTU
> 
> 
> 
> >[Jose] TCM is deployed inside the network (within a network segment),
> >and the end machines do not know that it is being deployed.
> >
> >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.
> 
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
> >