Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf

From: "Jose Saldana" <[email-masked]>
Date: Fri, 27 Jul 2012 13:14:20 +0200

Well, perhaps a solution is the use of Diffserv bits: in the draft for
updating rfc4594
(https://datatracker.ietf.org/doc/draft-polk-tsvwg-rfc4594-update) there are
classes for real-time services and for best-effort ones. I have always
believed that the update of rfc4594 can be beneficial for TCMTF: you can
build a tunnel with flows belonging to the same traffic category.

But I don't know if the best-effort class means exactly the same as
delay-tolerant.

Dan, what do you think?

Thanks,

Jose

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Dan
Wing
Enviado el: viernes, 27 de julio de 2012 0:53
Para: 'Jose Saldana'
CC: [email-masked]
Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf

> -----Original Message-----
> From: Jose Saldana [mailto:[email-masked]]
> Sent: Thursday, July 26, 2012 3:56 AM
> To: 'Dan Wing'
> Cc: [email-masked]
> Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
> 
> Dan,
> 
> I don't know if I have really understood your question. Of course, I 
> assume that a delay of some seconds is not important for certain 
> sensor networks.
> But they don't need to signal that they are delay tolerant. I mean, 
> they are assumed to be from the moment they are installed.

The device, doing the multiplexing, needs to know if the packets belong to a
delay-tolerant (sensor) endpoint or to a non-delay tolerant endpoint.

If the device doing the multiplexing is also the gateway communicating with
the delay-tolerant (sensor) network, it certainly knows those
devices are delay-tolerant.   I believe that is your point.

My point is that if the device doing the multiplexing is not directly
connected to that network of delay-tolerant devices, it needs to somehow
differentiate between the delay-tolerant devices and the non- delay-tolerant
-- by being signaled or by being configured.

In the future, I expect a mix of sensors on various networks that are not
traditional dedicated sensor networks (e.g., WiFi, 3G), so relying on a
gateway to that dedicated network may not always be the way to know a device
is delay tolerant.

-d

> Well, I think I should gather some information about typical examples 
> of sensor networks (number of sensors, frequency of samples, packet 
> size of the samples, etc), in order to calculate in which cases the 
> bandwidth saving obtained with TCMTF can be interesting, and which 
> "multiplexing period"
> should be used. I think that this could be a typical case in which 
> multiplexing can be done by packet size instead of using a period. I 
> mean, when you have almost 1500 bytes (or the MTU), you send a packet.
> 
> I don't know if I have answered your question,
> 
> Jose
> 
> -----Mensaje original-----
> De: Dan Wing [mailto:[email-masked]]
> Enviado el: martes, 24 de julio de 2012 23:58
> Para: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
> 
> ...
> > Nevertheless, in order to get an idea of the savings, we should
> deploy
> > some calculations. Our research group has only done simulations for 
> > VoIP and games. In this case, we should know:
> >
> >
> >
> > -          Number of sensors in a typical scenario.
> >
> > -          Packet size and used headers. If IPv6 is used, savings
> >            can be really big, since header compression is really
> >            good for it.
> >
> > -          Packets per second that a single sensor can generate.
> >
> >
> >
> > And of course, the gateway should be the place for multiplexing.
> > In this case, the flows only travel from sensors to data center.
> > Am I right?
> 
> I wonder if there is an easy way for the endpoints to signal that they 
> are delay tolerant (to allow collecting ~5 seconds of little packets).
> 
> -d

_______________________________________________
tcmtf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Manuel <[email-masked]>
Date: Fri, 27 Jul 2012 13:40:19 +0200

Hi,
Jose is too fast typing and I have had to modify my answer.   ;-)

There is an approach to solve that flexibility. If the packet is source
marked (DSCP or MPLS tag for example), the multiplexor could select
different behaviour as a function of that information.A method of
implementation would be to apply different processing queues depending
on the sensitivity of the delay of each flow marked.  If the packet is
not marked the default option is applied.
         A example of implementation is three queues with the following
