From bob.briscoe@bt.com Fri Mar 1 10:11:05 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A8221E80CA for ; Fri, 1 Mar 2013 10:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z1NVjw7k-2P for ; Fri, 1 Mar 2013 10:11:05 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id A550E21E80C1 for ; Fri, 1 Mar 2013 10:11:00 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 1 Mar 2013 18:10:54 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 1 Mar 2013 18:10:55 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.318.4; Fri, 1 Mar 2013 18:10:54 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.153]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r21IArM2010319 for ; Fri, 1 Mar 2013 18:10:54 GMT Message-ID: <201303011810.r21IArM2010319@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 1 Mar 2013 18:10:53 +0000 To: ConEx IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [conex] Test X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:11:05 -0000 ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Tue Mar 5 01:53:25 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFB021F8891 for ; Tue, 5 Mar 2013 01:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PeXIZQL9ezpf for ; Tue, 5 Mar 2013 01:53:19 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2D21F87E7 for ; Tue, 5 Mar 2013 01:53:18 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 5 Mar 2013 09:53:17 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 5 Mar 2013 09:53:16 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Tue, 5 Mar 2013 09:53:13 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.223]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r259rCTS000573; Tue, 5 Mar 2013 09:53:12 GMT Message-ID: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 5 Mar 2013 09:53:12 +0000 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:53:25 -0000 Matt, The solution to the access link part of this problem is explained in: It can only distinguish access link congestion from shared congestion. Distinguishing home network congestion is harder, but possible with a tunnel to the home router, which already exists in some DSL arrangements (e.g. in BT we use a tunnel for services that share a line). Bob At 22:18 04/03/2013, Matt Mathis wrote: >I have an interesting problem that I wish ConEx could solve, but I >don't see how. I want to distinguish between congestion on the path >between a server and a subscriber aggregation point (e.g. DSLAM etc) >and congestion beyond the aggregation point (e.g. the access links >themselves, or the user's home network). > >There are some ways to infer this, but as far as I can tell there is >not a reasonable way to measure it directly. This is a problem that >we have touched on in the past, but I don't recall discussing any >solutions. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > >Privacy matters! We know from recent events that people are using our >services to speak in defiance of unjust governments. We treat >privacy and security as matters of life and death, because for some >users, they are. ________________________________________________________________ Bob Briscoe, BT From mattmathis@google.com Tue Mar 5 09:36:40 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4C81F0D12 for ; Tue, 5 Mar 2013 09:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3oFLrnor3Nkj for ; Tue, 5 Mar 2013 09:36:36 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6E61F0D0F for ; Tue, 5 Mar 2013 09:36:35 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id h8so1175893iaa.29 for ; Tue, 05 Mar 2013 09:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7SkN3/d0U2KOopu30gwNrFd3jiLmJOdsLg0ZhqUOMA4=; b=FwomFJpcBPVtJorUDJAdMVV0lp4FwNZ1o0tfz7dUwDJDiM5FbMvbROFOSHqzkNoR9n XGMiR7SaiFj2dWSTGcx7lyXHYFXw2S9aZuHHT3UfP+/c5lwAFWLl/fU110kiZYJ3hbj3 pDsyZ8te8Bm1hFp2Yawqhe4AVjA2xcqZYtzPlfaBOLzTj1Oe5uuGn1uzsnawV9/NFfYW VAVb5DahyCBMy52b0DsoVbmazSE5THbUgt/8gXO98UVUHs3fsQaKsTwVnSLH7jb5Iryn QcyOivb3rYEbZ5lJ0+9onZDUj9AF3AqEi6FtIk2kmcw9JXncJgrgPossO3u8pb083CA5 AwYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=7SkN3/d0U2KOopu30gwNrFd3jiLmJOdsLg0ZhqUOMA4=; b=odEg/jWUa5+eQaffIBdoBj6JY8Qxp78VvXvcRgKau2h7ZJxWSGfyWLtKkWxdqC7cQn rvLx5bwd8JBaUvEtHGfrrML/aYQ4PKeEvczn4OjuD2oYCtCI07xo2NAUv31LFE23HDI9 ZH/sI0UYCUxVEQfIlUz/a3zHcwn3xGLHdvK5xC83OJ02jg/Nu/AOF3UTqkL0k86G/Jbd 0lJIzEYFi2Rw1+V9+ZWkiQHb5D47z3Xrlj7jrFru4Cx61LDWqrtSTpc9yW9wk1S/q2dU 1OSTR8E9teflYU++eDGq2l045qxChZxOG9dGWBfXFA3r+Qyx+rhS0QvU6HKqf7jn7uI1 /FJw== MIME-Version: 1.0 X-Received: by 10.50.100.167 with SMTP id ez7mr6914343igb.3.1362504994607; Tue, 05 Mar 2013 09:36:34 -0800 (PST) Received: by 10.64.252.100 with HTTP; Tue, 5 Mar 2013 09:36:34 -0800 (PST) In-Reply-To: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> Date: Tue, 5 Mar 2013 09:36:34 -0800 Message-ID: From: Matt Mathis To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmXEzc98bFDb+0Tdb8WTCb/6/7yDkUVS04DDeb6ZfbIrYWe4s/IPzF2XNHQkBgOXQd847AlY27W08JdchQOyV6iREFQiiIA0Z0dmpxbioF4aT3sN1fRZUi1do/DEewHc5GI7zgUOlIzbtdu88jkEDI5FywKfEHzFlh1wbBVmTJw43OgurYtU2INivBJfhyvbG4NH6E3 Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:36:40 -0000 Bob, I do know how to do it from the ISP's vantage point. It is a bit harder from the content provider's vantage point. A large content provider might, for example, want to be able to distinguish between appropriately filling subscriber links and aggravating some capacity failure elsewhere along the path. Traditional serving optimizations actually make this problem far worse: serving from as many places as possible, as close to the users as possible makes the system even more brittle to ISP failures. There is not an easy way to do this today. There are inference signals (e.g. correlated losses across flows) but the signals are expensive and slow. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Mar 5, 2013 at 1:53 AM, Bob Briscoe wrote: > Matt, > > The solution to the access link part of this problem is explained in: > > > It can only distinguish access link congestion from shared congestion. > Distinguishing home network congestion is harder, but possible with a tunnel > to the home router, which already exists in some DSL arrangements (e.g. in > BT we use a tunnel for services that share a line). > > > Bob > > > At 22:18 04/03/2013, Matt Mathis wrote: >> >> I have an interesting problem that I wish ConEx could solve, but I >> don't see how. I want to distinguish between congestion on the path >> between a server and a subscriber aggregation point (e.g. DSLAM etc) >> and congestion beyond the aggregation point (e.g. the access links >> themselves, or the user's home network). >> >> There are some ways to infer this, but as far as I can tell there is >> not a reasonable way to measure it directly. This is a problem that >> we have touched on in the past, but I don't recall discussing any >> solutions. >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> Privacy matters! We know from recent events that people are using our >> services to speak in defiance of unjust governments. We treat >> privacy and security as matters of life and death, because for some >> users, they are. > > > ________________________________________________________________ > Bob Briscoe, BT From john@jlc.net Tue Mar 5 10:12:29 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4997F21F8651 for ; Tue, 5 Mar 2013 10:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 IfzoTWV0AQOm for ; Tue, 5 Mar 2013 10:12:28 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B94BD21F8639 for ; Tue, 5 Mar 2013 10:12:28 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id CC4C433C21; Tue, 5 Mar 2013 13:12:28 -0500 (EST) Date: Tue, 5 Mar 2013 13:12:28 -0500 From: John Leslie To: Matt Mathis Message-ID: <20130305181228.GN84856@verdi> References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:12:29 -0000 Matt Mathis wrote: > > A large content provider might, for example, want to be able to > distinguish between appropriately filling subscriber links and > aggravating some capacity failure elsewhere along the path. > Traditional serving optimizations actually make this problem far > worse: serving from as many places as possible, as close to the users > as possible makes the system even more brittle to ISP failures. It sounds as if Matt could make use of a hop-count recorded by an ECN-aware node experiencing a loss in the ConEx Destination Option. (I'd rather hear from Matt whether that could work _before_ hearing from others why it's a ReallyBadIdea...) -- John Leslie From amclachl@cisco.com Tue Mar 5 10:13:30 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F921F8651 for ; Tue, 5 Mar 2013 10:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 nYbV1DZ1pI9y for ; Tue, 5 Mar 2013 10:13:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 973CF11E80E9 for ; Tue, 5 Mar 2013 10:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3688; q=dns/txt; s=iport; t=1362507206; x=1363716806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yqhGpt0mEg7BGLH/rem181D1hvBeS+YNfyP+dXqBAcY=; b=haihxyRzdGmINHyLY9/8KvG8eEpFUqLcte+gdiwQxpQ7QE0qs9+iSvsW x1fm+NNBTHBBCAx/38umOAJjnwtpUoYeDBrymGHZfUw5ymkPn8d642Dzr xSXxcsl1y+Yt/hi93FvHkEiCOO58J8l/iZuLAWyCK67qTi0SqiWU62eYg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIQ1NlGtJXG//2dsb2JhbABFxHKBbBZzgisBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBRkCh3IGDKw6kAuOWjMHgl9hA5ZKgR6PUIMI X-IronPort-AV: E=Sophos;i="4.84,788,1355097600"; d="scan'208";a="184074124" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 05 Mar 2013 18:13:25 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r25IDPeS005895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 18:13:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 12:13:24 -0600 From: "Andrew McLachlan (amclachl)" To: Matt Mathis Thread-Topic: [conex] Potentially interesting ConEx problem Thread-Index: AQHOGcgCF1c8saee40uci2QViBRx+ZiXZrBg Date: Tue, 5 Mar 2013 18:13:23 +0000 Message-ID: <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:13:30 -0000 Is this problem not mostly negated at the application layer in most video c= lients? They dynamically adjust to the realtime end to end bandwidth on an = end user by end user basis.=20 For a metro or backbone topology failure this method once again adapts per = end point affected, over any aggregate path these clients are running over. Moreover the expression of congestion by an ISP to an off net provider is n= ot really an attribute you would like to advertise and used to berate the S= P with. QoS is your friend here if you wish to actually protect valued traffic, rat= her the bringing whole bunches of users to the lowest common bandwidth for = an app. Andrew On 5 Mar 2013, at 17:36, "Matt Mathis" wrote: > Bob, I do know how to do it from the ISP's vantage point. >=20 > It is a bit harder from the content provider's vantage point. A > large content provider might, for example, want to be able to > distinguish between appropriately filling subscriber links and > aggravating some capacity failure elsewhere along the path. > Traditional serving optimizations actually make this problem far > worse: serving from as many places as possible, as close to the users > as possible makes the system even more brittle to ISP failures. >=20 > There is not an easy way to do this today. There are inference > signals (e.g. correlated losses across flows) but the signals are > expensive and slow. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. >=20 >=20 > On Tue, Mar 5, 2013 at 1:53 AM, Bob Briscoe wrote: >> Matt, >>=20 >> The solution to the access link part of this problem is explained in: >> >>=20 >> It can only distinguish access link congestion from shared congestion. >> Distinguishing home network congestion is harder, but possible with a tu= nnel >> to the home router, which already exists in some DSL arrangements (e.g. = in >> BT we use a tunnel for services that share a line). >>=20 >>=20 >> Bob >>=20 >>=20 >> At 22:18 04/03/2013, Matt Mathis wrote: >>>=20 >>> I have an interesting problem that I wish ConEx could solve, but I >>> don't see how. I want to distinguish between congestion on the path >>> between a server and a subscriber aggregation point (e.g. DSLAM etc) >>> and congestion beyond the aggregation point (e.g. the access links >>> themselves, or the user's home network). >>>=20 >>> There are some ways to infer this, but as far as I can tell there is >>> not a reasonable way to measure it directly. This is a problem that >>> we have touched on in the past, but I don't recall discussing any >>> solutions. >>>=20 >>> Thanks, >>> --MM-- >>> The best way to predict the future is to create it. - Alan Kay >>>=20 >>> Privacy matters! We know from recent events that people are using our >>> services to speak in defiance of unjust governments. We treat >>> privacy and security as matters of life and death, because for some >>> users, they are. >>=20 >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From mattmathis@google.com Tue Mar 5 14:37:20 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A394C11E80E9 for ; Tue, 5 Mar 2013 14:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 7B7W4GI3R3B2 for ; Tue, 5 Mar 2013 14:37:19 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E11A111E809C for ; Tue, 5 Mar 2013 14:37:18 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 10so8603561ied.30 for ; Tue, 05 Mar 2013 14:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EWcfMkQQ2TOxOT/O+8WUcxUxFbknHkAPhVN6uzMCfkU=; b=F4xQPYUhu0AjAPTF3Pn1Np59ddlmG5V0jjjRwg5ZOZSyVqlBKXOiQH5DZJXMMA6Y1k tRm4KMieKETahXU4rFm+vhEMpB4VZ9C1eJuKFXVIx6b81EuVyf3ron2ZRXl2bh7K0iUh SGlnfqaRhFk32xyW3tSVGqjogbWqUwiJ8OqXotyBIyMVxZmLAWmsxFvKGedEsoiT/s/M bJL5pHKuVpzx+no84Fsg/0qYRDU7p+D9iWsqBiGCZAXZdJPvQKJEutpuxRpGb4auXbVJ mNd6epRHmiyxaoZhrNlvtSsvehvXb/CPzSLmCmdUAiNLC3GxaAJ2VdGTigQICyB4zRWh CXYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EWcfMkQQ2TOxOT/O+8WUcxUxFbknHkAPhVN6uzMCfkU=; b=efZXxFFj/7Dgo9FczI+CerHLhuw7odkTTDvj5iO6EblY0DnUJWlL3/IhauxSF8bb0K LCG9QYxDdodXSBzRQX/FHJELNcC0XFbyO2+Jt/3sItwZ7+dNMk3IkSr1z/6u5s5IXaws LOUP1fWgJ/Qjy+fBn7VzED9zgk537dbibHtuGC7ArR5aV9sPdHCtF8TBa+Y+KsPYEUVP m4rd095NX/fq4SS6t+9LWHuBgdHDroUhp0mo27jctb6wdTrGAz8cusUl+7gxmzAZ7qUP yAZWZwfIAjJ9gxvz5CCWUaA4Wka4MyzJ2bB4X/VFz4BhHWpSdqVgyI5djVzD9JG/CoXW x6Hw== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr8046671igj.96.1362523037736; Tue, 05 Mar 2013 14:37:17 -0800 (PST) Received: by 10.64.252.100 with HTTP; Tue, 5 Mar 2013 14:37:17 -0800 (PST) In-Reply-To: <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> Date: Tue, 5 Mar 2013 14:37:17 -0800 Message-ID: From: Matt Mathis To: "Andrew McLachlan (amclachl)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm6KnYUkTgEp2kJYbFXd5u+h7Qj1dwrgMviekaO34o0uEBHFib7QpQ2M5k78xv8kJSQ+yfrHgXQzXI98XCnr4/4Jkps5c2PIQiAxn8znTzNmflp2druWFD7BoWxu0d8Pt7Pns7JdW54jMsxIoKTWNYCBoK5VE+gYsCpP6NHL4D7xoM4xmOvJDM8vL0RzEX2BSFB2AZt Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:37:20 -0000 On Tue, Mar 5, 2013 at 10:13 AM, Andrew McLachlan (amclachl) wrote: > Is this problem not mostly negated at the application layer in most video clients? They dynamically adjust to the realtime end to end bandwidth on an end user by end user basis. The clients are not immutable, nor does the server have to tell the clients about every available format. > For a metro or backbone topology failure this method once again adapts per endpoint affected, over any aggregate path these clients are running over. Right, but if I am serving from 2 mS away and the data rate is only 128kb/s, my expected TCP equilibrium loss rate might be well above 10% (it depends on the queue size). It makes a huge operational difference to know if the bottleneck is one subscriber's access link or 100k busy users trying to share a very saturated 10Gb/s link. If it is the latter, you really don't want to be one of the other 100k users. > Moreover the expression of congestion by an ISP to an off net provider is not really an attribute you would like to advertise and used to berate the SP with. Perhaps true, but the risks flow in both directions, and the alternative to sharing information has the potential to have much worse outcomes for both parties. Besides, some inference techniques will always work. > QoS is your friend here if you wish to actually protect valued traffic, rather the bringing whole bunches of users to the lowest common bandwidth for an app. Lets think about that idea: unconditionally mark all of my traffic to be lower priority than my competitors... I don't think that will pass muster. There are additional more incremental solutions in this space, including weighted congestion control, with the ability to trim the weights by small amounts in real time. (Which will indirectly cause clients to choose lower rate formats). The question I was asking was can ConEx help the content provider know which bottleneck prevails? Bob? Yes, John L, knowing which hop is key. but recording it in the ConEx destination option seems like a ReallyBadIdea. For one thing all potential tags are out of scope (I don't want to know hop counts or IP addresses towards the user, nor if the user has a bottlenecked WiFi between the client and the access link.) What I really want to know is: What are the traffic aggregates/routing prefixes sharing the same bottleneck? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From swmike@swm.pp.se Tue Mar 5 21:20:53 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1AC21F85DB for ; Tue, 5 Mar 2013 21:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 VBurPmPSL+C8 for ; Tue, 5 Mar 2013 21:20:52 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED3B21F85D8 for ; Tue, 5 Mar 2013 21:20:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E954D9C; Wed, 6 Mar 2013 06:20:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E4FCB9A for ; Wed, 6 Mar 2013 06:20:48 +0100 (CET) Date: Wed, 6 Mar 2013 06:20:48 +0100 (CET) From: Mikael Abrahamsson To: ConEx IETF list In-Reply-To: Message-ID: References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 05:20:53 -0000 On Tue, 5 Mar 2013, Matt Mathis wrote: > The question I was asking was can ConEx help the content provider know > which bottleneck prevails? Bob? I tried to get the TCP people look into this, but got shot down. They didn't feel TCP would work better by knowing more, or I guess they didn't want to handle th complexity. My idea was that TCP would over time "find out" what the access looked like if it indeed was the only thing congesting, and even that the connection manager on the machine would inform TCP what the properties of the primary connection was (speed, buffering, retransmits, half/full duplex etc), and if something substantial (like the link going down or coming up, speed changed etc) happened, TCP would be informed of this. They felt it was better to have TCP find out by itself instead of getting fed this information via some API. -- Mikael Abrahamsson email: swmike@swm.pp.se From mattmathis@google.com Wed Mar 6 10:13:31 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778C721F8734 for ; Wed, 6 Mar 2013 10:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 483cVWrYxp13 for ; Wed, 6 Mar 2013 10:13:27 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0942A21F89AE for ; Wed, 6 Mar 2013 10:13:23 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so10030237ieb.9 for ; Wed, 06 Mar 2013 10:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pDyMVjLy50y/1p7uYl3ZS8TzWXW8F5lvN64nYk8o6Lw=; b=MN8XxwM4bYrg5dgbesvyftlEfPPBS8l25Ms1FnBqJ8eyqsJh0MMNex/BFGNyMJxOo2 6CYiikenE2RUt1c/eCtT/iUsBR4TE3r+WFTNKeppYCalOJihHLe29CcflePqrknkTIp9 cwB5KgvQZ79FaciwWtTGi2OB+/kdrFsuy9c0KVC3fpJFxXwuZ3ne9KuPshZTbcwjTHFN tzv6uQ2lqH+WFiOkBJr+X9RywpUW059eZ3mr7kP2tdphXEvxvmqE1zRoYjhJTaIiHkYZ zEhQAPEpTD58nJqYaGk6DpdnUVwz2PU5gtoqZleQuYDvG0bWibBxQJcNMDe+bu9RY4vW g/fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=pDyMVjLy50y/1p7uYl3ZS8TzWXW8F5lvN64nYk8o6Lw=; b=hDoNmdfK4fWaG2DTzFSmDNSvyI2e6DeAuhWScK8EFMOiRZxwgj2Pe+b0ZH2lCnRQvQ dx3eDz4gzrH/ZueoqXnbEXbeGOhmDnR687MQR/OjsrtxJWzwI84We1g0aTmRL54phPnQ EG/AY+uYvZ/Sbzz2ovZbFIzcWX/l0+fTCiWaw5chruNxRjEfQZlIi+5M+53RSV73F5xW Cdrs0K3zDkI5f3o0KLnAl4tEypuK35DY32SRlSYugHWya7XZSj3Ng6AucDN459TKmf6v jYnH7rgBD3QXiwYnC9Rwy+x0+KU1jESr2T8Huqw8ha2Xcu4P3AndISfiJP3Jqmdh1GPA AcZQ== MIME-Version: 1.0 X-Received: by 10.42.128.70 with SMTP id l6mr3706000ics.54.1362593598731; Wed, 06 Mar 2013 10:13:18 -0800 (PST) Received: by 10.64.32.199 with HTTP; Wed, 6 Mar 2013 10:13:18 -0800 (PST) In-Reply-To: References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> Date: Wed, 6 Mar 2013 10:13:18 -0800 Message-ID: From: Matt Mathis To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn/Ct+ws//K4fTNNlYI32B605aDkSY2o8v1lhmJl9dMELxIc38jhiv17xjnuA1p9sQ8G9L13DAZxJOLHXVdKVwOyJ372mImVQl9bJG3DaW+2roq6IQD85TK4ITBWU71HEzh2Ci741b+2KoJiswFGWIvVYr9w7r5R93nfOqXG/5ouoGXVI4c3Jwwr4lNiY3lPjHXwrTS Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:13:31 -0000 So as an intermittent TCP person, I agree with them: this does not belong at the TCP layer, but at some slightly higher serving services layer, because it is has to be coupled to things like load balancers, etc. Per server state isn't useful. Which is not the same as saying the idea isn't valuable, it is just that TCP itself isn't quite the right place. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Mar 5, 2013 at 9:20 PM, Mikael Abrahamsson wrote: > On Tue, 5 Mar 2013, Matt Mathis wrote: > >> The question I was asking was can ConEx help the content provider know >> which bottleneck prevails? Bob? > > > I tried to get the TCP people look into this, but got shot down. They didn't > feel TCP would work better by knowing more, or I guess they didn't want to > handle th complexity. > > My idea was that TCP would over time "find out" what the access looked like > if it indeed was the only thing congesting, and even that the connection > manager on the machine would inform TCP what the properties of the primary > connection was (speed, buffering, retransmits, half/full duplex etc), and if > something substantial (like the link going down or coming up, speed changed > etc) happened, TCP would be informed of this. > > They felt it was better to have TCP find out by itself instead of getting > fed this information via some API. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Wed Mar 6 10:31:31 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20C421F886D for ; Wed, 6 Mar 2013 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8R2KfxcQx+ou for ; Wed, 6 Mar 2013 10:31:31 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 83F6D21F87E7 for ; Wed, 6 Mar 2013 10:31:27 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C3089C; Wed, 6 Mar 2013 19:31:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 425959A; Wed, 6 Mar 2013 19:31:26 +0100 (CET) Date: Wed, 6 Mar 2013 19:31:26 +0100 (CET) From: Mikael Abrahamsson To: Matt Mathis In-Reply-To: Message-ID: References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:31:31 -0000 On Wed, 6 Mar 2013, Matt Mathis wrote: > Which is not the same as saying the idea isn't valuable, it is just that > TCP itself isn't quite the right place. Well, I can't personally understand why the end user wouldn't get a better experience by TCP knowing that the wifi link is now up again, so it might be good to reset the retransmit timers to 1s instead of waiting 60 seconds before trying again. -- Mikael Abrahamsson email: swmike@swm.pp.se From michael.scharf@alcatel-lucent.com Wed Mar 6 11:46:26 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE321F8263 for ; Wed, 6 Mar 2013 11:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.319 X-Spam-Level: X-Spam-Status: No, score=-7.319 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 MHjwfXhEGkf5 for ; Wed, 6 Mar 2013 11:46:25 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3148021F8235 for ; Wed, 6 Mar 2013 11:46:25 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26JjM3t013624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 20:46:22 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 6 Mar 2013 20:46:08 +0100 From: "Scharf, Michael (Michael)" To: Mikael Abrahamsson , ConEx IETF list Date: Wed, 6 Mar 2013 20:46:07 +0100 Thread-Topic: [conex] Potentially interesting ConEx problem Thread-Index: Ac4aKma/D1i9fNTWSYqZZ0RmqnleZQAdiCZD Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12C1E0A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:46:27 -0000 Mikael, I do not understand how a congestion manager solves the problem raised here= . Also, since you seem to be unhappy with TCPM, please recall that at leas= t I was interested in seeing empirical data for the timer problem you descr= ibed (e. g., real OS traces). But that discussion would be better suited fo= r the TCPM list, imho. Actually, I do think that another recent TCPM discussion is closer related = to this question: http://www.ietf.org/mail-archive/web/tcpm/current/msg0682= 9.html (But Matt is certainly aware of this already, and it doesn't solve t= he problem). Another random idea that comes into my mind is the Quick-Start nonce mechan= ism. In Quick-Start one can ensure that certain actions can only be perform= ed by downstream routers. Sure, this is not what is needed here, but maybe = another interesting pointer? Michael ________________________________________ Von: conex-bounces@ietf.org [conex-bounces@ietf.org] im Auftrag von Mikael = Abrahamsson [swmike@swm.pp.se] Gesendet: Mittwoch, 6. M=E4rz 2013 06:20 An: ConEx IETF list Betreff: Re: [conex] Potentially interesting ConEx problem On Tue, 5 Mar 2013, Matt Mathis wrote: > The question I was asking was can ConEx help the content provider know > which bottleneck prevails? Bob? I tried to get the TCP people look into this, but got shot down. They didn't feel TCP would work better by knowing more, or I guess they didn't want to handle th complexity. My idea was that TCP would over time "find out" what the access looked like if it indeed was the only thing congesting, and even that the connection manager on the machine would inform TCP what the properties of the primary connection was (speed, buffering, retransmits, half/full duplex etc), and if something substantial (like the link going down or coming up, speed changed etc) happened, TCP would be informed of this. They felt it was better to have TCP find out by itself instead of getting fed this information via some API. -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Wed Mar 6 20:34:24 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7911E80D9 for ; Wed, 6 Mar 2013 20:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 YbdCvlmPBk41 for ; Wed, 6 Mar 2013 20:34:24 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5192611E80D3 for ; Wed, 6 Mar 2013 20:34:24 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1AEB69C; Thu, 7 Mar 2013 05:34:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 13CF89A; Thu, 7 Mar 2013 05:34:23 +0100 (CET) Date: Thu, 7 Mar 2013 05:34:23 +0100 (CET) From: Mikael Abrahamsson To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AB12C1E0A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> , <2A886F9088894347A3BE0CC5B7A85F3E9AB12C1E0A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:34:25 -0000 On Wed, 6 Mar 2013, Scharf, Michael (Michael) wrote: > I do not understand how a congestion manager solves the problem raised > here. Are you referring to TCP or Conex here? > Also, since you seem to be unhappy with TCPM, please recall that at > least I was interested in seeing empirical data for the timer problem > you described (e. g., real OS traces). But that discussion would be > better suited for the TCPM list, imho. Well, I'm not going back to the TCPM list with my idea (I felt there was consensus there this wasn't anything for TCP), I'll try to pitch my idea to other parties that might actually have an understanding for my the problem I'm experiencing and get running code into operating systems first. I've moved over to "mosh" (http://mosh.mit.edu/) which solves my problem nicely by avoiding TCP and using UDP instead. -- Mikael Abrahamsson email: swmike@swm.pp.se From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Mar 7 13:19:34 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F41421F859B for ; Thu, 7 Mar 2013 13:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 CazDmRVenPHU for ; Thu, 7 Mar 2013 13:19:34 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9221F857B for ; Thu, 7 Mar 2013 13:19:20 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id DC1A960275; Thu, 7 Mar 2013 22:19:18 +0100 (CET) Received: from vpn-2-cl113 (vpn-2-cl113 [10.41.21.113]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CB1FB60274; Thu, 7 Mar 2013 22:19:18 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Thu, 7 Mar 2013 22:19:18 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201303072219.18223.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 21:19:34 -0000 Hi Matt, > The question I was asking was can ConEx help the content provider know > which bottleneck prevails? Bob? (sorry I'm not Bob but will give it a try anyway) I don't think ConEx can help here. I believe you assume a scenario where the content provider is in most cases the sender. With ConEx information will be re-insert form the sender into the network. Thus ECN or loss information thus will be sufficient at the sender. Anyway as I've been recently looking in loss measurement/estimations methods, I actually came over the same question. Here my current ideas: - The client/receiver might know its access bandwidth and could provide this information to the server (in a higher layer protocol) or send some measurement traffic to the server or a measurement server - distinguish self-congestion (only one flow on bottleneck link) form shared congestion by looking at the lost pattern, e.g. a flow using cubic or reno has a very regular loss burst with a defined number of losses in a defined period (I'm currently looking at this) if there is no cross traffic disturbing the flow - correlate the losses (or loss pattern) of multiple flows (from the same server to different clients) to see if losses occur at the same time/in the same period (see network tomography in literature) Does this help? Mirja From bob.briscoe@bt.com Thu Mar 7 15:40:28 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C7A21F86C8 for ; Thu, 7 Mar 2013 15:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ryd-fPRPbRwj for ; Thu, 7 Mar 2013 15:40:27 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4221F86C5 for ; Thu, 7 Mar 2013 15:40:27 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 7 Mar 2013 23:40:26 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 7 Mar 2013 23:40:25 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Thu, 7 Mar 2013 23:40:24 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.160.193]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r27NeMJE021720; Thu, 7 Mar 2013 23:40:22 GMT Message-ID: <201303072340.r27NeMJE021720@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 7 Mar 2013 23:40:12 +0000 To: "Andrew McLachlan (amclachl)" From: Bob Briscoe In-Reply-To: <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> References: <201303050953.r259rCTS000573@bagheera.jungle.bt.co.uk> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 23:40:28 -0000 Andrew, Going back in the thread to your point... At 18:13 05/03/2013, Andrew McLachlan (amclachl) wrote: >Is this problem not mostly negated at the application layer in most >video clients? They dynamically adjust to the realtime end to end >bandwidth on an end user by end user basis. Yes, by driving load until they detect losses. That's just normal regular congestion avoidance & control. So far, that's nothing to do with ConEx, which doesn't propose to change what the network tells hosts. Rather, it's about hosts telling the network what e2e congestion they have detected. >For a metro or backbone topology failure this method once again >adapts per end point affected, over any aggregate path these clients >are running over. Yes. Again, nothing new here. >Moreover the expression of congestion by an ISP to an off net >provider is not really an attribute you would like to advertise and >used to berate the SP with. A link cannot not signal congestion (double negative intended) if hosts are overloading it with traffic, even briefly. It has to discard as much traffic as it has to discard. It's only choice is in whether it does that randomly (ie proportionate to instantaneous load) or focused (leading into your QoS point next). This still isn't related to ConEx, which is about the sender signalling the e2e congestion it detects back into the network, in an e2e field, which hosts can integrity-protect against networks altering it if they choose. ConEx is not about whether the network signals congestion (because it has no choice over that). >QoS is your friend here if you wish to actually protect valued >traffic, rather the bringing whole bunches of users to the lowest >common bandwidth for an app. ConEx is about intra-class protection of traffic. The operator can use QoS classes (or not), and it could manage traffic within a class using ConEx (or not). ConEx will be useful for focusing policing on particularly heavy sources within a class. QoS (Diffserv) focuses discards on all lower class traffic indiscriminately. The two could work together, so during overload QOS protects valued traffic and even in the lower classes ConEx will protect most traffic, while only shedding traffic from the heaviest customer(s) in the lower class. I believe you are dividing traffic up into valued (premium) and not, but customers also value and pay for this so-called 'not valued' traffic. And operators don't only care about premium traffic - they know they can't afford to lose custom for either service type. Matt's question was about how the network can infer whether congestion is shared or self-congestion (policing the major contributers would help in the former, but not the latter). Bob >Andrew > > > > > >On 5 Mar 2013, at 17:36, "Matt Mathis" wrote: > > > Bob, I do know how to do it from the ISP's vantage point. > > > > It is a bit harder from the content provider's vantage point. A > > large content provider might, for example, want to be able to > > distinguish between appropriately filling subscriber links and > > aggravating some capacity failure elsewhere along the path. > > Traditional serving optimizations actually make this problem far > > worse: serving from as many places as possible, as close to the users > > as possible makes the system even more brittle to ISP failures. > > > > There is not an easy way to do this today. There are inference > > signals (e.g. correlated losses across flows) but the signals are > > expensive and slow. > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our > > services to speak in defiance of unjust governments. We treat > > privacy and security as matters of life and death, because for some > > users, they are. > > > > > > On Tue, Mar 5, 2013 at 1:53 AM, Bob Briscoe wrote: > >> Matt, > >> > >> The solution to the access link part of this problem is explained in: > >> > > >> > >> It can only distinguish access link congestion from shared congestion. > >> Distinguishing home network congestion is harder, but possible > with a tunnel > >> to the home router, which already exists in some DSL arrangements (e.g. in > >> BT we use a tunnel for services that share a line). > >> > >> > >> Bob > >> > >> > >> At 22:18 04/03/2013, Matt Mathis wrote: > >>> > >>> I have an interesting problem that I wish ConEx could solve, but I > >>> don't see how. I want to distinguish between congestion on the path > >>> between a server and a subscriber aggregation point (e.g. DSLAM etc) > >>> and congestion beyond the aggregation point (e.g. the access links > >>> themselves, or the user's home network). > >>> > >>> There are some ways to infer this, but as far as I can tell there is > >>> not a reasonable way to measure it directly. This is a problem that > >>> we have touched on in the past, but I don't recall discussing any > >>> solutions. > >>> > >>> Thanks, > >>> --MM-- > >>> The best way to predict the future is to create it. - Alan Kay > >>> > >>> Privacy matters! We know from recent events that people are using our > >>> services to speak in defiance of unjust governments. We treat > >>> privacy and security as matters of life and death, because for some > >>> users, they are. > >> > >> > >> ________________________________________________________________ > >> Bob Briscoe, BT > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT From bob.briscoe@bt.com Thu Mar 7 16:06:31 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2CC21F86D3 for ; Thu, 7 Mar 2013 16:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 GcNg8dSHJchZ for ; Thu, 7 Mar 2013 16:06:30 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id E97D521F86D9 for ; Thu, 7 Mar 2013 16:06:29 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 8 Mar 2013 00:06:25 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 8 Mar 2013 00:06:23 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 8 Mar 2013 00:06:23 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.160.193]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r2806LFq021835; Fri, 8 Mar 2013 00:06:22 GMT Message-ID: <201303080006.r2806LFq021835@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 8 Mar 2013 00:06:22 +0000 To: Matt Mathis , Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201303072219.18223.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> <201303072219.18223.mirja.kuehlewind@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: conex@ietf.org Subject: Re: [conex] Potentially interesting ConEx problem X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 00:06:31 -0000 Matt, At 21:19 07/03/2013, Mirja Kuehlewind wrote: >Hi Matt, > > > The question I was asking was can ConEx help the content provider know > > which bottleneck prevails? Bob? Sorry, seeing your repeated question, I had misinterpreted. As Mirja says below, I can't see how ConEx could help the /content provider/ to know anything. The content provider sends the ConEx signal in the first place, so it surely cannot learn anything new from a signal it sends itself. I think Mirja's on the right track for the content provider to infer the difference between shared and self-congestion. Fixed-line self-congestion should lead to a very regular total bandwidth across flows, and a regular loss pattern. That isn't a panacea tho, because there might be tons of devices within a home sharing a fixed access link making all the flows to any single device see what looks like shared and variable congestion. Or the link might have a wireless tail that is shaking about all over the bandwidth range. Does it matter? If there's a link failure so loads of people's traffic all gets squeezed into some remaining link, the content provider will see the congestion, and adjust down. The congestion level will be higher, so it should go slower. Sorted? However, I don't understand the last part of your question (below). Why more brittle? At 17:36 05/03/2013, Matt Mathis wrote: >Traditional serving optimizations actually make this problem far >worse: serving from as many places as possible, as close to the users >as possible makes the system even more brittle to ISP failures. Bob >(sorry I'm not Bob but will give it a try anyway) > >I don't think ConEx can help here. I believe you assume a scenario where the >content provider is in most cases the sender. With ConEx information will be >re-insert form the sender into the network. Thus ECN or loss information thus >will be sufficient at the sender. > >Anyway as I've been recently looking in loss measurement/estimations methods, >I actually came over the same question. Here my current ideas: > >- The client/receiver might know its access bandwidth and could provide this >information to the server (in a higher layer protocol) or send some >measurement traffic to the server or a measurement server > >- distinguish self-congestion (only one flow on bottleneck link) form shared >congestion by looking at the lost pattern, e.g. a flow using cubic or reno >has a very regular loss burst with a defined number of losses in a defined >period (I'm currently looking at this) if there is no cross traffic >disturbing the flow > >- correlate the losses (or loss pattern) of multiple flows (from the same >server to different clients) to see if losses occur at the same time/in the >same period (see network tomography in literature) > >Does this help? > >Mirja > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT From sebastien.jobert@orange.com Fri Mar 8 16:03:16 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED721F8609 for ; Fri, 8 Mar 2013 16:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 kSiI+u7vxoXY for ; Fri, 8 Mar 2013 16:03:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C021F85B4 for ; Fri, 8 Mar 2013 16:03:14 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A5D4A3261C7 for ; Sat, 9 Mar 2013 01:03:10 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8DD10238080 for ; Sat, 9 Mar 2013 01:03:10 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Sat, 9 Mar 2013 01:03:10 +0100 From: To: "conex@ietf.org" Thread-Topic: [conex] I-D Action: draft-ietf-conex-mobile-01.txt Thread-Index: AQHN7ws2jW+6n/IJ1EuWQsToT2RtLZiEx7hQ Date: Sat, 9 Mar 2013 00:03:10 +0000 Message-ID: <16566_1362787390_513A7C3E_16566_17833_1_7F67B91079F7C74F9DAB55FC7872661E0C139F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <20130110081844.23078.88285.idtracker@ietfa.amsl.com> In-Reply-To: <20130110081844.23078.88285.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.8.224215 Subject: Re: [conex] I-D Action: draft-ietf-conex-mobile-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 00:03:16 -0000 Hi, I reviewed this draft, which is of interest to me. Indeed, as said during t= he IETF83 in Paris, I believe that documenting how to use ConEx in the cont= ext of mobile networks would be beneficial to the industry, as it clearly c= orresponds to an interesting use case. I would be happy to help if useful. Please see below some comments/questions for clarification, with the goal o= f improving this draft. - Section 2: overview of 3GPP EPC I am not convinced that this overview is really a must in this document, es= pecially if the purpose is to publish it at the end. Referencing the releva= nt 3GPP documents might be appropriate instead. Also, I would suggest avoid= ing to make this draft specific to LTE; indeed ConEx is applicable to other= mobile networks. What could be of interest however in this section might be to describe in a= generic way the aspects specific to the mobile networks relevant to ConEx,= for instance: - the use very often of a tunnel "IP over IP" (GTP tunnel in general) - the fact that two very different segments are involved in those networks= (wireless and backhaul/core) - the specificities of the wireless segment - e.g. the cost of transmittin= g a packet depends on the radio conditions - the mobility aspects, and their impact on the places where ConEx related= information must be maintained - the potential presence of very different mobile technologies (e.g. 3GPP-= based and Wifi) and offloading scenarios The following draft that we briefly presented in Paris could give some inpu= ts on the wireless segment: http://tools.ietf.org/pdf/draft-jobert-tsvwg-pr= e-congest-notif-mobile-00.pdf In addition, I wonder if the scope of this document could also cover unlice= nsed wireless networks such as Wifi? Perhaps the architectures are a bit di= fferent, but maybe not too much. And I understood that Wifi is already part= of the offloading scenarios described in this draft. - Section 3: ConEx use cases This draft mentions 4 different use case of ConEx in mobile networks: 3.1- CONEX as a Basis for Traffic Management The beginning of section 3.1 has again many references to 3GPP LTE mechanis= ms that are not really ConEx specific. It would be desirable to focus the d= iscussion on ConEX: describe basically the features that ConEx would bring,= and how to deploy the mechanism, without necessarily comparing with 3GPP L= TE features. DPI and admission control are mentioned. It is worth clarifying that DPI is= clearly not used everywhere and has clear drawbacks (e.g. versatility of a= pplication signatures, trend to encryption). I would personally avoid prese= nting it as a de facto mechanism; there are other options to manage QoS in = a dynamic way in mobile networks. It is worth also mentioning that the effi= ciency of admission control mechanisms for data services is quite limited i= n general in mobile networks, due to the high variability of the traffic an= d of the achievable throughput on the radio interface. My experience is tha= t, most of the time, they are simply deactivated for data services. When reading the text, I found the DPI discussion and comparison with ConEx= quite unclear. These are 2 different mechanisms. As presented in the draft= , DPI aims at identifying certain types of applications, to potentially app= ly a particular treatment to them in case of congestion. My understanding o= f ConEx is that it can tell you about how much congestion has been caused b= y a user or by a flow in the past. One might want to apply a particular tre= atment to the flows having causes the highest congestion in the past, but I= believe that it is a different use case compared to the "service classific= ation" mentioned with DPI - both could actually be complementary and combin= ed. I don't fully agree that ConEx plays the same role as a mechanism which= aims at identifying the type of application (DPI, or another mechanism). I= don't believe either that it is "more accurate and dynamic fashion"; this = is simply different paradigm. The use case of data offload is also mentioned. While I understand the conc= ept, I am not sure that I see how this is specific to ConEx. This is a bit = similar to the previous discussion: one can apply various criteria to selec= t the flows to be offloaded, ConEx providing information for a congestion-b= ased selection. I'll tend to think that congestion will very likely not be = the only criteria. Again, I believe that the draft would benefit in simply describing how ConE= x is expected to be used to address this kind of use cases, rather than com= paring with other LTE mechanisms. 3.2- CONEX to Incentivize Scavenger Transports While I fully understand the objective of this (basically, incentivize the = use of less-than-best-effort transport), I feel that this is more in the ha= nds of the application than the network, and the application probably needs= some trigger from the network to move to this kind of scavenger transport.= Therefore, you might perhaps add that additional specific mechanisms could= be implemented in the network, such as the one described in section 3.3 (A= ccounting for Congestion Volume), to really incentivize the applications to= play the game. 3.3- Accounting for Congestion Volume IMHO, this is probably the most interesting use case for ConEx in mobile ne= tworks: providing a more accurate form of fair usage. How to use ConEx to a= ddress this use case should be better described in this document. The advan= tages of informing the application about the periods of congestion could be= for instance highlighted. Also, the description could be combined with the= previous use case described in section 3.2 (Scavenger Transports), since t= hey are in a way complementary. 3.4- CONEX as a Form of Differential QoS I don't really see the main difference compared to section 3.1; could you c= larify what is specific here? Perhaps both sections should be combined? - Section 3.5: Partial vs. Full Deployment This section is really important, as it is quite clear that ConEx will not = be supported everywhere in potential early deployments. Especially, as ment= ioned in the draft, mobile terminals may not support the mechanisms at the = beginning. Some of the schemes suggested during partial deployments may however be dif= ficult to be explained to the end user (e.g. "apply fixed volume caps for n= on-CONEX UEs and more flexible schemes for CONEX-enabled UEs"), and therefo= re difficult to consider in practice. This may moreover not always be a mat= ter of mobile terminal, but also of the way the application running on the = terminal is developed - hence the potential variability. Migration paths and partial support for ConEx should be further detailed, i= n particular how to progressively introduce ConEx in mobile networks, e.g. = in case the features are not supported everywhere. For instance, in case th= e terminals do not implement ConEx, could some ConEx functions be implement= ed in the base station instead? The draft is currently not so detailed on t= hese aspects. This section describes relevant areas where attention is required (roaming,= mobility, ...). There is however some overlapping with previous section on= ConEx-based data offload (it might be easily fixed). - Section 4: ConEX in the EPS The description of the 3 scenarios is currently very limited/weak (basicall= y reduced to the figures...). Further details are clearly needed to underst= and them. For instance, I don't understand how case 1 (figure 2) could work without t= he UE supporting ConEx. How can the server know about the amount of congest= ion in this case? My understanding of this scenario is that the UE does not= even send back to the sender the congestion signal (e.g. ECN/loss) in the = TCP layer. It is not clear either how ConEx could operate over multiple administrative= domains (e.g. multiple operators). It should be discussed somewhere whether the purpose is to cover congestion= only over the wireless segment, only over the backhaul segment, or both. A= section discussing how to actually manage / differentiate congestion in th= e backhaul vs radio segment could be useful. Indeed, when ECN is used, this= kind of consideration may be of importance. It was good point to reference= RFC 6040 as propagation of the ECN marking across the (GTP) tunnel may be = needed. Further details about the exact option(s) to be used could however = be useful. The draft should recommend more clearly where to position the different fun= ctions defined in ConEx, e.g.: - Policer in the core network (e.g. in the GGSN / PDN-GW) - Auditer in the base station - Support for ConEx in the mobile terminals (as senders or receivers) - Support for ConEx in the senders more in general (e.g. Web server) While I understand the concept, I am not fully convinced about positioning = the policer in the base station for the uplink direction; that seems really= too much distributed for this kind of function. Probably it depends on the= exact use case addressed, but if some form of user-specific accounting inf= ormation is required to the policer, this position is clearly not a good op= tion at all. - Other comments I have a general question to the group: which relationships do you see betw= een ConEx and UPCON activities in 3GPP? They are touching the same aspects = (namely congestions in wireless networks), but the mechanisms may at the en= d be quite different (although my understanding is that the mechanisms in U= PCON are still to be defined). For instance:=20 - Could ConEx be one possible solution to UPCON? - Will UPCON be an alternative to ConEx, where the congestion information = will be carried back to the core network by another mean than TCP layer? (e= .g. inside the GTP tunnel) - Can UPCON be considered as similar to a partial deployment of ConEx, and= be completed later when the mobile terminals will be "ConEx aware"? I'd be really interested to hear people's opinion on these items. Thanks. Cheers, S=E9bastien -----Message d'origine----- De=A0: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] De la part de= internet-drafts@ietf.org Envoy=E9=A0: jeudi 10 janvier 2013 09:19 =C0=A0: i-d-announce@ietf.org Cc=A0: conex@ietf.org Objet=A0: [conex] I-D Action: draft-ietf-conex-mobile-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : Mobile Communication Congestion Exposure Scenario Author(s) : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-01.txt Pages : 22 Date : 2013-01-10 Abstract: This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP Evoled Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-mobile-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-mobile-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Dirk.Kutscher@neclab.eu Mon Mar 11 01:25:42 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65821F87F9 for ; Mon, 11 Mar 2013 01:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1lIdeqiTltKK for ; Mon, 11 Mar 2013 01:25:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7621F87FB for ; Mon, 11 Mar 2013 01:25:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6912310361B; Mon, 11 Mar 2013 09:25:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0AK5oC-9NRs; Mon, 11 Mar 2013 09:25:40 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 463CD1035B7; Mon, 11 Mar 2013 09:25:30 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 11 Mar 2013 09:25:30 +0100 From: Dirk Kutscher To: "sebastien.jobert@orange.com" , "conex@ietf.org" Thread-Topic: [conex] I-D Action: draft-ietf-conex-mobile-01.txt Thread-Index: AQHN7ws331UX9ppFRESPANIFbFA5P5icxB4AgAPBTdA= Date: Mon, 11 Mar 2013 08:24:43 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524955232DD2@PALLENE.office.hd> References: <20130110081844.23078.88285.idtracker@ietfa.amsl.com> <16566_1362787390_513A7C3E_16566_17833_1_7F67B91079F7C74F9DAB55FC7872661E0C139F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <16566_1362787390_513A7C3E_16566_17833_1_7F67B91079F7C74F9DAB55FC7872661E0C139F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.203] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] I-D Action: draft-ietf-conex-mobile-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 08:25:42 -0000 Hi Sebastien, Thanks a lot for the feedback -- we'll come back to that (hopefully soon). Best regards, Dirk > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of sebastien.jobert@orange.com > Sent: Samstag, 9. M=E4rz 2013 01:03 > To: conex@ietf.org > Subject: Re: [conex] I-D Action: draft-ietf-conex-mobile-01.txt >=20 > Hi, >=20 > I reviewed this draft, which is of interest to me. Indeed, as said during= the > IETF83 in Paris, I believe that documenting how to use ConEx in the conte= xt > of mobile networks would be beneficial to the industry, as it clearly > corresponds to an interesting use case. I would be happy to help if usefu= l. >=20 > Please see below some comments/questions for clarification, with the goal > of improving this draft. >=20 >=20 > - Section 2: overview of 3GPP EPC >=20 > I am not convinced that this overview is really a must in this document, > especially if the purpose is to publish it at the end. Referencing the re= levant > 3GPP documents might be appropriate instead. Also, I would suggest > avoiding to make this draft specific to LTE; indeed ConEx is applicable t= o other > mobile networks. >=20 > What could be of interest however in this section might be to describe in= a > generic way the aspects specific to the mobile networks relevant to ConEx= , > for instance: > - the use very often of a tunnel "IP over IP" (GTP tunnel in general) > - the fact that two very different segments are involved in those > networks (wireless and backhaul/core) > - the specificities of the wireless segment - e.g. the cost of > transmitting a packet depends on the radio conditions > - the mobility aspects, and their impact on the places where ConEx > related information must be maintained > - the potential presence of very different mobile technologies (e.g. > 3GPP-based and Wifi) and offloading scenarios >=20 > The following draft that we briefly presented in Paris could give some in= puts > on the wireless segment: http://tools.ietf.org/pdf/draft-jobert-tsvwg-pre= - > congest-notif-mobile-00.pdf >=20 > In addition, I wonder if the scope of this document could also cover > unlicensed wireless networks such as Wifi? Perhaps the architectures are = a > bit different, but maybe not too much. And I understood that Wifi is alre= ady > part of the offloading scenarios described in this draft. >=20 >=20 > - Section 3: ConEx use cases >=20 > This draft mentions 4 different use case of ConEx in mobile networks: >=20 > 3.1- CONEX as a Basis for Traffic Management >=20 > The beginning of section 3.1 has again many references to 3GPP LTE > mechanisms that are not really ConEx specific. It would be desirable to f= ocus > the discussion on ConEX: describe basically the features that ConEx would > bring, and how to deploy the mechanism, without necessarily comparing > with 3GPP LTE features. >=20 > DPI and admission control are mentioned. It is worth clarifying that DPI = is > clearly not used everywhere and has clear drawbacks (e.g. versatility of > application signatures, trend to encryption). I would personally avoid > presenting it as a de facto mechanism; there are other options to manage > QoS in a dynamic way in mobile networks. It is worth also mentioning that > the efficiency of admission control mechanisms for data services is quite > limited in general in mobile networks, due to the high variability of the= traffic > and of the achievable throughput on the radio interface. My experience is > that, most of the time, they are simply deactivated for data services. >=20 > When reading the text, I found the DPI discussion and comparison with > ConEx quite unclear. These are 2 different mechanisms. As presented in th= e > draft, DPI aims at identifying certain types of applications, to potentia= lly apply > a particular treatment to them in case of congestion. My understanding of > ConEx is that it can tell you about how much congestion has been caused b= y a > user or by a flow in the past. One might want to apply a particular treat= ment > to the flows having causes the highest congestion in the past, but I beli= eve > that it is a different use case compared to the "service classification" > mentioned with DPI - both could actually be complementary and combined. I > don't fully agree that ConEx plays the same role as a mechanism which aim= s > at identifying the type of application (DPI, or another mechanism). I don= 't > believe either that it is "more accurate and dynamic fashion"; this is si= mply > different paradigm. >=20 > The use case of data offload is also mentioned. While I understand the > concept, I am not sure that I see how this is specific to ConEx. This is = a bit > similar to the previous discussion: one can apply various criteria to sel= ect the > flows to be offloaded, ConEx providing information for a congestion-based > selection. I'll tend to think that congestion will very likely not be the= only > criteria. >=20 > Again, I believe that the draft would benefit in simply describing how Co= nEx > is expected to be used to address this kind of use cases, rather than > comparing with other LTE mechanisms. >=20 >=20 > 3.2- CONEX to Incentivize Scavenger Transports >=20 > While I fully understand the objective of this (basically, incentivize th= e use of > less-than-best-effort transport), I feel that this is more in the hands o= f the > application than the network, and the application probably needs some > trigger from the network to move to this kind of scavenger transport. > Therefore, you might perhaps add that additional specific mechanisms coul= d > be implemented in the network, such as the one described in section 3.3 > (Accounting for Congestion Volume), to really incentivize the application= s to > play the game. >=20 >=20 > 3.3- Accounting for Congestion Volume >=20 > IMHO, this is probably the most interesting use case for ConEx in mobile > networks: providing a more accurate form of fair usage. How to use ConEx = to > address this use case should be better described in this document. The > advantages of informing the application about the periods of congestion > could be for instance highlighted. Also, the description could be combine= d > with the previous use case described in section 3.2 (Scavenger Transports= ), > since they are in a way complementary. >=20 >=20 > 3.4- CONEX as a Form of Differential QoS >=20 > I don't really see the main difference compared to section 3.1; could you > clarify what is specific here? Perhaps both sections should be combined? >=20 >=20 > - Section 3.5: Partial vs. Full Deployment >=20 > This section is really important, as it is quite clear that ConEx will no= t be > supported everywhere in potential early deployments. Especially, as > mentioned in the draft, mobile terminals may not support the mechanisms a= t > the beginning. >=20 > Some of the schemes suggested during partial deployments may however > be difficult to be explained to the end user (e.g. "apply fixed volume ca= ps for > non-CONEX UEs and more flexible schemes for CONEX-enabled UEs"), and > therefore difficult to consider in practice. This may moreover not always= be a > matter of mobile terminal, but also of the way the application running on= the > terminal is developed - hence the potential variability. >=20 > Migration paths and partial support for ConEx should be further detailed,= in > particular how to progressively introduce ConEx in mobile networks, e.g. = in > case the features are not supported everywhere. For instance, in case the > terminals do not implement ConEx, could some ConEx functions be > implemented in the base station instead? The draft is currently not so > detailed on these aspects. >=20 > This section describes relevant areas where attention is required (roamin= g, > mobility, ...). There is however some overlapping with previous section o= n > ConEx-based data offload (it might be easily fixed). >=20 >=20 > - Section 4: ConEX in the EPS >=20 > The description of the 3 scenarios is currently very limited/weak (basica= lly > reduced to the figures...). Further details are clearly needed to underst= and > them. >=20 > For instance, I don't understand how case 1 (figure 2) could work without= the > UE supporting ConEx. How can the server know about the amount of > congestion in this case? My understanding of this scenario is that the UE= does > not even send back to the sender the congestion signal (e.g. ECN/loss) in= the > TCP layer. >=20 > It is not clear either how ConEx could operate over multiple administrati= ve > domains (e.g. multiple operators). >=20 > It should be discussed somewhere whether the purpose is to cover > congestion only over the wireless segment, only over the backhaul segment= , > or both. A section discussing how to actually manage / differentiate > congestion in the backhaul vs radio segment could be useful. Indeed, when > ECN is used, this kind of consideration may be of importance. It was good > point to reference RFC 6040 as propagation of the ECN marking across the > (GTP) tunnel may be needed. Further details about the exact option(s) to = be > used could however be useful. >=20 > The draft should recommend more clearly where to position the different > functions defined in ConEx, e.g.: > - Policer in the core network (e.g. in the GGSN / PDN-GW) > - Auditer in the base station > - Support for ConEx in the mobile terminals (as senders or receivers) > - Support for ConEx in the senders more in general (e.g. Web server) >=20 > While I understand the concept, I am not fully convinced about positionin= g > the policer in the base station for the uplink direction; that seems real= ly too > much distributed for this kind of function. Probably it depends on the ex= act > use case addressed, but if some form of user-specific accounting informat= ion > is required to the policer, this position is clearly not a good option at= all. >=20 >=20 > - Other comments >=20 > I have a general question to the group: which relationships do you see > between ConEx and UPCON activities in 3GPP? They are touching the same > aspects (namely congestions in wireless networks), but the mechanisms may > at the end be quite different (although my understanding is that the > mechanisms in UPCON are still to be defined). >=20 > For instance: > - Could ConEx be one possible solution to UPCON? > - Will UPCON be an alternative to ConEx, where the congestion > information will be carried back to the core network by another mean than > TCP layer? (e.g. inside the GTP tunnel) > - Can UPCON be considered as similar to a partial deployment of > ConEx, and be completed later when the mobile terminals will be "ConEx > aware"? >=20 > I'd be really interested to hear people's opinion on these items. >=20 > Thanks. >=20 > Cheers, >=20 > S=E9bastien >=20 > -----Message d'origine----- > De=A0: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] De la part = de > internet-drafts@ietf.org Envoy=E9=A0: jeudi 10 janvier 2013 09:19 =C0=A0:= i-d- > announce@ietf.org Cc=A0: conex@ietf.org Objet=A0: [conex] I-D Action: dra= ft-ietf- > conex-mobile-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Congestion Exposure Working Group of th= e > IETF. >=20 > Title : Mobile Communication Congestion Exposure Scenario > Author(s) : Dirk Kutscher > Faisal Ghias Mir > Rolf Winter > Suresh Krishnan > Ying Zhang > Carlos J. Bernardos > Filename : draft-ietf-conex-mobile-01.txt > Pages : 22 > Date : 2013-01-10 >=20 > Abstract: > This memo describes a mobile communications use case for congestion > exposure (CONEX) with a particular focus on mobile communication > networks such as 3GPP Evoled Packet System (EPS). The draft provides > a brief overview of the architecture of these networks (both access > and core networks), current QoS mechanisms and then discusses how > congestion exposure concepts could be applied. Based on this, this > memo suggests a set of requirements for CONEX mechanisms that > particularly apply to mobile networks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-conex-mobile >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-conex-mobile-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-mobile-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, France Telecom - > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From internet-drafts@ietf.org Thu Mar 28 11:48:23 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC421F8FF3; Thu, 28 Mar 2013 11:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 lE7cma+Mwciy; Thu, 28 Mar 2013 11:48:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14F21F9029; Thu, 28 Mar 2013 11:48:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130328184822.15390.39746.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2013 11:48:22 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 18:48:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : IPv6 Destination Option for ConEx Author(s) : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-04.txt Pages : 8 Date : 2013-03-28 Abstract: ConEx is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-destopt-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-destopt-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/