Re: [Dclc] Agenda topics

Bob Briscoe <bob.briscoe@bt.com> Mon, 27 October 2014 22:34 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: dclc@ietfa.amsl.com
Delivered-To: dclc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FCE1A1B2F for <dclc@ietfa.amsl.com>; Mon, 27 Oct 2014 15:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYq0tBJ-uLcK for <dclc@ietfa.amsl.com>; Mon, 27 Oct 2014 15:33:58 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201D01A1B23 for <dclc@irtf.org>; Mon, 27 Oct 2014 15:33:57 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 28 Oct 2014 02:51:45 +0000
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 27 Oct 2014 22:33:53 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 27 Oct 2014 22:33:50 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.38.168]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9RMXm8h017085; Mon, 27 Oct 2014 22:33:49 GMT
Message-ID: <201410272233.s9RMXm8h017085@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 27 Oct 2014 22:33:24 +0000
To: "Fred Baker (fred)" <fred@cisco.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <CD5957AA-B604-4BBC-8F5E-404585FA2C5E@cisco.com>
References: <D8EC17A9-A105-484F-B36F-7806A1A80D48@cisco.com> <C5C3BB522B1DDF478AA09545169155B46D842B70@nkgeml507-mbx.china.huawei.com> <1903A114-C834-472D-9AA3-52983FE8972D@netapp.com> <CD5957AA-B604-4BBC-8F5E-404585FA2C5E@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
Archived-At: http://mailarchive.ietf.org/arch/msg/dclc/bP2Tsrte-TUDVklNQeen3dn02wM
Cc: Weixinpeng <weixinpeng@huawei.com>, "Eggert, Lars" <lars@netapp.com>, dclc <dclc@irtf.org>
Subject: Re: [Dclc] Agenda topics
X-BeenThere: dclc@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of Data Center Latency Control <dclc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dclc>, <mailto:dclc-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dclc/>
List-Post: <mailto:dclc@irtf.org>
List-Help: <mailto:dclc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dclc>, <mailto:dclc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 22:34:06 -0000

Fred, Lars,

This is the same technique, but applied to a data centre by 
implementing the tunnel endpoints in the hypervisors:
<https://tools.ietf.org/html/draft-briscoe-conex-data-centre-02>

It's the one I had prepared a presentation for in the last dclc mtg, 
but I gave up the slot so we had longer to discuss the direction of the group.
<http://www.bobbriscoe.net/presents/1407ietf/1407dc-congestion-policing.pdf>
(I'd be happy to present it this time - perhaps in conjunction with 
Xinpeng if you establish that it will be relevant to data centres)


And, to respond to Toby's IPR point, back in 2005 BT declared its IPR 
related to this, and updated the declaration in 2012, including 
royalty-free terms under the conditions specified here:
<https://datatracker.ietf.org/ipr/1922/>



Bob

At 15:39 27/10/2014, Fred Baker (fred) wrote:
>Content-Language: en-US
>Content-Type: multipart/signed;
>         boundary="Apple-Mail=_44D5A9BE-946A-4C98-96DA-75F726FDCBE8";
>         protocol="application/pgp-signature"; micalg=pgp-sha1
>
>
>On Oct 27, 2014, at 2:09 AM, Eggert, Lars <lars@netapp.com> wrote:
>
> > Hi Xinpeng,
> >
> > On 2014-10-27, at 09:21, Weixinpeng <weixinpeng@huawei.com> wrote:
> >> It will be appreciated if there is a timeslot for me to show our 
> work on tunnel-based congestion control.
> >> The following is a link to the document.
> >> 
> http://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-congestion-feedback/
> >
> > could you outline how this draft is related to latency control in 
> datacenters? I read an earlier version and it seemed to be all 
> about wide area networks?
> >
> > Thanks,
> > Lars
>
>I'm scratching my head as well. Lingli is a co-author, so maybe she 
>can comment here.
>
>The draft does mention NFV, which can be implemented across multiple 
>data centers connected by a WAN, but if primarily implemented within 
>a data center, and specifically mentions data centers. It also 
>mentioned latency in passing, in the third paragraph of the section on 3GPP.
>
>Where I'm scratching my head is figuring out what it's actually 
>trying to say. It explains NFV and that tunnels might be implemented 
>in a vSwitch, which is true, and often the case in architectures 
>such as OpenStack. It doesn't seem to make obvious points about that 
>such as are made in RFC 2983: when the tunnel is marked as having 
>experienced congestion, that information needs to be reflected in 
>the interior header at the tunnel endpoint. It talks quite a bit 
>about IPFIX. I'm not sure I walked away with "so do this".
>
>
>_______________________________________________
>Dclc mailing list
>Dclc@irtf.org
>https://www.irtf.org/mailman/listinfo/dclc

________________________________________________________________
Bob Briscoe,                                                  BT