Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
<Ruediger.Geib@telekom.de> Mon, 30 July 2012 10:18 UTC
Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC38021F8769; Mon, 30 Jul 2012 03:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eZV4CrJGKRx; Mon, 30 Jul 2012 03:18:27 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC621F876C; Mon, 30 Jul 2012 03:18:26 -0700 (PDT)
Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 30 Jul 2012 12:18:25 +0200
Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 30 Jul 2012 12:18:19 +0200
From: Ruediger.Geib@telekom.de
To: jsaldana@unizar.es
Date: Mon, 30 Jul 2012 12:18:18 +0200
Thread-Topic: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
Thread-Index: AQGF+EuvFpZGZkinmlaOrA3LFBD+CQDG7hgjAtHnKE0AzSb+eAKtKsUWANcmoK8CBoLfLJeA1leQgAAVtDA=
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD2456F9@HE111648.emea1.cds.t-internal.com>
References: <03ee01cd69e7$649942e0$2dcbc8a0$@com> <004001cd6b1d$405442e0$c0fcc8a0$@unizar.es> <069901cd6b81$6f1bd2a0$4d5377e0$@com> <004001cd6be8$f8e1e170$eaa5a450$@unizar.es> <090e01cd6c14$943fd750$bcbf85f0$@com> <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD2452CB@HE111648.emea1.cds.t-internal.com> <5016356C.6030400@gmail.com> <005201cd6e28$f68438a0$e38ca9e0$@unizar.es>
In-Reply-To: <005201cd6e28$f68438a0$e38ca9e0$@unizar.es>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tcmtf@ietf.org, tsvwg@ietf.org
Subject: Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2012 10:18:28 -0000
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:jsaldana@unizar.es] Sent: Monday, July 30, 2012 9:57 AM To: 'Brian E Carpenter'; Geib, Rüdiger Cc: tcmtf@ietf.org; tsvwg@ietf.org; dwing@cisco.com Subject: RE: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-tsvwg-tcmtf 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: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Brian E Carpenter Enviado el: lunes, 30 de julio de 2012 9:19 Para: Ruediger.Geib@telekom.de CC: tcmtf@ietf.org; tsvwg@ietf.org; dwing@cisco.com; jsaldana@unizar.es Asunto: Re: [tcmtf] [tsvwg] 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 > > _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf
- [tcmtf] M2M, WSNs and draft-saldana-tsvwg-tcmtf FERNANDO PASCUAL BLANCO
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Tomaso.deCola
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… FERNANDO PASCUAL BLANCO
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Jose Saldana
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Dan Wing
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Jose Saldana
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Tomaso.deCola
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… gorry
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Dan Wing
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Jose Saldana
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Jose Saldana
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Manuel
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Dan Wing
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Ruediger.Geib
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Brian E Carpenter
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Jose Saldana
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Ruediger.Geib
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Ruediger.Geib
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Dan Wing
- Re: [tcmtf] [tsvwg] M2M, WSNs and draft-saldana-t… Ruediger.Geib