values to add each packet ( < 10 mseg; 10-100 mseg; > 100 meg). In fact,
I am agreed with Jose and the "draft-polk-tsvwg-rfc4594-update" would be
define these different classes for RT and BE ones.
  The multiplexor introduce the received packet in the right queue in
function of its tag, and the multiplexor waits for the maximum time in
that queue new packets before it process that queue.
         However the multiplexor does not need to know these treatments,
and it only receives always the same type of packets.

         These solution introduce flexibility in any case and the
complexity is not tow much hight.

I hope this helps the discussion.

Manuel Núñez

PD.: I have several ideas to refine the treatment and efficiency in the
queues, but I will explain them when they are more matured.

El 27/07/2012 13:14, Jose Saldana escribió:
> .

--
Manuel Núñez Sanz
Head of Network Automation & Dynamization
Telefónica Global Resources
Address: C/ Don Ramón de la Cruz 84. Madrid.
Phone: +34 629923641

________________________________

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jul 2012 09:26:30 -0700

> Sent: Friday, July 27, 2012 4:14 AM
> To: 'Dan Wing'
> Cc: [email-masked]; [email-masked]

I agree that DSCP is the best tool we have to combine packets
with similar characteristics.  

A recurring problem with DSCP is they are re-written to different 
values because a router was configured to rewrite them all the
time or because a queue of that traffic class had built.  That
rewriting needs to be considered (or ignored) when grouping packets 
that are 'similar'.  IMO, the fact that a packet was in a queue
a few router hops away (and now has a different DSCP than
its friends) doesn't change that it should be grouped with all 
of its friends into a multiplexing tunnel.

-d

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 08:53:57 +0200

Folks,

avoiding a DSCP rewrite at domain boundarys is probably
impossible - there are many independent DiffServ
deployments by now.

Al Morton will present some ITU work on the issue. We propose
to apply a small standardised set of domain behaviours (also
called QoS classes) at interconnection interfaces. The benefit
is a domain remarks tranmitted/received traffic to/from the
interdomain DSCPs. Every ISP needs to solve the interworking
issue once only and should expect a reasonable end to end QoS.

The proposal more tries to look at DiffServ router forwarding knobs:
a queuing mechanism and active queue management. My view is, these
can be optimised for an expected transport behaviour:

UDP traffic (streaming or telephony, real time gaming) will most
likely not be retransmitted. A short queue will do, active queue
management by random drops isn't required (unless you'd like
to apply PCN marking or the like).

TCP traffic interacts with router congestion indications, queues
may be a little bit deeper and active queue management may be
deployed. Today it is RED, ECN or the like in future.

If one looks at it from that angle, the number of useful
QoS classes is small.

Take the transport indication (TCP/UDP) as "dominating" in a
class, not a pureness requirement.

Regards

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Friday, July 27, 2012 6:27 PM
To: 'Jose Saldana'
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jul 2012 08:19:08 +0100

On 30/07/2012 07:53, [email-masked] wrote:
> interdomain DSCPs. 

That assumes that you trust the diffserv markings applied by your
peer. In the general case, that seems unlikely, which is why there
is always likely to be a classifier as well as a re-marker at the
boundary, and quite possibly a traffic conditioner too.

Agreed, there might be a subset of peering relationships at which
you would be prepared to trust your neighbour's DSCPs. I thought
that was one intent behind RFC 4594 and its possible update.
We surely don't need *another* set of recommended traffic classes.

However, at a peering connection where you don't have that level of
trust, you have to either reclassify all packets or mark everything
as best effort.

Every ISP needs to solve the interworking
> deployed. Today it is RED, ECN or the like in future.

How do you help the alarming amount of traffic that is streaming over
TCP?

    Brian

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 30 Jul 2012 09:57:25 +0200

Another question: Brian talks about streaming over TCP (e.g. Youtube). This
is non-interactive traffic, since the client can do buffering an wait some
(short) time. But in addition, there are real-time interactive services
using TCP.

