Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback

Hi all, I've read the draft, and for me it has resulted very interesting. As a proposal of coverage extension of the standard, I would like to propose you to don't put focus only in real-time flows.
From the point of view of a network operator, there are lots of kind of small packets that suppose a big amount of information and packets travelling through the network. An example could be DNS packets. A DNS packet may have an average size under 100 bytes, included header bytes. And the amount of DNS packets in a medium or big operator may achieve a rate of thousands of packets per second. It could also be used in the communication between the cache DNS and the authoritative DNS TLD servers, reducing the bandwidth and adding also a new kind of secure communications (the tunnel could be a secure one, as IPSec). Although there is already a secure DNS Sec protocol defined by IETF, this must not be seen as incompatible.

Besides, there are other kinds of traffic of services, as could be chatting applications like whatsapp and similar ones, that can suppose a lot of bytes that can be compressed, multiplexed, and tunnelled to the server endpoint.
Specially in rush hours, like new year's night, Christmas day, etc...this could be very useful, not only for the operator, but also for the application owner.

In summary, I would like to propose you to include other subchapter 1.X for such kind of traffic, not as sensible to delay as the other ones you comment in the draft, but very optimizables.

What do you think about it?

Regards,

Juan Antonio





Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Juan Antonio,

I think your proposal is interesting. By now, we are mostly focused in real-time flows, since you can find flows of e.g. 50 pps, with a common origin and destination. In that cases, the header compression rate is big, since all the packets have, at least, the same IP-port origin and destinations. So you can save a lot of bytes in each packet.

We should not forget that the proposal is for tunneling, compressing and multiplexing. So for the DNS case, we should think a bit more. Some thoughts:

- Are there scenarios where many DNS flows share a path?: In the case of  " the communication between the cache DNS and the authoritative DNS TLD servers", perhaps you can simply establish a tunnel with header compression. But I don't think multiplexing is present: which flows do you aggregate? Isn't it only one flow? So we have tunneling and compressing, but not multiplexing. (If somebody finds a scenario where multiplexing is also possible, it would be fine).

- In the case of Whatsapp, I think TCMTF can be applied, but if you really want to save bandwidth, you need to locate the multiplexer in a place where you can bundle a really high number of flows. In addition, the flows will not have the same IP origin (you cannot multiplex two messages from the same user, since you would lose the interactivity). Perhaps all the flows behind a NAT would have the same IP origin and destination but, how many flows can you find there? On the other hand, the advantage is that the multiplexing period can be bigger in order to get more savings. I think a Whatsapp user would not notice a delay of 1 or 2 seconds. (In contrast, for a FPS game, adding more than 40-50 ms is really bad). Logically, these effects and the savings should be studied, but nothing prevents us to include non real-time flows as a use case in the draft.

Perhaps we could deploy some preliminary calculations. It is not difficult to find the asymptote of the bandwidth saving: is a very simple quotient: you only need to estimate the average size of the compressed header you would obtain. (You can find an example in the equation (2) of this paper:  http://diec.unizar.es/~jsaldana/personal/comm...) 

Best regards,

Jose

-----Mensaje original-----
De:   En nombre de JUAN ANTONIO CASTELL LUCIA
Enviado el: martes, 26 de junio de 2012 15:56
Para: 
Asunto: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback

Hi all, I've read the draft, and for me it has resulted very interesting. As a proposal of coverage extension of the standard, I would like to propose you to don't put focus only in real-time flows.
From the point of view of a network operator, there are lots of kind of small packets that suppose a big amount of information and packets travelling through the network. An example could be DNS packets. A DNS packet may have an average size under 100 bytes, included header bytes. And the amount of DNS packets in a medium or big operator may achieve a rate of thousands of packets per second. It could also be used in the communication between the cache DNS and the authoritative DNS TLD servers, reducing the bandwidth and adding also a new kind of secure communications (the tunnel could be a secure one, as IPSec). Although there is already a secure DNS Sec protocol defined by IETF, this must not be seen as incompatible.

Besides, there are other kinds of traffic of services, as could be chatting applications like whatsapp and similar ones, that can suppose a lot of bytes that can be compressed, multiplexed, and tunnelled to the server endpoint.
Specially in rush hours, like new year's night, Christmas day, etc...this could be very useful, not only for the operator, but also for the application owner.

In summary, I would like to propose you to include other subchapter 1.X for such kind of traffic, not as sensible to delay as the other ones you comment in the draft, but very optimizables.

What do you think about it?

Regards,

Juan Antonio





Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Jose, first of all, thanks for giving me your opinion.

Regarding your first question, if there are common paths for many DNS flows where it could be possible to apply TCMTF, the answer is yes. In case of the question about if there is more than one flow, the answer is yes again. The fact that the DNS requests can have the same origin IP doesn't mean that the requests correspond to the same requestor.
Anyway, this is only one of a handful of use cases where it is possible to apply the TCMTF. Therefore, I suggest you to choose which you consider more suitable.

Regarding whatsapp use case (but not only whatsapp, also twitter, MSN, skype, ...), there are places in the network to "collect" flows from different users in order to may apply multiplexing, like the IP edge or the DPI.
Only for this second use case, I think it's worth to use TCMTF for non real-time flows, but, more use cases are out there!

Kind Regards,
Juan Antonio

-----Mensaje original-----
De: Jose Saldana 
Enviado el: miércoles, 27 de junio de 2012 9:56
Para: JUAN ANTONIO CASTELL LUCIA; 
Asunto: RE: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback

Juan Antonio,

I think your proposal is interesting. By now, we are mostly focused in real-time flows, since you can find flows of e.g. 50 pps, with a common origin and destination. In that cases, the header compression rate is big, since all the packets have, at least, the same IP-port origin and destinations. So you can save a lot of bytes in each packet.

We should not forget that the proposal is for tunneling, compressing and multiplexing. So for the DNS case, we should think a bit more. Some thoughts:

- Are there scenarios where many DNS flows share a path?: In the case of  " the communication between the cache DNS and the authoritative DNS TLD servers", perhaps you can simply establish a tunnel with header compression. But I don't think multiplexing is present: which flows do you aggregate? Isn't it only one flow? So we have tunneling and compressing, but not multiplexing. (If somebody finds a scenario where multiplexing is also possible, it would be fine).

- In the case of Whatsapp, I think TCMTF can be applied, but if you really want to save bandwidth, you need to locate the multiplexer in a place where you can bundle a really high number of flows. In addition, the flows will not have the same IP origin (you cannot multiplex two messages from the same user, since you would lose the interactivity). Perhaps all the flows behind a NAT would have the same IP origin and destination but, how many flows can you find there? On the other hand, the advantage is that the multiplexing period can be bigger in order to get more savings. I think a Whatsapp user would not notice a delay of 1 or 2 seconds. (In contrast, for a FPS game, adding more than 40-50 ms is really bad). Logically, these effects and the savings should be studied, but nothing prevents us to include non real-time flows as a use case in the draft.

Perhaps we could deploy some preliminary calculations. It is not difficult to find the asymptote of the bandwidth saving: is a very simple quotient: you only need to estimate the average size of the compressed header you would obtain. (You can find an example in the equation (2) of this paper:  http://diec.unizar.es/~jsaldana/personal/comm...)

Best regards,

Jose

-----Mensaje original-----
De:   En nombre de JUAN ANTONIO CASTELL LUCIA
Enviado el: martes, 26 de junio de 2012 15:56
Para: 
Asunto: [tsvwg] Extension proposal for draft-saldana-tsvwg-tcmtf-02: asking for feedback

Hi all, I've read the draft, and for me it has resulted very interesting. As a proposal of coverage extension of the standard, I would like to propose you to don't put focus only in real-time flows.
From the point of view of a network operator, there are lots of kind of small packets that suppose a big amount of information and packets travelling through the network. An example could be DNS packets. A DNS packet may have an average size under 100 bytes, included header bytes. And the amount of DNS packets in a medium or big operator may achieve a rate of thousands of packets per second. It could also be used in the communication between the cache DNS and the authoritative DNS TLD servers, reducing the bandwidth and adding also a new kind of secure communications (the tunnel could be a secure one, as IPSec). Although there is already a secure DNS Sec protocol defined by IETF, this must not be seen as incompatible.

Besides, there are other kinds of traffic of services, as could be chatting applications like whatsapp and similar ones, that can suppose a lot of bytes that can be compressed, multiplexed, and tunnelled to the server endpoint.
Specially in rush hours, like new year's night, Christmas day, etc...this could be very useful, not only for the operator, but also for the application owner.

In summary, I would like to propose you to include other subchapter 1.X for such kind of traffic, not as sensible to delay as the other ones you comment in the draft, but very optimizables.

What do you think about it?

Regards,

Juan Antonio





Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx