Subject: [Dclc] Agenda topics

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 23 Oct 2014 15:17:57 +0000

We are scheduled for a meeting at IETF 91 in Honolulu. Looking for agenda items.

---

From: Weixinpeng <[email-masked]>
Date: Mon, 27 Oct 2014 08:21:38 +0000

Hi Fred,
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/ 

Thanks!
-Xinpeng
>-----Original Message-----
>From: Dclc [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
>Sent: Thursday, October 23, 2014 11:18 PM
>To: dclc
>Subject: [Dclc] Agenda topics
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 27 Oct 2014 09:09:07 +0000

Hi Xinpeng,

> 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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 27 Oct 2014 15:39:43 +0000

> 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?

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”.

---

From: Toby Moncaster <[email-masked]>
Date: Mon, 27 Oct 2014 15:43:51 +0000

I’m also contemplating whether it needs an IPR disclosure on this:

http://www.google.com/patents/EP2258079B1?cl=en

Which I was working on at BT a few years ago.

Toby

On 27 Oct 2014, at 15:39, Fred Baker (fred) <[email-masked]> wrote:

> _______________________________________________
> Dclc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dclc

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 27 Oct 2014 15:49:13 +0000

Please don’t post links to patents on IETF/IRRTF lists.

If you need to make a third-party disclosure, please do so at https://datatracker.ietf.org/ipr/about/

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 22:33:24 +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
>
>
> > 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".
>
>

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 27 Oct 2014 23:34:21 +0000

On Oct 27, 2014, at 3:33 PM, Bob Briscoe <[email-masked]> wrote:

> Fred, Lars,
> 
> This is the same technique, but applied to a data centre by implementing the tunnel endpoints in the hypervisors:
> 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.
> (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)

Maybe the two discussions. I agree that a vSwitch or hypervisor can be the tunnel endpoint, and RFC 2983 tells us how to manage the CU flags between the two IP headers. The question in my mind is how that interacts with latency.

Where things stand right now, this is likely to be our entire agenda. There is some work from KAIST and RedHat/Morgan Stanley that I would have liked to see discussed, and they want to delay until March.

I’ll post an agenda showing the two discussions. Happy to have discussion from the floor as well.

> 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:
>> I'm scratching my head as well. Lingli is a co-author, so maybe she can comment here.
>> 
>> 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".
>> 
>>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 23:54:47 +0000

Fred,

At 23:34 27/10/2014, Fred Baker (fred) wrote:

> > 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.
> > 
> > (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)
>
>Maybe the two discussions. I agree that a vSwitch or hypervisor can 
>be the tunnel endpoint, and RFC 2983 tells us how to manage the CU 
>flags between the two IP headers. The question in my mind is how 
>that interacts with latency.

I can't answer for Xinpeng, but in my case there's a congestion 
policer in each ingress hypervisor and the fill rates of all the 
tenants' token buckets (in units of ECN marks) bounds the growth of 
the FIFO AQM queue that all tenants share. This policer focuses drop 
on any tenant(s) that would otherwise cause heavier congestion, but 
it isolates all the other tenants from any queuing beyond the configured bound.

The pathetic part is I can't give any results, at least not in a data 
centre scenario.

Bob

>Where things stand right now, this is likely to be our entire 
>agenda. There is some work from KAIST and RedHat/Morgan Stanley that 
>I would have liked to see discussed, and they want to delay until March.
>
>I'll post an agenda showing the two discussions. Happy to have 
>discussion from the floor as well.
>
> > 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 
> >> >> It will be appreciated if there is a timeslot for me to show 
> our work on tunnel-based congestion control.
> >> > could you outline how this draft is related to latency control 
> in datacenters? I read an earlier version and it seemed to be all 
> >> 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.
> >>
> 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".
> >>
> >>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 27 Oct 2014 23:58:57 +0000

On Oct 27, 2014, at 4:54 PM, Bob Briscoe <[email-masked]> wrote:

> I can't answer for Xinpeng, but in my case there's a congestion policer in each ingress hypervisor and the fill rates of all the tenants' token buckets (in units of ECN marks) bounds the growth of the FIFO AQM queue that all tenants share. This policer focuses drop on any tenant(s) that would otherwise cause heavier congestion, but it isolates all the other tenants from any queuing beyond the configured bound.
> 
> The pathetic part is I can't give any results, at least not in a data centre scenario.

I know the feeling. But we can discuss the concept.

>> I'll post an agenda showing the two discussions. Happy to have discussion from the floor as well.
>>

---

From: Weixinpeng <[email-masked]>
Date: Tue, 28 Oct 2014 07:35:19 +0000

Hi all,
Thanks for your comments.
Let me give some more detailed clarification on this issue.
You are right that the initial purpose of draft-wei-tsvwg-tunnel-congestion-feedback is to solve network congestion,
ECN is used in the tunnel, ECN marks are used as an indication of congestion status of routers' buffers, and the document
tries to provide a solution to feed back this indication to tunnel ingress for the ingress to implement congestion control.

We assume latency mainly caused by queue length in the network.
For congestion control, the packets are marked when the buffer is filled to a specific threshold; but for latency control, we can
mark packets in another way: the packets are marked according to queue's length, which means as queue grows the number of marked
packets grows, as queue decreases the number of marked packets decreases. So we can collect the number of marked packets to learn about
information of queue length status and to do latency control at tunnel ingress based on this information.

About IPFIX, I am not sure whether it is suitable in DC, we can see it just as a possible method for information feedback, and there could be
other candidates. So I suggest currently we don't focus on this aspect.

Regards,
-Xinpeng

>From: Bob Briscoe [mailto:[email-masked]]
>Sent: Tuesday, October 28, 2014 6:33 AM
>To: Fred Baker (fred)
>Cc: Eggert, Lars; Weixinpeng; dclc
>Subject: Re: [Dclc] Agenda topics
>
>Fred, Lars,
>
>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.
>(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:
>> datacenters? I read an earlier version and it seemed to be all about
>> wide area networks?
>> >
>> > Thanks,
>> > Lars
>>
>>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".
>>
>>