For example, World of Warcraft and almost every MMORPG game uses TCP. And
they are real-time interactive services: a player has to fight against other
players or against the "machine", and delay matters (every single player can
confirm this). Our research group has studied this issue, and also the
coexistence of real-time and best-effort TCP flows in a paper that is being
presented today in ICCCN Munchen: "The Effect of TCP Variants on the
Coexistence of MMORPG and Best-Effort Traffic"
(http://diec.unizar.es/~jsaldana/personal/hurry_NIME_2012_in_proc.pdf)

These games are becoming more and more popular. World of Warcraft has 10
million players. And gamers are really difficult clients to delay with. You
can have a look to this presentation (especially slide 5):
http://diec.unizar.es/~jsaldana/personal/sergei_SPECTS_2012_presentation.pdf

The only thing I want to remark with this e-mail is that TCP and best-effort
are not the same. It may sound weird, but real-time interactive TCP services
do exist, and they work every day with a lot of clients. We cannot forget
this when thinking about traffic classification.

Best regards and thank you for your feedback,

Jose

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de
Brian E Carpenter
Enviado el: lunes, 30 de julio de 2012 9:19
Para: [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf

On 30/07/2012 07:53, [email-masked] wrote:
> Folks,
> 
> avoiding a DSCP rewrite at domain boundarys is probably impossible - 
> there are many independent DiffServ deployments by now.
> 
> Al Morton will present some ITU work on the issue. We propose to apply 
> a small standardised set of domain behaviours (also called QoS 
> classes) at interconnection interfaces. The benefit is a domain 
> remarks tranmitted/received traffic to/from the interdomain DSCPs.

That assumes that you trust the diffserv markings applied by your peer. In
the general case, that seems unlikely, which is why there is always likely
to be a classifier as well as a re-marker at the boundary, and quite
possibly a traffic conditioner too.

Agreed, there might be a subset of peering relationships at which you would
be prepared to trust your neighbour's DSCPs. I thought that was one intent
behind RFC 4594 and its possible update.
We surely don't need *another* set of recommended traffic classes.

However, at a peering connection where you don't have that level of trust,
you have to either reclassify all packets or mark everything as best effort.

> a queuing mechanism and active queue management. My view is, these can 
> be optimised for an expected transport behaviour:
> 
> management by random drops isn't required (unless you'd like to apply 
> PCN marking or the like).
> 
> TCP traffic interacts with router congestion indications, queues may 
> be a little bit deeper and active queue management may be deployed. 
> Today it is RED, ECN or the like in future.

How do you help the alarming amount of traffic that is streaming over TCP?

    Brian

> 
> If one looks at it from that angle, the number of useful QoS classes 
> is small.
> 
> Take the transport indication (TCP/UDP) as "dominating" in a class, 
> not a pureness requirement.
> 
> Regards
> 
> Ruediger
> 
> 
> 
>> Well, perhaps a solution is the use of Diffserv bits: in the draft 
>> for updating rfc4594
>> classes for real-time services and for best-effort ones. I have 
>> always believed that the update of rfc4594 can be beneficial for 
>> TCMTF: you can build a tunnel with flows belonging to the same 
>> traffic category.
>>
> I agree that DSCP is the best tool we have to combine packets with 
> similar characteristics.
> 
> values because a router was configured to rewrite them all the time or 
> because a queue of that traffic class had built.  That rewriting needs 
> to be considered (or ignored) when grouping packets that are 
> 'similar'.  IMO, the fact that a packet was in a queue a few router 
> hops away (and now has a different DSCP than its friends) doesn't 
> change that it should be grouped with all of its friends into a 
> multiplexing tunnel.
> 
> -d
> 
> 
>> Thanks,
>>
>> Jose
>>
>> De: [email-masked] [mailto:[email-masked]] En nombre 
>> de Dan Wing Enviado el: viernes, 27 de julio de 2012 0:53
>> Para: 'Jose Saldana'
>> CC: [email-masked]
>> The device, doing the multiplexing, needs to know if the packets 
>> belong to a delay-tolerant (sensor) endpoint or to a non-delay 
>> tolerant endpoint.
>>
>> If the device doing the multiplexing is also the gateway 
>> communicating with the delay-tolerant (sensor) network, it certainly 
>> knows those
>> connected to that network of delay-tolerant devices, it needs to 
>> somehow differentiate between the delay-tolerant devices and the non- 
>> delay- tolerant
>> In the future, I expect a mix of sensors on various networks that are 
>> not traditional dedicated sensor networks (e.g., WiFi, 3G), so 
>> relying on a gateway to that dedicated network may not always be the 
>> way to know a device is delay tolerant.
>>
>> -d
>>
>>> Well, I think I should gather some information about typical 
>>> examples of sensor networks (number of sensors, frequency of 
>>> samples, packet size of the samples, etc), in order to calculate in 
>>> which cases the bandwidth saving obtained with TCMTF can be 
>>> interesting, and which "multiplexing period"
>>> De: Dan Wing [mailto:[email-masked]] Enviado el: martes, 24 de 
>>> julio de 2012 23:58
>>> Para: [email-masked]

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 10:44:54 +0200

Brian,

a two parts response:

QoS interconnection isn't free of charges. The philosphy I am
aware of is "sending party pays". It's a sender incentive
then to ensure the traffic is marked as desired.

Traffic using TCP transport should use a QoS class optimised
for TCP transport, I'd suggest. A recurring issue during
standardisation and interconnection discussion with network
engineers is to avoid to name QoS classes by applications.
The point is to look at the required QoS properties. Transport
seems to be reasonably abstract.

Another issue: QoS means to avoid congestion (this is
not CoS, meaning "survive longer"). Under foreseeable
operational conditions, all QoS classes experience similar
forwarding (no drops and low delay/jitter).

That's why I also don't favour approaches starting from
an application and ending with a new required QoS class.
Where's the experience with the deployed classes
justifying this way of engineering?

The more basic part of your statement:

I agree, we don't need *another* set of classes. You, James and
I just don't agree on which are the ones we don't need. The
set I propopse is rather abstract. I didn't up to now catch a
single line telling me why this set of classes isn't useful.
Instead you say that you prefer a small set as I propose but
then you support James class/codepoint overspecification.
Too many classes, codepoints and standards around them
are part of the problem, they are not part of the solution.

To be precise: Interconnection agreements are simple regarding
the EF and the Best Effort class. They are work intensive
for AF based classes. Do you have an idea what could be
the cause?

No standards body besides IETF works with these many
codepoints and classes. Even if they propose pure IP
interconnections. But (obviously) each standard body
picks another subset and some of them interpret IETF AF
standards rather creative. Yes, DiffServ is flexible enough
to deal with that. Administration, operation and
interconnection negotiation however benefit if there's a
standard behviour, used by a majority of all customers and
by tailored adaptions used by a few.

Regards,

Ruediger

    Brian

>> Dan
>> somehow
>> not

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 12:18:18 +0200

Jose,

thanks. Sure, application developers hack around the transport
services they find and it is amazing what they can deliver
withhout QoS. And there are fair arguments why to use TCP
for everything.

By DiffServ alone, one doesn't change the routing path of
a packet. Hence in a congestion free network, the DiffServ
supported packet is at best slightly faster then the
BE packet (that's far less than 1 ms). The RTT remains
the same then.

QoS aware routing could offer more. I'm taking this thread
as a DiffServ thread, not a QoS aware routing thread. No
discussion on QoS routing then.

Under congestion, the player suffers a longer delay and
may experience packet drops. QoS transport of whatever
kind may help to avoid that. But DiffServ doesn't provide
more bandwidth. It defines how the available bandwidth
is shared. If there's a bottleneck in your architecture,
it will remain a bottleneck, also if you deploy DiffServ.
If there's non gaming background traffic which can deal
with congestion, DiffServ could be of use.

Be relaxed on the suitable class. QoS means that under
foreseeable conditions, no congestion should occur.
Queues/classes are optimised for a certain behaviour
in unlikely cases. The SLA QoS descriptions don't tell
you what's your daily experience. A QoS class optimised
for TCP traffic may well do.

Regards,

Ruediger

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]]
Sent: Monday, July 30, 2012 9:57 AM
To: 'Brian E Carpenter'; Geib, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf

Jose

-----Mensaje original-----

    Brian