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

["Jose Saldana" <[e-mail]>]

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

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En nombre de
> [e-mail]
> Enviado el: miércoles, 12 de junio de 2013 18:33
> Para: [e-mail]
> CC: [e-mail]; [e-mail]; "'Mirko Su¾njeviæ"'""
> Asunto: 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: [e-mail] [mailto:[e-mail]] Enviado el:
> >> miércoles, 12 de junio de 2013 17:55
> >> Para: [e-mail]
> >> CC: [e-mail]; "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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/tcmtf
> >> >
> >
> >
> > _______________________________________________
> > tcmtf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> >
> 
> 
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf