From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8EDCA21F9B6; Wed, 22 Jul 2015 23:48:15 -0700 (PDT) Received: by obre1 with SMTP id e1so148704369obr.1; Wed, 22 Jul 2015 23:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=KVViPcQJu3z/W6JwvANLOn7bzH9yFJF1Lp8tjWUvuOY=; b=KVZKARqGapbDwYC5eQJhakMfQdsI3IJaZR1X2H+oP3LVBm8+smHHwnaMclDQEY+sIT sL+/DYfdi94mB0Z6z+gijRFigwf3I6Ma+e8hvIOvkEuLMSCBWfnNZ4BMRgvnJNvPOr+L AYfMaNGWA/7CRPvc3IupZR7zDTm/EXWo8XEayJpoBxytotL8mqavwZsmQcEms+Z4qTzA +3VkyqHg/RRFHtOlWVXfnb0gvhgWvBFeFOdOUHyPaRygImf1yjXkdpaRNnaqVYhJNakP dqp/8766vVW7cYe8gOJXsk3KpwJ+aqcjpUHmpBtX9Hbne3c0oOMIM4Jxch4agvd5l1H5 DYkg== MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr1611045oec.11.1437634094339; Wed, 22 Jul 2015 23:48:14 -0700 (PDT) Received: by 10.202.107.9 with HTTP; Wed, 22 Jul 2015 23:48:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 08:48:14 +0200 Message-ID: From: Dave Taht To: make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Make-wifi-fast] Fwd: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 06:48:43 -0000 ---------- Forwarded message ---------- From: Cullen Jennings Date: Thu, Jul 16, 2015 at 12:15 AM Subject: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e To: Tim Szigeti , tsvwg@ietf.org I'm glad to see this draft. This does need to be standardized - just having unpredictable behavior of equipment in the field is very bad. I do think this should be standards track and jointly developed by IEEE and IETF. I think the metric for how we choose needs to be based on finding a sane set of defaults that is going to work for the majority of situations and allow many reconfiguration cases for use cases that don't work. There is no mapping that will will work for 100% of use cases. I'd restructure the draft to simply have figure 4 be an IANA tables that showed the mappings and then have text to explain why the mapping is made the way it is. For me the focus of this draft is the default configuration of devices, I'm assuming that devices can be configured to override the defaults in this specification. On the applicability, it is very hard for an manufacture to know if an access point is going to be on the edge of the middle of the network when they develop the code for it. Even when it is deployed, it is very hard to to know if it is near the edge or not. I would remove the limitations of applicability and make the applicability be the internet. I'd move all the material about how 802.11e works to an appendix. I don't think the network norm has been to move from DSCP to marking with smaller number of bits by taking the high order bits (and visa versa in other direction). I agree some equipment has done this. But this does not really matter this draft, I would remove this type of stuff that is hard to a get agreement on and just focus on the mappings. Similarly I question that multimedia class was intended to necessarily be video. The vast majority of the devices that need to implement this will be deployed in situation where they run the default configuration that came from the manufacture so ideas like where the edge of the diff serv domain are can't be used very easily. On the topic of the actual mappings.... Based on my view of the changed applicability, I think things like CS6 and 7 need to map to UP 6 or 7 not 0 Agree that EF -> 6 We should consider CS5 mapping to same things as EF (6) but should map to at least 5 so that it is not less than the video flows. Note that the voice and signaling (EF and CS5) both have the same top 3 bits for DSCP value and that was by design. Slight rat whole on this topic ... Cisco's first QoS demo of video over sprints network set the QoS for video to be above signaling and you once the video started you could never stop the video or even hang up on the call. Due to a bunch of bugs on that prototype, you basically you had to pull the battery on the phone to get your phone so you could control it again. The practical use of AF4 vs CS4 for video phone calls has always been confusing. Over the past 4 years we have spent a huge amount of time getting the direction to be AF4. If this spec put CS4 above AF4, that would be a cause multiple manufactures to re-examin all of that and likely move to CS4 completely reseting the work we have done on this. The one thing I feel really strongly about is CS4 can't map higher than AF4. In the actual use of interactive video, some bits are far more important than others and we want to be able to indicate this inside the AF4 class so some should map to 4 and some should map to 5. I would suggest something like AF41 and AF42 map to 5 and AF43 and AF44 map to 4. Map CS4 to 4 CS3 is particularly tricking. The thing that is tricky about it is it got labeled Broadcast video. On unmanaged networks running default configurations, it is very unlikely to be broadcast video and is much more likely to be surveillance video. This is probably best mapped to 3 with configuration that allows it to be mapped to 4 instead. Of course there are networks where the surveillance traffic is more important than everything else (same as broadcast video) but if the consumer WIFI camera puts in wireless traffic at UP 5, users will not be happy. As a result, I would make the default mapping for CS3 and AF3 be 3. I know it would be appealing to look at what CS3 was meant to be used for but I think it is more important to think about how it did get used. The case I am thinking of is a wired surveillance camera plugged into a 802.11 bridges that does wireless to another AP than connects to the rest of the internet. AF2 to 3 or 0. Sure be nice if it went somewhere else but when mapping 64 things to 8, somethings not going to be pretty. I don't work with this enough to know when to use 3 and when 0. My experience is mostly around the audio and video qos so don't really have any comments on CS2 but mapping to 0 seems OK. Having AF1 maps to something less that DF seems like it will cause lots of unhappiness and surprises. I'd map it 3 or 0. CS1 to 1 makes sense. As Ken mentioned, adding the the VOICE-ADMIT admit to 6. On dropping things not in use. That's fine as advice to people deploying things but probably not much use to equipment vendors. It would be nice if all the deployment advice got separated to one section. --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast