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

On 30/07/2012 07:53, Ruediger.Geib@telekom.de 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.

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.

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
> 
> 
> 
> -----Original Message-----
> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Dan Wing
> Sent: Friday, July 27, 2012 6:27 PM
> To: 'Jose Saldana'
> Cc: tcmtf@ietf.org; tsvwg@ietf.org
> Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf
> 
>> -----Original Message-----
>> From: Jose Saldana [mailto:jsaldana@unizar.es]
>> Sent: Friday, July 27, 2012 4:14 AM
>> To: 'Dan Wing'
>> Cc: tcmtf@ietf.org; tsvwg@ietf.org
>> Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
>>
>> 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?
> 
> 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
> 
> 
>> Thanks,
>>
>> Jose
>>
>> -----Mensaje original-----
>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de
>> Dan
>> Wing
>> Enviado el: viernes, 27 de julio de 2012 0:53
>> Para: 'Jose Saldana'
>> CC: tcmtf@ietf.org
>> Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
>>
>>> -----Original Message-----
>>> From: Jose Saldana [mailto:jsaldana@unizar.es]
>>> Sent: Thursday, July 26, 2012 3:56 AM
>>> To: 'Dan Wing'
>>> Cc: tcmtf@ietf.org
>>> 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:dwing@cisco.com]
>>> Enviado el: martes, 24 de julio de 2012 23:58
>>> Para: jsaldana@unizar.es
>>> CC: Tomaso.deCola@dlr.de; fpb@tid.es; tcmtf@ietf.org
>>> 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
>> tcmtf@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcmtf
> 
> 