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

[<[e-mail]>]

Hi Dan,

if QoS is what your provider promises, then during 99,9x% of the
time, you will not be aware of what your QoS class is
optimised for. Unfortunately, SLA definitions are the only
QoS descriptions which matter to most of us.

Another issue with QoS is that one shouldn't assign application
class names to QoS PHBs. I also shouldn't use transport names. Then
one ends up with a rather abstract PHB descriptions and that often
isn't helpful again (noone knows what to do with abstractly described
things).

A QoS class optimised for traffic with no or very small
retransmission capacities will carry traffic which doesn't decrease
if there's congestion. One could adapt queue design to this
beahivour. That's what I mean by a class optimised for a UDP
like transport.

If one optimises a QoS class for a transport which will react on
network congestion indications, the queue may look different. It
may be deeper, and Active Queue Management with random dropping
or marking is possibly present. TCP? SCTP? Yes, and any other
benefitting from this behaviour.

Marking isn't present yet, but I hope the Internet community
finds way's to design and deploy it (I've been active in PCN
and I follow Conex).

None of these QoS classes is optimised for a particular transport.
But how to give guidance which QoS class to pick? I choose
transport characteristics. Others prefer application charatersitics
(I prefer less QoS classes, others more).

Don't be fixed on TCP or UDP - these terms are used to give
orientation only. Understand the QoS class properties and keep
in mind, what you get is indeed QoS, i.e. no congestion.

Regards,

Ruediger

-----Original Message-----
From: Dan Wing [mailto:[e-mail]]
Sent: Tuesday, August 07, 2012 3:00 AM
To: Geib, Rüdiger; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Sunday, July 29, 2012 11:54 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf
>
> 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).

Yes, I would like PCN and ECN marking for UDP flows, so they can
react.

What of SCTP-over-UDP, which is the data channel that RTCWEB is
going to use?  SCTP has congestion control and thus SCTP-over-UDP
should be treated much more like TCP.  Similarly, we have lots of
existing deployment of TCP over IPsec over UDP (such as VPNs),
which should also be treated like TCP.

> 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.

What of SCTP and DCCP?  I would like those protocols to be deployable
at least over IPv6.  With IPv6, we don't have NAPT devices that
only allow TCP and UDP, and would be a shame if QoS only worked for
UDP and TCP.

-d


>
> Regards
>
> Ruediger
>
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Dan Wing
> Sent: Friday, July 27, 2012 6:27 PM
> To: 'Jose Saldana'
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf
>
> > -----Original Message-----
> > From: Jose Saldana [mailto:[e-mail]]
> > Sent: Friday, July 27, 2012 4:14 AM
> > To: 'Dan Wing'
> > Cc: [e-mail]; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] En nombre
> de
> > Dan
> > Wing
> > Enviado el: viernes, 27 de julio de 2012 0:53
> > Para: 'Jose Saldana'
> > CC: [e-mail]
> > Asunto: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
> >
> > > -----Original Message-----
> > > From: Jose Saldana [mailto:[e-mail]]
> > > Sent: Thursday, July 26, 2012 3:56 AM
> > > To: 'Dan Wing'
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > > Enviado el: martes, 24 de julio de 2012 23:58
> > > Para: [e-mail]
> > > CC: [e-mail]; [e-mail]; [e-mail]
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcmtf