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

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: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]
> Enviado el: miércoles, 12 de junio de 2013 17:55
> Para: jsaldana@unizar.es
> CC: tcmtf@ietf.org; "Mirko Su¾njeviæ"
> Asunto: Re: [tcmtf] A terminological question: "small-packet flows"
> 
> If you're talking about TCP ACKs RFC 3449 could be relevant.
> 
> Gorry
> 
> > 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
> >
> >
> >
> > _______________________________________________
> > tcmtf mailing list
> > tcmtf@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcmtf
> >