From nobody Mon Jan 18 08:37:25 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37E1B398C; Mon, 18 Jan 2016 08:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L5O4dZ5Kc3k; Mon, 18 Jan 2016 08:37:20 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0B1B398A; Mon, 18 Jan 2016 08:37:17 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D458D1B001C2; Mon, 18 Jan 2016 16:44:43 +0000 (GMT) Received: from 37.205.56.247 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 18 Jan 2016 16:37:16 -0000 Message-ID: Date: Mon, 18 Jan 2016 16:37:16 -0000 From: gorry@erg.abdn.ac.uk To: draft-trammell-spud-req@ietf.org, spud@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, fverdicc@abdn.ac.uk Subject: [Spud] Some initial comments on Requirements for the design of a Substrate Protocol for User Datagrams (SPUD) X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 16:37:23 -0000 Here are a few comments on a read of the requirements draft: In section 4; NiT; correct /flow which are/flow that are/ /refrain from sending heartbeat traffic/ - disagree with the hard state view, to me this should I feel be regarded as soft state, in as much as a middlebox can decide to keep the state once it sees the start of a SPUD flow, but keeping that state indefinitely is I think unlikely and quite undesirable. I would suggest that rather than eliminating heartbeat needs, it relaxes this need, and can result in flows that do not need to generate explicit heartbeats because their natural protocol interactions already provide sufficient packet exchanges to refresh the state. Tear-down messages bring their own DOS and reordering opportunities, but could anyway be regarded as advisory, perhaps even good policy is not to remove state until after a grace period. NiT; /tube/ - term used, but not previously defined (definition should come earlier) Similarly spud flow? ... I am not sure I understand this related to a 5-tuple and then saying they receive similar treatment, will this not also imply the same DSCP? /ICMP/ - presumably also ICMPv6? what is 5-tuple ICMP? - isn't recommended ICMP processing already based on a sort of 5-tuple utilising the payload to extract the flow info that caused the error? Can you explain more than current? Sect 5.1 I'm unclear what is intended by "may or may not" be related to separate semantic entities in the superstate. This seems like it should include the same caveats as exposed when using multiple DSCPs with upper layer protocols, as discussed in the DART WG, but of course without assumptions that DSCPs are end to end. Sect 5.4 See earlier note on End Signalling, tear down messages may be delayed, reordered, etc. Hence I am really unsure it can be a good idea for these to explicitly and immediately release state. (Perhaps in a hard state model, but then this model seems wrong to me). They can however be used to know that an association will end with a particular sequence number (etc). being robust to reordering and delay is important. Sect 5.7. I agree endpoints need to verify that messages originate on-path. Equally though I would suggest endpoints need to be robust to path changes and cases where more than one path exists at a time, although I would say that maybe these cases are not the norm, more that any system should not behave stupidly when these occur. Sect 6.1 Maybe you could think again about wording of this requirement! I do not think you can require it to work through arbitrary middleboxes. You can require the protocol to be designed to optimize the chances of success, or something. Sect 6.2 NiT: Again, probably "designed to have low overhead" is more correct? Sect 6.3 - I understand the conclusion to use UDP, but TCP is widely implemented also and often provides richer APIs all available from user space. it just does not meet the requirements in terms of the transport services that are needed by SPUD - which seems to need a datagram transport. So I am not sure I agree with why the current reasoning, but agree with the outcome. Sect 6.4 NiT: Again, probably "designed to operate in the present internet" is more correct? Sect 6.4 I do not agree that the information exposed by SPUD needs (must) be useful, only that this is desirable to stimulate deployment. It doesn't seem a prerequisite to me. Again, I'd argue that the information "should" provide incentives, not has to. Sect 6.4 I'd encourage the authors to bring out the implications of loss, reordering etc as a separate point, since these are I suggest unrelated to incremental Deployability. Sect 6.4 I'm about the actual requirements to operate in multiparty, multicast etc. If the need is to support multicast, this is a CORE reason why SPUD has to be over UDP, since it is the only IETF standards track transport protocol that supports multicast over the network layer. In stating the support for this, it's brings very specific requirements - I don't see these discussed - Is the assumption SSM? ASM? Both? How will SPUD handling scaling and multiple responses from different branches in the tree, etc? Then Multipath. Multipath surely brings it own set of requirements - what are these. Sect 6.5 What is background in this context? - The present text makes it sound like off path attack for UDP is somehow a more problem than for TCP, whereas I think what may be intended is that UDP receivers are not protected from these threats in the way that TCP and other connection-Oriented transports protocols provide protection? - The forgery of a source address is maybe less of an issue for multicast, because of RPF rules, This section could usefully refer to the UDP Guidelines, and probably other sections, since some of what this document discusses are not actually SPUD specific issues, but issues that result from the limited in-built transport services offered by UDP. In these cases, reference to the guidelines RFC(or newer ID) would seem the correct requirement. Sect 6.5 /We note.../ This note is quite confusing to me. I am not sure what is intended. In some ways this seems to contradict the multicast requirement, and I am not sure what it really implies. Please clarify. Sect 6.11 - duplication robustness was also noted as a need in 6.4. See note there. Sect 6.11 - sending less that the output link MTU does not avoid downstream fragmentation. I think this fragmentation requirement is a little difficult to understand, but is important. For instance, how will SPUD work with IPv6, where fragmentation -even at the endpoints, requires a UDP checksum? Sect 6.12 I see two requirements here, that the user of the transport service (superstrate) is transparent to whether SPUD is used beneath. This I think I understand. The second is that the two formats are freely transcodable of the wire, which leaves me very puzzled and worried. Are these tow points perceived the same? I do not understand? And why the latter? Sect 6 There is no explicit requirement that the there is a return path from the the receiving endpoint back to the sender, although I think this could well be implied. I'd have expected this. I'd also hoped for some text that said that data flow (whatever words) could be Uni or Bi directional, is that the case? Sect 6 In discussing robustness, it could be worth noting (aka UDP guidelines) that per packets signals may need to be repeated over multiple packets and appropriate interval to have sufficient confidence of delivery under link loss or congestion. Section 7.1 I think I didn't get my head around these two options. I wonder though if this is related to a /bidirectional/ flow? - is it only when the superstrate is bidirectional, I would have thought it was when the SPUD layer was bidirectional, but maybe I am already confused here, and will only be able to comment when the above comments are clarified. section 7.3 I think there are two very distinct cases here: 1) avoiding corrupt data to the endpoint, and sent to other endpoints I am not sure what the corruption protection model is that is being proposed. How will SPUD use higher layer checksums to validate lower layer information? Models vary widely, maybe this is implied use of DTLS or something? 2) avoiding corrupt control data used by SPUD endpoints and middleboxes - is it possible to separate these topics? Section 7.6 I would personally prefer separation of the requirements for end to end transport discovery support (and superstrates) and the different case of discovering middleboxes. Hope this helps, and look forward to finding out more, Gorry From nobody Mon Jan 25 23:30:41 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DFE1A6F47; Mon, 25 Jan 2016 23:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEabALuj4Tpo; Mon, 25 Jan 2016 23:30:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3171A6F49; Mon, 25 Jan 2016 23:30:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDL54950; Tue, 26 Jan 2016 07:30:32 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Jan 2016 07:30:30 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.62]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Tue, 26 Jan 2016 15:30:25 +0800 From: Youjianjie To: "tsvwg@ietf.org" , "spud@ietf.org" Thread-Topic: One bit for latency bandwidth tradeoff Thread-Index: AdFYC2ufEvZMvnA6QRuvgZ56n6lDIQ== Date: Tue, 26 Jan 2016 07:30:24 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.235] Content-Type: multipart/alternative; boundary="_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A72099.0054, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.62, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 60752dacd129d1fb7f98335c7d1ae800 Archived-At: Subject: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 07:30:38 -0000 --_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Existing work shows that having a latency-bandwidth trade-off decision woul= d be useful. For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D9= 23942 http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2= 008.pdf SPUD describes this as one of its use cases. https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 We wonder: how should this be specified? Could we, for example, use the DSC= P? If so, how - can we use an existing value, or should we define a new one= ? Regards, Jianjie --_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Existing work shows that hav= ing a latency-bandwidth trade-off decision would be useful.

For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942

http://p= eople.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf<= /a>

 

SPUD describes this as one o= f its use cases.

https://tools.ietf= .org/html/draft-kuehlewind-spud-use-cases-00#section-4

 

We wonder: how should this b= e specified? Could we, for example, use the DSCP? If so, how - can we use a= n existing value, or should we define a new one?

 

Regards,

Jianjie

 

--_000_F6C28B32DA084644BB6C8D0BD65B669DBBED91NKGEML515MBSchina_-- From nobody Tue Jan 26 00:50:26 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301401A870C for ; Tue, 26 Jan 2016 00:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juVYUggzu5eF for ; Tue, 26 Jan 2016 00:50:22 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AD21A8706 for ; Tue, 26 Jan 2016 00:50:21 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1aNzKL-00006s-Kw for ; Tue, 26 Jan 2016 09:50:17 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 85066B00472 for ; Tue, 26 Jan 2016 09:50:17 +0100 (CET) To: spud@ietf.org References: From: "Bless, Roland (TM)" X-Enigmail-Draft-Status: N1110 Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <56A73348.70504@kit.edu> Date: Tue, 26 Jan 2016 09:50:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1453798217. Archived-At: Subject: Re: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:50:25 -0000 Hi, Am 26.01.2016 um 08:30 schrieb Youjianjie: > Existing work shows that having a latency-bandwidth trade-off decision > would be useful. > > For example: > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942 > > http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf > > SPUD describes this as one of its use cases. > > https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 > > We wonder: how should this be specified? Could we, for example, use the > DSCP? If so, how - can we use an existing value, or should we define a > new one? I think one should distinguish between different cases, e.g., - Application wants low latency transport - Application needs bulk transfer and insensitive to latency - Application uses a congestion control algorithm for achieving low latency - etc. Moreover, there may exist high-bandwidth applications that also require low latency, so that you don't have a tradeoff situation. One bit isn't enough to distinguish that properly. In the DiffServ architecture you better should exactly describe what kind of per-hop behaviour (PHB) you want for packet treatment. Then you could use a DSCP that points to that PHB. The EF PHB is also offering a low delay service, but usually requires admission control, policing and non-bursty flows. An indication of the transport protocol that it's going to use a low-delay congestion control mechanism is a completely different thing. I think it would be useful to have a possibility to separate flows with incompatible congestion control mechanisms, i.e., to put them into separate queues. We did some experiments and were able to achieve bandwidth fairness while keeping the delay for the low-delay congestion controlled flows much lower compared to the loss-based congestion controlled flows. Regards, Roland From nobody Tue Jan 26 01:11:57 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919171A8799 for ; Tue, 26 Jan 2016 01:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLSUGDMPtMcl for ; Tue, 26 Jan 2016 01:11:54 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45D51A8790 for ; Tue, 26 Jan 2016 01:11:53 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aNzfD-0006tk-5Q; Tue, 26 Jan 2016 10:11:51 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aNzfC-0001tg-IV; Tue, 26 Jan 2016 10:11:51 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <56A73348.70504@kit.edu> Date: Tue, 26 Jan 2016 10:11:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <361E6EA9-0886-452D-96B4-A4FC4277A4B9@ifi.uio.no> References: <56A73348.70504@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 37500 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 92B8F7550856683EAE963048B75AF4E2E705E10B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 8979 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 09:11:56 -0000 > On 26 Jan 2016, at 09:50, Bless, Roland (TM) = wrote: >=20 > Hi, >=20 > Am 26.01.2016 um 08:30 schrieb Youjianjie: >> Existing work shows that having a latency-bandwidth trade-off = decision >> would be useful. >>=20 >> For example: >> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 >>=20 >> = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >>=20 >> SPUD describes this as one of its use cases. >>=20 >> = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>=20 >> We wonder: how should this be specified? Could we, for example, use = the >> DSCP? If so, how - can we use an existing value, or should we define = a >> new one? >=20 > I think one should distinguish between different cases, e.g., > - Application wants low latency transport > - Application needs bulk transfer and insensitive to latency > - Application uses a congestion control algorithm for achieving low = latency > - etc. >=20 > Moreover, there may exist high-bandwidth applications that also = require > low latency, so that you don't have a tradeoff situation. > One bit isn't enough to distinguish that properly. >=20 > In the DiffServ architecture you better should exactly describe what > kind of per-hop behaviour (PHB) you want for packet treatment. Then > you could use a DSCP that points to that PHB. The EF PHB is also > offering a low delay service, but usually requires admission control, > policing and non-bursty flows. The idea is to provide something simple that avoids having to use = admission control etc. - no QoS in the sense: "you pay more, you get = more", but a trade-off where there's no incentive to lie, and the more = routers support it, the better, generally. > An indication of the transport protocol > that it's going to use a low-delay congestion control mechanism > is a completely different thing. >=20 > I think it would be useful to have a possibility to separate > flows with incompatible congestion control mechanisms, i.e., > to put them into separate queues. We did some experiments > and were able to achieve bandwidth fairness while keeping the > delay for the low-delay congestion controlled flows much lower > compared to the loss-based congestion controlled flows. This sounds as if you're thinking about something slightly different = than us. The question isn't about "how can I protect my delay-based = congestion control mechanism from loss-based mechanisms" but about "how = could I say: drop me if you must, but don't delay me, I prefer that". = That seems pretty binary to me, and as the papers that Jianjie pointed = at show, this simple binary logic can be good enough for a beneficial = outcome. So... any DSCP value that could reasonably be used for that? I mean, in = a way, what this is asking for is to simply give some packets a high = drop precedence, but without associating them with a specific (usually = admission controlled) DiffServ PHB, I guess... Cheers Michael From nobody Tue Jan 26 01:54:42 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5528D1A88D3; Tue, 26 Jan 2016 01:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxtexOvyF83w; Tue, 26 Jan 2016 01:54:36 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id EB56A1A88CF; Tue, 26 Jan 2016 01:54:35 -0800 (PST) Received: from public-docking-cx-1556.ethz.ch (public-docking-pat-cx-mapped-0004.ethz.ch [195.176.111.5]) by trammell.ch (Postfix) with ESMTPSA id 93B6B1A026F; Tue, 26 Jan 2016 10:54:04 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: Date: Tue, 26 Jan 2016 10:54:03 +0100 Message-Id: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> References: To: Youjianjie X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 09:54:38 -0000 --Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jianjie, Our thinking on this in the context of the prototype is either (a) that = the latency tradeoff be bound to a tube (which would require (1) more = than one bit to encode the tradeoff and (2) that the forwarding/queueing = decision also always do a lookup on the tube ID, which is not optimal), = or (b) that one of the reserved bits in cmd/flags be used for this. It does not appear that the current definitions of the DSCP codepoints = would allow compatible reuse of either a single bit or any of the = codepoints as a signal for this tradeoff. One could perhaps go to the = effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for = "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone = with some DSCP expertise to say how difficult this would be. Cheers, Brian > On 26 Jan 2016, at 08:30, Youjianjie wrote: >=20 > Hi, >=20 > Existing work shows that having a latency-bandwidth trade-off decision = would be useful. > For example: = http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 > = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >=20 > SPUD describes this as one of its use cases. > = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >=20 > We wonder: how should this be specified? Could we, for example, use = the DSCP? If so, how - can we use an existing value, or should we define = a new one? >=20 > Regards, > Jianjie --Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWp0I8AAoJEIoSt78L6kajhegQAJBd5DwIj/zDxuMRQ9s1jSqD Usmf5f5/fKcwGkVcgu+tq9A6uRsI1Xv6Lx1ZEeGqJvKRWMHaTtSihVlf8a1TGZnP MIZi25jz48vNhbG9buyc5gDL06JCB1DHYeL0vPzPNi9A85N9noy5XO2xUW4sVDE4 bDgl+FqLBjjHIG7FKk8hdPi23IoAEIbOfFsg9QSI+L31dFW9DgTd2917aUB2NEBv cJ0Gqdg9MEfdBcyMH3RloXGJ5jnwAMZuXI1aQcnZFE/imzgKZJ1NwyOz9DMeT+1O 0bCTryDz5fsFVanBe+YKi1mLu+jeVl5p2yw3gt5XXfHLxj0Jdhd+QNgmtDa/iidt rkeDtuqvyGP6UXmFGwSpBVtCAaKUjCBKH2mJ3hk/bvx6s69t7DWU1DCq6EVB+CII /hqQyGsFnOxtJ+eNW5Z/JQdJRWlU7uy8QZS9cXv//6pSHDR+O0I20mEFMmwDtl/c Ljc72yHyeUSDHIjrGSChlX6viRoZ8Zcn1ziLNLe9b8JQ67WBoujQpNaP54N6skw4 t8zoBegW7vL5PBFIeDhMf7u7fmxbLXFundxcxYDOSiCBelZ61WweKbPec0WP5Ybf aAd3mIEoYnxN0x9VSkq4njTBk5a8roTnfvxEWXiUjid5wxP5ZzmifnSwJcywIbgi 9V9k273Cu0fsVOIv0iB4 =o7NG -----END PGP SIGNATURE----- --Apple-Mail=_7E782E34-EDCE-4182-8819-9B5F01CB6445-- From nobody Tue Jan 26 01:59:33 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B671A88EF; Tue, 26 Jan 2016 01:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjd44tTvlBoC; Tue, 26 Jan 2016 01:59:31 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6319C1A88ED; Tue, 26 Jan 2016 01:59:31 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO0PD-0000N7-JB; Tue, 26 Jan 2016 10:59:23 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO0PD-0000Gb-5Z; Tue, 26 Jan 2016 10:59:23 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> Date: Tue, 26 Jan 2016 10:59:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 8 sum rcpts/h 16 sum msgs/h 10 total rcpts 37510 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E4EDEB33E7C8810D31313402164B74DE20E601E9 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 8986 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Youjianjie , "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 09:59:33 -0000 > On 26 Jan 2016, at 10:54, Brian Trammell wrote: >=20 > hi Jianjie, >=20 > Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >=20 > It does not appear that the current definitions of the DSCP codepoints = would allow compatible reuse of either a single bit or any of the = codepoints as a signal for this tradeoff. One could perhaps go to the = effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for = "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone = with some DSCP expertise to say how difficult this would be. +1 - this is exactly Jianjie and I are asking about... how difficult it = would be, and if folks would consider this reasonable Cheers, Michael From nobody Tue Jan 26 02:10:34 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072551A8940; Tue, 26 Jan 2016 02:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk1sgHcwzsy0; Tue, 26 Jan 2016 02:10:28 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 337521A88F7; Tue, 26 Jan 2016 02:10:28 -0800 (PST) Received: from [IPv6:2001:67c:10ec:52c7:8000::38e] (unknown [IPv6:2001:67c:10ec:52c7:8000::38e]) by trammell.ch (Postfix) with ESMTPSA id 5AA9E1A0023; Tue, 26 Jan 2016 11:09:57 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: Date: Tue, 26 Jan 2016 11:09:56 +0100 Message-Id: <1CDC8606-31D2-4A60-B035-346F5A466B58@trammell.ch> References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Youjianjie , "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 10:10:30 -0000 --Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26 Jan 2016, at 10:59, Michael Welzl wrote: >=20 >=20 >> On 26 Jan 2016, at 10:54, Brian Trammell wrote: >>=20 >> hi Jianjie, >>=20 >> Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >>=20 >> It does not appear that the current definitions of the DSCP = codepoints would allow compatible reuse of either a single bit or any of = the codepoints as a signal for this tradeoff. One could perhaps go to = the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, = for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of = someone with some DSCP expertise to say how difficult this would be. >=20 > +1 - this is exactly Jianjie and I are asking about... how difficult = it would be, and if folks would consider this reasonable I consider it extremely reasonable, but have no idea how difficult it = is. :) Indeed, since a lot of how we're thinking about how tube properties get = implemented by in-network functionality involves things like translating = tube information down to DSCP, MPLS labels, etc, having an explicit DSCP = *in addition to* a SPUD flag for this tradeoff is a win for everyone = IMO. Even if we designate 0b111101 as "latency sensitive / loss tradeoff" and = 0b011101 as "loss sensitive / latency tradeoff", it'll be a (long) while = before you get border devices deployed that would strip AF and EF = codepoints but let these tradeoff codepoints through. For a lot of = platforms I expect you'd need a new configuration language to even be = able to tell your firewall to do that. So I still think we need bits in = both places for a while. Cheers, Brian --Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWp0X1AAoJEIoSt78L6kajJtwP+wYKKw5BkRYpsUS3chE+vaRL zO1BBHuhGfKN7HZxtP8fLyCEOepRjYh+sSUAv23UsAXSWgPJtzoPjTnnew40+Wbh Dv4EEq/kBLfgvr9i2lwNAnQdbVrv90ofpe34thQBmFNMAIDJ/pT5a9GKTwFgMmkU NXSCBjv1+iZSjR7HR3BKHou+nizc9NB+03zc4BdS5qd2bpDD3MQmqv7SkRTa21rT J1osrzYZVQu61y12HQ3jYfdLS27Lzu7dIePkw4iMxK5KE5sFsDu6rIhcN8SMpJxB jEmPi9Uv2FOz62gzozDe2kaUGpDWo6d01ba3gxDzlA2Ej/vclGPM47WnRkeJlwT3 TXjgL+lQ0qORHBiIoCALCrMTuRYGIuWdSqHHnTCGinBUXef35Jc6lfcJNlaM1zzS tkSAbQEgwUvOFbHSt2UdpGqCPE1R3xqbxqq1c20CmHNZN7AJTYJgH/vCOZttOjUH k8p7QhxBDFQZPEp7aUsOS2UqDBefQOTLlf9qbGgplzOcKDILusg6q+XNiv5Vx5dY HRw12a+fezUAU5Oe2i3u3WY3Ny/0VaQiAk7/urDsFje4ZCnKaUGK5cZK2FIbPkI0 +e89cRkB2iW2YV1aXvI1A54z9A3k6vxtURrDD5eaKDyWoYkT72IPzwW1RHonL7mH NBlYcwxZSapSDeJYopBB =9jFH -----END PGP SIGNATURE----- --Apple-Mail=_B0BA5FC9-440E-4C77-BB1C-923451DD4D21-- From nobody Tue Jan 26 03:14:26 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210051AD0B8; Tue, 26 Jan 2016 03:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJgucP82xHxy; Tue, 26 Jan 2016 03:14:21 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD01B1AD06F; Tue, 26 Jan 2016 03:14:20 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO1Zh-0004Iz-W1; Tue, 26 Jan 2016 12:14:17 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO1Zh-0006yR-Ek; Tue, 26 Jan 2016 12:14:17 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <1CDC8606-31D2-4A60-B035-346F5A466B58@trammell.ch> Date: Tue, 26 Jan 2016 12:14:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A63816A-8DC5-4138-BCAE-FC0CEBEC5A25@ifi.uio.no> References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> <1CDC8606-31D2-4A60-B035-346F5A466B58@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 12 sum msgs/h 6 total rcpts 37514 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E8AADADB93553E7166FE59C740E59A3D75089B4C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 8987 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Youjianjie , "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 11:14:23 -0000 > On 26 Jan 2016, at 11:09, Brian Trammell wrote: >=20 >=20 >> On 26 Jan 2016, at 10:59, Michael Welzl wrote: >>=20 >>=20 >>> On 26 Jan 2016, at 10:54, Brian Trammell wrote: >>>=20 >>> hi Jianjie, >>>=20 >>> Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >>>=20 >>> It does not appear that the current definitions of the DSCP = codepoints would allow compatible reuse of either a single bit or any of = the codepoints as a signal for this tradeoff. One could perhaps go to = the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, = for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of = someone with some DSCP expertise to say how difficult this would be. >>=20 >> +1 - this is exactly Jianjie and I are asking about... how difficult = it would be, and if folks would consider this reasonable >=20 > I consider it extremely reasonable, but have no idea how difficult it = is. :) >=20 > Indeed, since a lot of how we're thinking about how tube properties = get implemented by in-network functionality involves things like = translating tube information down to DSCP, MPLS labels, etc, having an = explicit DSCP *in addition to* a SPUD flag for this tradeoff is a win = for everyone IMO. >=20 > Even if we designate 0b111101 as "latency sensitive / loss tradeoff" = and 0b011101 as "loss sensitive / latency tradeoff", it'll be a (long) = while before you get border devices deployed that would strip AF and EF = codepoints but let these tradeoff codepoints through. For a lot of = platforms I expect you'd need a new configuration language to even be = able to tell your firewall to do that. So I still think we need bits in = both places for a while. I agree with everything here. Cheers Michael From nobody Tue Jan 26 08:37:08 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13031B30AE for ; Tue, 26 Jan 2016 08:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npojvvVDPqB6 for ; Tue, 26 Jan 2016 08:37:00 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90EE1B30AD for ; Tue, 26 Jan 2016 08:36:59 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1aO6bv-0002Rj-D7; Tue, 26 Jan 2016 17:36:55 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 49004B00E73; Tue, 26 Jan 2016 17:36:55 +0100 (CET) To: Michael Welzl References: <56A73348.70504@kit.edu> <361E6EA9-0886-452D-96B4-A4FC4277A4B9@ifi.uio.no> From: "Bless, Roland (TM)" X-Enigmail-Draft-Status: N1110 Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <56A7A0A7.4060603@kit.edu> Date: Tue, 26 Jan 2016 17:36:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <361E6EA9-0886-452D-96B4-A4FC4277A4B9@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1453826215. Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 16:37:07 -0000 Hi Michael, [see comments inline...] Am 26.01.2016 um 10:11 schrieb Michael Welzl: >> On 26 Jan 2016, at 09:50, Bless, Roland (TM) wrote: >> >> Hi, >> >> Am 26.01.2016 um 08:30 schrieb Youjianjie: >>> Existing work shows that having a latency-bandwidth trade-off decision >>> would be useful. >>> >>> For example: >>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942 >>> >>> http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf >>> >>> SPUD describes this as one of its use cases. >>> >>> https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>> >>> We wonder: how should this be specified? Could we, for example, use the >>> DSCP? If so, how - can we use an existing value, or should we define a >>> new one? >> >> I think one should distinguish between different cases, e.g., >> - Application wants low latency transport >> - Application needs bulk transfer and insensitive to latency >> - Application uses a congestion control algorithm for achieving low latency >> - etc. >> >> Moreover, there may exist high-bandwidth applications that also require >> low latency, so that you don't have a tradeoff situation. >> One bit isn't enough to distinguish that properly. >> >> In the DiffServ architecture you better should exactly describe what >> kind of per-hop behaviour (PHB) you want for packet treatment. Then >> you could use a DSCP that points to that PHB. The EF PHB is also >> offering a low delay service, but usually requires admission control, >> policing and non-bursty flows. > The idea is to provide something simple that avoids having to use > admission control etc. - no QoS in the sense: "you pay more, you get > more", but a trade-off where there's no incentive to lie, and the more > routers support it, the better, generally. I was just pointing to the fact that there are many ways of achieving a low latency service and that a DSCP normally points to a PHB definition. >> An indication of the transport protocol >> that it's going to use a low-delay congestion control mechanism >> is a completely different thing. >> >> I think it would be useful to have a possibility to separate >> flows with incompatible congestion control mechanisms, i.e., >> to put them into separate queues. We did some experiments >> and were able to achieve bandwidth fairness while keeping the >> delay for the low-delay congestion controlled flows much lower >> compared to the loss-based congestion controlled flows. > This sounds as if you're thinking about something slightly different > than us. The question isn't about "how can I protect my delay-based > congestion control mechanism from loss-based mechanisms" but about "how > could I say: drop me if you must, but don't delay me, I prefer that". Thanks for clarification. I just gave an example that the latency vs. throughput could mean various things and it's better to exactly define the intended behavior. We already had a very fuzzy indication with the ToS bits and that didn't work out very well in practice. So the "drop me if you must, but don't delay me, I prefer that." policy can be realized in various ways and one should be more precise what that means. > That seems pretty binary to me, and as the papers that Jianjie pointed > at show, this simple binary logic can be good enough for a beneficial > outcome. > > So... any DSCP value that could reasonably be used for that? I mean, > in a way, what this is asking for is to simply give some packets a high > drop precedence, but without associating them with a specific (usually > admission controlled) DiffServ PHB, I guess... Usually, admission control is only required for achieving strict guarantees, so a PHB definition doesn't require that. However, specifying queues, their behavior/management and scheduling mechanisms for such a forwarding strategy is exactly what a PHB definition describes (at least). Regards, Roland From nobody Tue Jan 26 08:52:54 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8439F1B30E5 for ; Tue, 26 Jan 2016 08:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSJdshu2Gd3m for ; Tue, 26 Jan 2016 08:52:51 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCC41B30E2 for ; Tue, 26 Jan 2016 08:52:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D8F74D930D for ; Tue, 26 Jan 2016 17:52:48 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XuYjaMbq6Het for ; Tue, 26 Jan 2016 17:52:48 +0100 (MET) Received: from [192.168.178.33] (x5f719647.dyn.telefonica.de [95.113.150.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 76A66D9303 for ; Tue, 26 Jan 2016 17:52:48 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <56A73348.70504@kit.edu> Date: Tue, 26 Jan 2016 17:52:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <805CD933-4D64-4188-BF9C-0D3ACAAB5AC8@tik.ee.ethz.ch> References: <56A73348.70504@kit.edu> To: spud@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 16:52:53 -0000 Hi, the idea for signaling here is to use a field/bit in some kind of new = spud shim-layer/header where the intention is to have a way to = explicitly communicate with middleboxes (instead of using whatever they = can find in other headers). Other than DSCP, we do not assume any = guarantees or specific treatment regarding what the network/middlebox = will do with this information; it=E2=80=99s simply an indication by the = endpoint to the middle.=20 Further having a low latency vs. low drop signal, always provides a = trade-off. Of course that=E2=80=99s not optimal for all applications but = could help a lot of them a lot. And having this trade-off there is also = no incentive and no advantage in lying about this information (as an = application would simply get the wrong treatment while there nothing = like a priority assigned here). Mirja > Am 26.01.2016 um 09:50 schrieb Bless, Roland (TM) = : >=20 > Hi, >=20 > Am 26.01.2016 um 08:30 schrieb Youjianjie: >> Existing work shows that having a latency-bandwidth trade-off = decision >> would be useful. >>=20 >> For example: >> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 >>=20 >> = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >>=20 >> SPUD describes this as one of its use cases. >>=20 >> = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>=20 >> We wonder: how should this be specified? Could we, for example, use = the >> DSCP? If so, how - can we use an existing value, or should we define = a >> new one? >=20 > I think one should distinguish between different cases, e.g., > - Application wants low latency transport > - Application needs bulk transfer and insensitive to latency > - Application uses a congestion control algorithm for achieving low = latency > - etc. >=20 > Moreover, there may exist high-bandwidth applications that also = require > low latency, so that you don't have a tradeoff situation. > One bit isn't enough to distinguish that properly. >=20 > In the DiffServ architecture you better should exactly describe what > kind of per-hop behaviour (PHB) you want for packet treatment. Then > you could use a DSCP that points to that PHB. The EF PHB is also > offering a low delay service, but usually requires admission control, > policing and non-bursty flows. An indication of the transport protocol > that it's going to use a low-delay congestion control mechanism > is a completely different thing. >=20 > I think it would be useful to have a possibility to separate > flows with incompatible congestion control mechanisms, i.e., > to put them into separate queues. We did some experiments > and were able to achieve bandwidth fairness while keeping the > delay for the low-delay congestion controlled flows much lower > compared to the loss-based congestion controlled flows. >=20 > Regards, > Roland >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud From nobody Tue Jan 26 09:12:28 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998C91A1A04 for ; Tue, 26 Jan 2016 09:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrptCRgwuhIZ for ; Tue, 26 Jan 2016 09:12:25 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21CF1A905E for ; Tue, 26 Jan 2016 09:12:20 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO7AA-0003fu-Tl; Tue, 26 Jan 2016 18:12:18 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO7AA-0005v9-BD; Tue, 26 Jan 2016 18:12:18 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <56A7A0A7.4060603@kit.edu> Date: Tue, 26 Jan 2016 18:12:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D73E98C-8CB2-4030-8EE9-4872E5BFBE53@ifi.uio.no> References: <56A73348.70504@kit.edu> <361E6EA9-0886-452D-96B4-A4FC4277A4B9@ifi.uio.no> <56A7A0A7.4060603@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 37553 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4D3FAB3E373B280139361C8951D32091F5DDA267 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9005 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:12:27 -0000 Thanks a lot Roland! More below - > On 26 Jan 2016, at 17:36, Bless, Roland (TM) = wrote: >=20 > Hi Michael, >=20 > [see comments inline...] >=20 > Am 26.01.2016 um 10:11 schrieb Michael Welzl: >>> On 26 Jan 2016, at 09:50, Bless, Roland (TM) = wrote: >>>=20 >>> Hi, >>>=20 >>> Am 26.01.2016 um 08:30 schrieb Youjianjie: >>>> Existing work shows that having a latency-bandwidth trade-off = decision >>>> would be useful. >>>>=20 >>>> For example: >>>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 >>>>=20 >>>> = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >>>>=20 >>>> SPUD describes this as one of its use cases. >>>>=20 >>>> = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>>>=20 >>>> We wonder: how should this be specified? Could we, for example, use = the >>>> DSCP? If so, how - can we use an existing value, or should we = define a >>>> new one? >>>=20 >>> I think one should distinguish between different cases, e.g., >>> - Application wants low latency transport >>> - Application needs bulk transfer and insensitive to latency >>> - Application uses a congestion control algorithm for achieving low = latency >>> - etc. >>>=20 >>> Moreover, there may exist high-bandwidth applications that also = require >>> low latency, so that you don't have a tradeoff situation. >>> One bit isn't enough to distinguish that properly. >>>=20 >>> In the DiffServ architecture you better should exactly describe what >>> kind of per-hop behaviour (PHB) you want for packet treatment. Then >>> you could use a DSCP that points to that PHB. The EF PHB is also >>> offering a low delay service, but usually requires admission = control, >>> policing and non-bursty flows. >=20 >> The idea is to provide something simple that avoids having to use >> admission control etc. - no QoS in the sense: "you pay more, you get >> more", but a trade-off where there's no incentive to lie, and the = more >> routers support it, the better, generally. >=20 > I was just pointing to the fact that there are many ways of achieving = a > low latency service and that a DSCP normally points to a PHB = definition. >=20 >>> An indication of the transport protocol >>> that it's going to use a low-delay congestion control mechanism >>> is a completely different thing. >>>=20 >>> I think it would be useful to have a possibility to separate >>> flows with incompatible congestion control mechanisms, i.e., >>> to put them into separate queues. We did some experiments >>> and were able to achieve bandwidth fairness while keeping the >>> delay for the low-delay congestion controlled flows much lower >>> compared to the loss-based congestion controlled flows. >=20 >> This sounds as if you're thinking about something slightly different >> than us. The question isn't about "how can I protect my delay-based >> congestion control mechanism from loss-based mechanisms" but about = "how >> could I say: drop me if you must, but don't delay me, I prefer that". >=20 > Thanks for clarification. I just gave an example that the latency vs. > throughput could mean various things and it's better to exactly define > the intended behavior. We already had a very fuzzy indication with the > ToS bits and that didn't work out very well in practice. So the "drop > me if you must, but don't delay me, I prefer that." policy can be > realized in various ways and one should be more precise what that = means. >=20 >> That seems pretty binary to me, and as the papers that Jianjie = pointed >> at show, this simple binary logic can be good enough for a beneficial >> outcome. >>=20 >> So... any DSCP value that could reasonably be used for that? I mean, >> in a way, what this is asking for is to simply give some packets a = high >> drop precedence, but without associating them with a specific = (usually >> admission controlled) DiffServ PHB, I guess... >=20 > Usually, admission control is only required for achieving strict > guarantees, so a PHB definition doesn't require that. However, > specifying queues, their behavior/management and scheduling mechanisms > for such a forwarding strategy is exactly what a PHB definition > describes (at least). Ah ok! If I interpret this correctly, this means that if we need = something probabilistically, we should just go ahead and DSCP-mark as = desired, maybe using table 1 in = https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-10 right? (not at all unreasonable, I think) Cheers, Michael From nobody Tue Jan 26 11:50:47 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01D1B2BD4; Tue, 26 Jan 2016 11:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6n_OWlcyyzS; Tue, 26 Jan 2016 11:20:01 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696B21B2BD2; Tue, 26 Jan 2016 11:20:01 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id q63so106260488pfb.1; Tue, 26 Jan 2016 11:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=mG//Rm+F/C7dgOzH7JDHlTBAr4vnIivowPaUtU0T69w=; b=QV5RJg3Kk5HTnXlww76MhOAes4bc3noR9cedViQs1VPmQUCJfnIsVtgtMVENoe0Lmy +zLR+NmyvMtNvuugwwmMeYzKuxti7DtNFskS8Zo/yvXQ6YobE5tO/tf+8/j8G+uMU4A6 aM9MnQeogUvg0eazdG2FGHlI+me6z3Z3iZzUEGdWYrGsylqFIY6Dlcf2BNj1FMjG8Kp7 5pu6NHX8/h5SF7H1AfnFdJpqP9fN43o546Mv5mTVUziW17uIO6I/8MHzIXyc6ziQZzpQ kdV1o7pOE6v4XRfR8aSpe9XSVPcPwHD0/TLJFM/6ANfHwREuYeH+7rhTJ5wYJEfCs/CM 4uZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=mG//Rm+F/C7dgOzH7JDHlTBAr4vnIivowPaUtU0T69w=; b=mizIqcn+iOmRAMM788AXuFMTHko/4yHxtyBMO4JhZGjxOdMS1cvZl+Y5HEdITqoLOg +r/ic4qO/4+lVFVjawo7D1tTRgYhOukjx5I3XH510m3xAkgmcCvSv5wKhED3DMaPXfHh gbEeN7aTdeFPKX1kiGR+NiaQiF+GziKQF7caMl3yAyZ2i3o5iJ6wPPJ8hDB24JZbOhQj g4C1RbaMPr6qd5jih8X89/l3HLdc6NXvRhHJ9B08Y7Z7PsrpVxsVKZujgi6Ywl3LhfrR CarIUG+glDZI9k0FrEaYyWrpuyhJXcQvqIaa+qocleirxcTiKtHfF8I3qWXpY+9WEfVB AVEQ== X-Gm-Message-State: AG10YOQLXcSyGBXXqfqwJZwezBUeIY2a0Vg6kEdoO7KHz6Dqf8ChwzqSqMfep7kdDlNizg== X-Received: by 10.98.66.74 with SMTP id p71mr36177055pfa.105.1453836001096; Tue, 26 Jan 2016 11:20:01 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m75sm3549351pfj.38.2016.01.26.11.19.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 11:19:59 -0800 (PST) To: Brian Trammell , Youjianjie References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A7C6E2.40401@gmail.com> Date: Wed, 27 Jan 2016 08:20:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 26 Jan 2016 11:50:46 -0800 Cc: "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:20:04 -0000 On 26/01/2016 22:54, Brian Trammell wrote: > hi Jianjie, > > Our thinking on this in the context of the prototype is either (a) that the latency tradeoff be bound to a tube (which would require (1) more than one bit to encode the tradeoff and (2) that the forwarding/queueing decision also always do a lookup on the tube ID, which is not optimal), or (b) that one of the reserved bits in cmd/flags be used for this. > > It does not appear that the current definitions of the DSCP codepoints would allow compatible reuse of either a single bit or any of the codepoints as a signal for this tradeoff. One could perhaps go to the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone with some DSCP expertise to say how difficult this would be. Can you define the relevant per-hop behaviours precisely? That's the only formal requirement of RFC2474 section 5. Are they implementable at line speed? BTW, the choice between EF and not-EF is to a large extent a latency/throughput choice. EF is supposed to provide bounded latency and jitter within bounded throughput. RFC 3248 and RFC 3246 are all about bounded latency. Low latency, low jitter, high throughput: pick any two. Brian C > > Cheers, > > Brian > > > >> On 26 Jan 2016, at 08:30, Youjianjie wrote: >> >> Hi, >> >> Existing work shows that having a latency-bandwidth trade-off decision would be useful. >> For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942 >> http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf >> >> SPUD describes this as one of its use cases. >> https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >> >> We wonder: how should this be specified? Could we, for example, use the DSCP? If so, how - can we use an existing value, or should we define a new one? >> >> Regards, >> Jianjie > From nobody Tue Jan 26 12:20:40 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F11B2CCA; Tue, 26 Jan 2016 12:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HybhKTVsdvwl; Tue, 26 Jan 2016 12:20:37 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id AC4EE1B2CC1; Tue, 26 Jan 2016 12:20:36 -0800 (PST) Received: from [10.0.27.116] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 4F5F61A026F; Tue, 26 Jan 2016 21:20:35 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: <56A7C6E2.40401@gmail.com> Date: Tue, 26 Jan 2016 21:20:34 +0100 Message-Id: <112CE360-529A-4076-8E52-B7758798EC62@trammell.ch> References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> <56A7C6E2.40401@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Youjianjie , "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 20:20:39 -0000 --Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian (C), > On 26 Jan 2016, at 20:20, Brian E Carpenter = wrote: >=20 > On 26/01/2016 22:54, Brian Trammell wrote: >> hi Jianjie, >>=20 >> Our thinking on this in the context of the prototype is either (a) = that the latency tradeoff be bound to a tube (which would require (1) = more than one bit to encode the tradeoff and (2) that the = forwarding/queueing decision also always do a lookup on the tube ID, = which is not optimal), or (b) that one of the reserved bits in cmd/flags = be used for this. >>=20 >> It does not appear that the current definitions of the DSCP = codepoints would allow compatible reuse of either a single bit or any of = the codepoints as a signal for this tradeoff. One could perhaps go to = the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, = for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of = someone with some DSCP expertise to say how difficult this would be. >=20 > Can you define the relevant per-hop behaviours precisely? That's the = only formal > requirement of RFC2474 section 5. There are a couple of possible definitions. The simplest I can think of, = which probably has issues in the margins due to the fact that it has to = be evaluated per-hop without any accumulated path information: (1) if the Latency Tradeoff codepoint is set, the device should drop the = packet if it would otherwise impart more than N (configurable?) queueing = delay. (This is the "don't bufferbloat me!" codepoint, and is the = default for hypothetical devices with very short queues and no AQM) (2) if the Loss Tradeoff codepoint is set, the device should queue the = packet for as long as it has buffer capacity. (This is the "please = bufferbloat me!" codepoint, and indeed the default for devices with a = single big queue and no AQM). The simplest way to implement this is with two queues: one with a very = short queue, one with a much longer queue, with a transmission algorithm = that tends to drain the short one first, but does not assign strict = priority to the short one. Lots of proposals in this space (indeed, I = think discussed in TSV) that would point the way toward the right = configuration here. > Are they implementable at line speed? Since in the two-queue case it's merely a queueing decision, yes. > BTW, the choice between EF and not-EF is to a large extent a = latency/throughput choice. > EF is supposed to provide bounded latency and jitter within bounded = throughput. > RFC 3248 and RFC 3246 are all about bounded latency. Thanks for the reply... I briefly looked over these before answering and = EF seemed also to request low loss for defined throughput, which is... = not really the same thing. Cheers, Brian (T) > Low latency, low jitter, high throughput: pick any two. >=20 > Brian C >=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >>=20 >>=20 >>> On 26 Jan 2016, at 08:30, Youjianjie wrote: >>>=20 >>> Hi, >>>=20 >>> Existing work shows that having a latency-bandwidth trade-off = decision would be useful. >>> For example: = http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D923942 >>> = http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_= 2008.pdf >>>=20 >>> SPUD describes this as one of its use cases. >>> = https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>>=20 >>> We wonder: how should this be specified? Could we, for example, use = the DSCP? If so, how - can we use an existing value, or should we define = a new one? >>>=20 >>> Regards, >>> Jianjie >>=20 >=20 > _______________________________________________ > Spud mailing list > Spud@ietf.org > https://www.ietf.org/mailman/listinfo/spud --Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWp9UTAAoJEIoSt78L6kajZ88P/2/xqV8U2XUpoyWmdY1o2VbV m7gSlP5YHna7nOxo0MscWwvZ0lT0iOMq7A7AEX/krNo1C9f4iuzjLTJ37+OmlaNk KxQzBje0g6/HiC00q8jgGcbYVLz8GXUh/Xw6HM0dogvVRpvKS7QAZf8Ez8uBenQk LKe2BhdQAHPNeH+PwsYMjqUkQyBfm2ow2cSY0pu9lciwaKVIA/lGqsgEQ4CFBbBI Twv/Ck+hFdoUqu7jrO3mjl1hMNW/8CaCpDUMea7YeeJgsiHdWdoQ3dY2KoqFaZIK 1atwbHT8H/IdPM7dKFElY7jAwQOBOBbCyrXXJa0BxJqPhB3nA515qMkaHap/A+Tt FllMWtBVTx6j+QPEl+MYwus3XeQgiA7u43n5T1tOb63ItynSv/0WM1LwrHyrpbxa 1xgQjYhnRAZFzK5x/WFk+a/ThJVrXyvNCr/TKzz3oaD4WZ6vsNG7jau2YW94+jvQ kK1R/Wro7C8Te96lNDHd+/QjUkviLYNJFl5LElEoRL9a8HDZYMMCcmOcNKAzq1Ab WvzxAX5vARl3f0XuxAcI7ZktoFusdbQnNsgyz/Nd6FI7J3FSVqU8u/yWKJ9RQlu1 MedmmXuAf9P/vPkIYzPEoek87lVvgsCoHPuvRA/xVlRl83SeuYQs52I5c28VreP8 UzXIWY5HzSZDJJ4fUd44 =dP5N -----END PGP SIGNATURE----- --Apple-Mail=_47E23A8F-4ADA-4C1C-9604-5BB927E1CC61-- From nobody Tue Jan 26 12:37:41 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07DA1B2D27 for ; Tue, 26 Jan 2016 12:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0c2UItwfSkk for ; Tue, 26 Jan 2016 12:37:38 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C877C1B2D21 for ; Tue, 26 Jan 2016 12:37:37 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aOAMq-0001GX-4a; Tue, 26 Jan 2016 21:37:36 +0100 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aOAMp-0001mX-KM; Tue, 26 Jan 2016 21:37:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Michael Welzl In-Reply-To: <805CD933-4D64-4188-BF9C-0D3ACAAB5AC8@tik.ee.ethz.ch> Date: Tue, 26 Jan 2016 21:37:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56A73348.70504@kit.edu> <805CD933-4D64-4188-BF9C-0D3ACAAB5AC8@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3112) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 5 sum msgs/h 4 total rcpts 37559 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A0D473AEA3F7AA983E6DDF9E88DF0CAB64D6BDB9 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 263 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: spud@ietf.org Subject: Re: [Spud] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 20:37:39 -0000 > On 26. jan. 2016, at 17.52, Mirja K=C3=BChlewind = wrote: >=20 > Hi, >=20 > the idea for signaling here is to use a field/bit in some kind of new = spud shim-layer/header where the intention is to have a way to = explicitly communicate with middleboxes (instead of using whatever they = can find in other headers). Other than DSCP, we do not assume any = guarantees or specific treatment regarding what the network/middlebox = will do with this information; it=E2=80=99s simply an indication by the = endpoint to the middle.=20 Just like draft-ietf-tsvwg-rtcweb-qos, I=E2=80=99d think?! Also no = guarantees there=E2=80=A6 > Further having a low latency vs. low drop signal, always provides a = trade-off. Of course that=E2=80=99s not optimal for all applications but = could help a lot of them a lot. And having this trade-off there is also = no incentive and no advantage in lying about this information (as an = application would simply get the wrong treatment while there nothing = like a priority assigned here). To me, that=E2=80=99s what makes the idea so attractive (as in the = papers Jianjie pointed to). It makes me wonder, are there lying = incentives in draft-ietf-tsvwg-rtcweb-qos ? Cheers, Michael From nobody Tue Jan 26 16:21:10 2016 Return-Path: X-Original-To: spud@ietfa.amsl.com Delivered-To: spud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F231A039F; Tue, 26 Jan 2016 16:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZL0I0dcCcL8; Tue, 26 Jan 2016 16:21:05 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275F11A03A2; Tue, 26 Jan 2016 16:21:05 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id ho8so105649695pac.2; Tue, 26 Jan 2016 16:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=O+hDWVCTiAHt1TdVAEysKqRaJFd2lCX2dj8WF0Y20xI=; b=NYLDEERgwKVdosYdT4CJTTCHhX4p4rWI783mCk3GS9TD/6uT/2H3ZS9RvbNq0gEjMd QVKyTIrf61EuN1sRRmKqKw6WnoblUkSe1hWd5hxHQ70sKBoBue/Z+1+1/THErcw42iqf TNjWxGDGmq1NKf2A7kHSvTfXRgeTXw86GjTvi4NkPOyOel+GrzaxVl4993F9uULkeXx4 WyeRMujhBwYfcMkjfS12fRA4J0bLoPgSzqWCpKNkeUZ4d4EvO4yMKWWE3pHQawcpSenh uIMpHU0Y/84KKV2o7izeZmbeUAnJ2t1pSWl3iXNXGJyBnym4lsJEN9/uhUqOB15bOb61 aj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=O+hDWVCTiAHt1TdVAEysKqRaJFd2lCX2dj8WF0Y20xI=; b=gFt8EaggKoq9H9EfdQLzLG4ZXgeXlikw0nfGbOO9O2K2fvjSCB/nyxpGtLsUgZOZeu Oc5bM58zPNxkNjpwzRVxKmhl/ogVmXBSL+e6ur0LrFlR8uSnKvD16uu4TbjBZ6GJ7EGG YXnyTOsw3s7IDblVeddFPSdMnBk0j2AHO+3lS7xrzoAR+hUP4ClArriHC+Y2A/MszwB1 MLDmH31ocfSCGu5/9SCTP6U9UF+69sFaVrbWfPhr3yvmczgmAQhAmtpA5pjqS2AUTIx7 V+zykpkbDASVbID/wjvHaZhDEzhmJiaY2grNyRyGsG6snkq2tyEO+AcgIJ4NzEEyfec0 r4nA== X-Gm-Message-State: AG10YOSFC6eUV3QewwuCvOf6XwKe/X/SPSoVkpuyjlDXMgaMWqv00dM5UlbGnRWWlCGrzQ== X-Received: by 10.67.6.67 with SMTP id cs3mr38256580pad.143.1453854064788; Tue, 26 Jan 2016 16:21:04 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z3sm4312716par.17.2016.01.26.16.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 16:21:03 -0800 (PST) To: Brian Trammell References: <6D09F965-7694-4805-BDC8-4A6F0D1D1F6B@trammell.ch> <56A7C6E2.40401@gmail.com> <112CE360-529A-4076-8E52-B7758798EC62@trammell.ch> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A80D72.5020000@gmail.com> Date: Wed, 27 Jan 2016 13:21:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <112CE360-529A-4076-8E52-B7758798EC62@trammell.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Youjianjie , "tsvwg@ietf.org" , "spud@ietf.org" Subject: Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff X-BeenThere: spud@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Session Protocol Underneath Datagrams List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:21:07 -0000 On 27/01/2016 09:20, Brian Trammell wrote: > Hi Brian (C), > >> On 26 Jan 2016, at 20:20, Brian E Carpenter wrote: >> >> On 26/01/2016 22:54, Brian Trammell wrote: >>> hi Jianjie, >>> >>> Our thinking on this in the context of the prototype is either (a) that the latency tradeoff be bound to a tube (which would require (1) more than one bit to encode the tradeoff and (2) that the forwarding/queueing decision also always do a lookup on the tube ID, which is not optimal), or (b) that one of the reserved bits in cmd/flags be used for this. >>> >>> It does not appear that the current definitions of the DSCP codepoints would allow compatible reuse of either a single bit or any of the codepoints as a signal for this tradeoff. One could perhaps go to the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone with some DSCP expertise to say how difficult this would be. >> >> Can you define the relevant per-hop behaviours precisely? That's the only formal >> requirement of RFC2474 section 5. > > There are a couple of possible definitions. The simplest I can think of, which probably has issues in the margins due to the fact that it has to be evaluated per-hop without any accumulated path information: > > (1) if the Latency Tradeoff codepoint is set, the device should drop the packet if it would otherwise impart more than N (configurable?) queueing delay. (This is the "don't bufferbloat me!" codepoint, and is the default for hypothetical devices with very short queues and no AQM) > > (2) if the Loss Tradeoff codepoint is set, the device should queue the packet for as long as it has buffer capacity. (This is the "please bufferbloat me!" codepoint, and indeed the default for devices with a single big queue and no AQM). I don't see any intrinsic issue in writing PHB specifications for that. Of course, getting IETF standards track consensus is another matter. > The simplest way to implement this is with two queues: one with a very short queue, one with a much longer queue, with a transmission algorithm that tends to drain the short one first, but does not assign strict priority to the short one. Lots of proposals in this space (indeed, I think discussed in TSV) that would point the way toward the right configuration here. > >> Are they implementable at line speed? > > Since in the two-queue case it's merely a queueing decision, yes. Right, which is what I've always seen as the hallmark of deployable diffserv. > >> BTW, the choice between EF and not-EF is to a large extent a latency/throughput choice. >> EF is supposed to provide bounded latency and jitter within bounded throughput. >> RFC 3248 and RFC 3246 are all about bounded latency. > > Thanks for the reply... I briefly looked over these before answering and EF seemed also to request low loss for defined throughput, which is... not really the same thing. True, EF wants a lot (which is why we always assumed it would only be granted a smallish fraction of link capacity, so that its other requirements would leave plenty of space-time for other flows). Brian > > Cheers, > > Brian (T) > >> Low latency, low jitter, high throughput: pick any two. >> >> Brian C >> >>> >>> Cheers, >>> >>> Brian >>> >>> >>> >>>> On 26 Jan 2016, at 08:30, Youjianjie wrote: >>>> >>>> Hi, >>>> >>>> Existing work shows that having a latency-bandwidth trade-off decision would be useful. >>>> For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942 >>>> http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf >>>> >>>> SPUD describes this as one of its use cases. >>>> https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4 >>>> >>>> We wonder: how should this be specified? Could we, for example, use the DSCP? If so, how - can we use an existing value, or should we define a new one? >>>> >>>> Regards, >>>> Jianjie >>> >> >> _______________________________________________ >> Spud mailing list >> Spud@ietf.org >> https://www.ietf.org/mailman/listinfo/spud >