Subject: [tcmtf] A terminological question: "small-packet flows"

From: "Jose Saldana" <[email-masked]>
Date: Wed, 12 Jun 2013 15:10:37 +0200

Hi all.

Mirko and I are working on an improved version of the "TCMTF -
recommendations" document. Since TCMTF is not only suitable for real-time
services, but also for non real-time ones (M2M, flows of ACKs, instant
messaging), one possibility is using the term "small-packet flows".

The advantages are clear:

- It is more generic.

- It includes the characteristics of TCMTF-able packets:

- low payload-to-header ratio

- long-term flows

This term is also being used in some technical documents:
www.huawei.com/ilink/en/download/HW_193034. 

What do you think? Any other proposals?

Jose

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Jun 2013 08:34:13 -0700

On Jun 12, 2013, at 6:10 AM, Jose Saldana <[email-masked]> wrote:

> Hi all.
>  
> Mirko and I are working on an improved version of the “TCMTF – recommendations” document. Since TCMTF is not only suitable for real-time services, but also for non real-time ones (M2M, flows of ACKs, instant messaging), one possibility is using the term “small-packet flows”.

I agree TCMTF is suitable for small packets.  

But by saying "small packet flow", it implies that the *entire flow* has to be small packets for TCMTF to kick in.  But TCMTF is useful if the flow is a mix of small and large packets, and useful if the flow began with lots of large packets (TLS or SSH handshake followed by a file transfer, or an HTTP GET (with a 4KB cookie) followed by a file transfer).

I like the term "small-packet flows" and it is concise, but when initially defined it would be useful to explain the flow does not have to always be small packets for the lifetime of the flow.

-d

> This term is also being used in some technical documents:www.huawei.com/ilink/en/download/HW_193034.
>  
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: [email-masked]
Date: Wed, 12 Jun 2013 16:54:32 +0100

If you're talking about TCP ACKs RFC 3449 could be relevant.

Gorry

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 12 Jun 2013 18:03:18 +0200

You are right, Dan:

We are considering the use of a "period" policy, which sends a multiplexed
packet at the end of each interval. However, this policy should be combined
with a "MTU size limit" policy, which triggers the packet as soon as a "next
to MTU" multiplexed packet is sent, even if the period has not expired.

In addition, if a single packet is to be multiplexed, it will be better to
send it in its native form. We don't need the tunnel in that case.

So let's suppose we have identified a "small packet flow" and in a certain
moment it generates a burst of big packets. In that case, TCMTF still works.
If we use the "period+MTU size limit" policy, then big packets will be sent
alone as soon as they arrive to the multiplexer.

So, as you say, when initially defining "small-packet flows", it would be
useful to explain that the flow does not have to always be small packets for
the lifetime of the flow. We can say that in a "small-packet flow" the vast
majority of the packets are small.

Thanks!

Jose

De: [email-masked] [mailto:[email-masked]] En nombre de Dan
Wing
Enviado el: miércoles, 12 de junio de 2013 17:34
Para: [email-masked]
CC: [email-masked]; Mirko Sužnjević
Asunto: Re: [tcmtf] A terminological question: "small-packet flows"

Hi all.

But by saying "small packet flow", it implies that the *entire flow* has to
be small packets for TCMTF to kick in.  But TCMTF is useful if the flow is a
mix of small and large packets, and useful if the flow began with lots of
large packets (TLS or SSH handshake followed by a file transfer, or an HTTP
GET (with a 4KB cookie) followed by a file transfer).

I like the term "small-packet flows" and it is concise, but when initially
defined it would be useful to explain the flow does not have to always be
small packets for the lifetime of the flow.

-d

 

- It is more generic.

- long-term flows

This term is also being used in some technical documents:
<http://www.huawei.com/ilink/en/download/HW_193034>
www.huawei.com/ilink/en/download/HW_193034.

Jose

_______________________________________________
tcmtf mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tcmtf>
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 12 Jun 2013 18:20:18 +0200

Gorry,

Thanks for the suggestion.

Some ACK flows generate a lot of pps:

- A file download may easily generate 100 ACKs per second from a computer to
the file server.
- TCP-based games also generate ACKs (maybe 10 pps)

Which delays would impair an ACK flow, according to RFC 3449? The idea I
have in mind is using multiplexing periods between 50 and 100 ms.

There is another problem, related to TCP Friendly Rate Control (TFRC, RFC
5348): if you add too much delay, the throughput can be reduced. This idea
was suggested by Michael some weeks ago:
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00235.html

Thanks!

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]
> Enviado el: miércoles, 12 de junio de 2013 17:55
> Para: [email-masked]
> CC: [email-masked]; "Mirko Su¾njeviæ"
> > recommendations" document. Since TCMTF is not only suitable for
> > real-time services, but also for non real-time ones (M2M, flows of
> > ACKs, instant messaging), one possibility is using the term
"small-packet
> flows".

---

From: [email-masked]
Date: Wed, 12 Jun 2013 17:32:45 +0100

See below,

Gorry

> have in mind is using multiplexing periods between 50 and 100 ms.
RFC 3449 gives BCP guidance on how to manage compression of the TCP ACK
stream and things to do and things to avoid.

For example, you may well be aware that bunching ACKs by sending them all
in one burst **IS** likely something that would need to be examined in
detail, since this impacts the flow dynamics and can therefore modify the
congestion behaviour across the network.

I'm just suggesting that your charter should be clear about about the set
of topics the group is currently addressing (e.g. TCP changes) so that
people understand whether they support or have issues with the proposed
scope of the work.

> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00235.html
That's also true - but I am not sure Michael was actually talking about
looking at TFRC, more as I saw it, he was talking about the sort of  TCP
rate you should expect based on the throughput equation (i.e. as a
function of loss and RTT).

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 13 Jun 2013 10:47:07 +0200

Gorry,

Thanks for the suggestion. I have included it in the end of Paragraph 8 of
the charter draft v6:

8. As a counterpart of the bandwidth saving, TCMTF may add some delay and
jitter. This is not a problem for the services which are not sensitive to
delay. However, regarding delay-sensitive services, the Working Group will
also develop a document (TCMTF - recommendations) with useful
recommendations in order to decide which packet flows can or can not be
multiplexed and how. The document will present a list of available traffic
classification methods which can be used for identification of the service
or application to which a particular flow belongs, as well as
recommendations of the maximum delay and jitter to be added depending of the
identified service or application. The eventual impact of multiplexing on
protocol dynamics (e.g., when multiplexing TCP flows) will also have to be
addressed.

I think we should study this in the TCMTF - recommendations document. Do you
agree?

Thanks,

Jose

> De: [email-masked] [mailto:[email-masked]] En nombre de
> [email-masked]
> Enviado el: miércoles, 12 de junio de 2013 18:33
> Para: [email-masked]
> CC: [email-masked]; [email-masked]; "'Mirko Su¾njeviæ"'""
> > - A file download may easily generate 100 ACKs per second from a
> > computer to the file server.
> > Which delays would impair an ACK flow, according to RFC 3449? The idea
> > I have in mind is using multiplexing periods between 50 and 100 ms.
> >
of
> topics the group is currently addressing (e.g. TCP changes) so that people
> understand whether they support or have issues with the proposed scope of
> the work.
> 
> > 5348): if you add too much delay, the throughput can be reduced. This
> > idea was suggested by Michael some weeks ago:
looking
> at TFRC, more as I saw it, he was talking about the sort of  TCP rate you
> should expect based on the throughput equation (i.e. as a function of loss
> and RTT).
> 
> > Thanks!
> >
> > Jose
> >
> >> De: [email-masked] [mailto:[email-masked]] Enviado el:
> >> miércoles, 12 de junio de 2013 17:55
> >> Para: [email-masked]