Hi, Reinaldo. > -----Mensaje original----- > De: Reinaldo Penno (repenno) [mailto:repe...@cisco.com] > Enviado el: miércoles, 20 de noviembre de 2013 19:41 > Para: jsald...@unizar.es; tc...@ietf.org; tsv-area@ietf.org > CC: Martin Stiemerling; 'Spencer Dawkins' > Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft > > Hi, > > Some comments: (...) > * "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². My first reaction would be to not try to list > available classification methods since it will get into implementation > details. And what if traffic is e2e encrypted? Given the whole surveillance > thing should we we can expect this to happen? How would you know a flow > is candidate or suitable for compression?
One question about this. Our idea is to list some possibilities to be used for a TCM optimizer in order to select the flows to optimize. Some examples: - DPI. However, some people would say that it is against network neutrality, and it may also be difficult if the flow is encrypted. - Selecting according to IPs and port numbers. For example, if a flow has a destination IP belonging to a game company, it is a clear candidate. This would be possible if there is an agreement between the ISP and the game company. - The packets include specific diffserv values. - Automatic detection based on statistics of Inter-packet time and packet size have also been proposed. They are not against neutrality: T. T. Nguyen, G. Armitage, P. Branch, S. Zander, Timely and continuous machine-learning-based classification for interactive IP traffic, IEEE/ACM Trans. on Networking, 20(6), pp 1880-1894, 2012. What do you think about these possibilities? Thanks, Jose > * I wonder if some of the possible scenarios really apply. It seems we are > throwing everything to see what sticks. Example: Journalist covering the a > cycling competition do not need write their report real time. And if they > need to do a interview, it seems to be working well right now, HD and > everything. > * "- an agreement between two network operators could allow them to > compress a number of flows they are exchanging between a pair of Internet > Routers². Not sure compressing flows between peering routers is a good > use-case. > > > On 11/20/13, 3:13 AM, "Jose Saldana" <jsald...@unizar.es> wrote: > > >TCM-TF charter draft v8 > > > >Description of Working Group > > > >1. In the last years we are witnessing the raise of new real-time > >services that use the Internet for the delivery of interactive > >multimedia > >applications: VoIP, videoconferencing, telemedicine, video vigilance, > >online gaming, etc. Due to the need of interactivity, many of these > >services use small packets (some tens of bytes), since they have to > >send frequent updates between the extremes of the communication. In > >addition, some other services also send small packets, but they are not > >delay-sensitive (e.g., instant messaging, m2m packets sending collected > >data in sensor networks using wireless or satellite scenarios). For > >both the delay-sensitive and delay-insensitive applications, their > >small data payloads incur significant overhead, and it becomes even > >higher when IPv6 is used, since the basic > >IPv6 > >header is twice the size of the IPv4 one. > > > >2. The efficiency cannot be increased by the inclusion of a higher > >number of samples in a single packet, since this would harm the delay > >requirements of the service. But there exist some scenarios in which a > >number of flows share the same path. In this case, packets belonging to > >different flows can be grouped together, adding a small multiplexing > >delay as a counterpart of bandwidth saving. This delay will have to be > >maintained under some threshold in order to grant the delay > >requirements. Some examples of the scenarios where grouping packets is > >possible are: > > > >- aggregation networks of a network operator; > >- an end-to-end tunnel between appliances located in two different > >offices of the same company; > >- the access connection of an Internet Café including a high number of > >VoIP/gaming flows; > >- an agreement between two network operators could allow them to > >compress a number of flows they are exchanging between a pair of > >Internet Routers; > >- a wireless Internet connection shared by a number of people in a > >place with low Internet penetration > >- a community network, in which a number of people in the same > >geographical place share their connections in a cooperative way > >- a satellite connection used for collecting the data of a high number > >of sensors. > >- a satellite connection used for providing connectivity in a > >non-connected area during a short period of time (e.g. journalists > >covering the arrival of a mountain stage of a cycling competition). > >- an air-to-ground connection providing Internet connectivity to the > >passengers of an aircraft, multiplexing a number of simultaneous VoIP > >flows. > >The same can be applied between a cruise ship and a satellite. > > > >3. VoIP using RTP is a clear example of a real-time service using small > >packets with high overhead. In order to improve efficiency, RFC4170 > >(TCRTP) > >defined a method for grouping packets when a number of flows share a > >path, considering three different layers: header compression by means > >of ECRTP; multiplexing by means of PPPMux; tunneling by means of > L2TPv3. > > > >4. However, in the last years, emerging real-time services which do not > >use UDP/RTP have become popular: some of them use UDP. In addition, > new > >header compression methods have been defined (ROHC). So there is a > need > >of widening the scope of RFC4170 in order to consider not only UDP/RTP > >but also other protocols. The same structure of three layers will be > >considered: > > > >- Header compression: Taking into account that real-time applications > >use different headers (RTP/UDP, UDP), different protocols can be used: > >no compression, ECRTP, IPHC and ROHC. > >- Multiplexing: If a number of flows share a path between an origin and > >a destination, a TCM-optimizer (called TCM-ingress optimizer) can build > >a bigger multiplexed packet in which a number of payloads share a > >common header. Another TCM-optimizer (called TCM-egress optimizer) is > >then necessary at the end of the common path, so as to rebuild the > >packets as they were originally sent. PPPMux will be the main option. > >Other ones are not discarded. > >- Tunneling will be used to send the multiplexed packets end-to-end. > >The options in this layer are L2TP, GRE and MPLS. > > > >5. So the first objective of this group is to specify the protocol > >stack for tunneling, compressing and multiplexing traffic flows > >(TCM-TF). Since standard protocols are being used at each layer, the > >signaling methods of those protocols will be used. Interactions with > >the Working Groups and Areas in which these protocols are developed can > >be expected. However, the development of new compressing, > multiplexing > >or tunneling protocols is not an objective of this Working Group. In > >addition, since the current RFC > >4170 > >would be considered as one of the options, this RFC could be obsoleted. > > > >6. As a first objective, a document (TCM-TF - reference model) will > >define the different options which can be used at each layer. Specific > >problems caused by the interaction between layers will have to be > >issued, and suitable extensions may have to be added to the involved > protocols. > > > >7. If a pair of ingress/egress optimizers want to establish a TCM-TF > >session, they have first to use a mechanism to negotiate which concrete > >option would they use in each layer: header compression, multiplexing > >and tunneling. This will depend on the protocols that each extreme > >implements at each level, and in the scenario. So another document > >(TCM-TF - negotiation > >protocol) will include: > > > >- a mechanism to setup/release a TCM-TF session between an ingress and > >an egress-optimizer, also including: > >- a negotiation mechanism to decide the options to use at each layer > >(header compression, multiplexing and tunneling) between an ingress and > >an egress-optimizer, > > > >8. As a counterpart of the bandwidth saving, TCM-TF 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 (TCM-TF - 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. the loss of > >a multiplexed packet, MTU-related > >issues) will also have to be addressed. > > > >9. The working group may identify additional deliverables that are > >necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to > >discover an egress optimizer, and vice versa. The working group would > >re-charter to add them before working on them. > > > >10. In addition, specific uses of TCM-TF, such as in wireless and > >satellite scenarios, could be considered, and it might be studied > >whether modifications or extensions are required on the protocol. The > >working group would re-charter to work on those > >modifications/extensions. > > > >11. Interactions with other Working Groups can be expected, since > >TCM-TF uses already defined protocols for compression, multiplexing and > >tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). > > > > > >Goals and Milestones > > > >Specification of TCM-TF reference model. > > > >Specification of TCM-TF negotiation protocol. > > > >Specification of TCM-TF recommendations of using existing traffic > >classification methods, maximum delay and jitter to add, depending on > >the service. > > > > > >Current version of Document (TCM-TF - reference model): > >https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ > > > >Current version of Document (TCM-TF - recommendations): > >http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ > > > > > > > >Best regards, > > > >Jose > > > > > >_______________________________________________ > >tcmtf mailing list > >tc...@ietf.org > >https://www.ietf.org/mailman/listinfo/tcmtf