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

See below,

Gorry

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

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

> 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
>> >
>
>
> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf
>