Subject: RE: [Tsvwg] Re: HEADS UP: agenda requests for San Diego

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Oct 2006 17:46:32 +0100

David,

[I allowed tsvwg to drop off the distribution. I've cc'd it this time 
quoting the missing exchange between us. Brief digest: David & I are 
agreeing that re-ECN shouldn't be in with PCN. But a wider home is needed 
for work like re-ECN, then PCN (and everyone else) can use the results.]

Yes, you're correct, traffic policing is more part of QoS than security. 
But the problem is that traffic policing has historically been a simple 
function on a box, so the community that do it don't do architecture. Here 
we are talking about policing the whole congestion feedback loop, the 
integrity of the information passed, and the responses of sources: 
architecture. As Mark Handley said, the IETF, IESG, IAB etc don't do 
architecture at all well.

As I say below, once we have enough folks at the IETF on the same page (the 
purpose of my request to talk in tsv-area to deconstruct dominant fairness 
concepts), I'm more than happy to do whatever it takes to plough a furrow 
through the IETF to get architectural change going. I've blacked out the 
next seven years in my diary for this. And actually I'm not joking. Given 
I'm leading BT's future comms architecture programme, I've made this my job 
- much wider than just re-ECN. And there's got to be a way for any the 
useful results from all this new future architecture research (FIND etc) to 
get standardised eventually, so hey, let's get started!

Regarding whether this is another QoS architecture beyond Intserv & 
Diffserv, it is. And yes, we are well on the way to a non-AIMD world within 
BE already. But once you can police congestion control, you have a QoS 
architecture at the datagram level. You don't need to signal to the 
forwarding plane of routers (as Intserv). You don't need to provision loads 
of classes for customers (as Diffserv), but you do need at least two 
classes. I explained this in our SIGCOMM paper on re-feedback.

Bob

At 15:19 13/10/2006, [email-masked] wrote:
>Bob,
>
> > Re-ECN wouldn't have the same community of interest as PCN. Re-ECN
>requires
> > a traffic policing, security type community. PCN requires a QoS
>community.
>
>To the extent that you're arguing that traffic policing is a security
>issue and not a QoS issue, I disagree.  Traffic policing *is* part of
>QoS; it just happens to have security implications.  For example, see
>the Security Considerations section of RFC 2475 (Diffserv Architecture).
>
> > PCN seems to be on the way to making a home of its own quite nicely.
>At
> > IETF-66, the transport area chairs suggested I needed to go through
>the
> > motions of doing the same for re-ECN.
>
>And I'm not sure whether that's the right approach, as it's based on
>a priori assumptions about how to divide up the larger problem space.
>
> > I figured this community should be wider than just re-ECN, titled
> > something like "misbehaving traffic" or "enforcing fairness".
>
>I think I may be pushing you to widen this community further -
>one of the things that has been frustrating me about this overall area
>is the lack of a forum to effectively focus on that larger problem
>space.
>We are dealing with some of the scarcest resources that the IETF is
>responsible for (between the DSCP and ECN fields, we have exactly 8
>bits in the IP header to work with, and there are no lack of other
>potential uses for them), so I'd like to have some confidence that
>we've sliced up the problem space correctly (or at least plausibly)
>among the various pieces that we are moving forwards.
>
>I shudder to think that I may be pushing for another Internet
>QoS architecture effort (after Intserv and Diffserv), but I suspect
>the non-AIMD response of the increasing level of real-time traffic
>plus the availability of call admission control (and preemption)
>mechanisms for that traffic are in the process of creating one,
>whether we acknowledge it or not.
>
>Thanks,
>--David
>----------------------------------------------------
>David L. Black, Senior Technologist
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>[email-masked]        Mobile: +1 (978) 394-7754
>----------------------------------------------------
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: Friday, October 13, 2006 6:23 AM
> > To: Black, David; [email-masked]
> > Subject: RE: [Tsvwg] Re: HEADS UP: agenda requests for San Diego
> >
> > David, Transport chairs,
> >
> > I should have addressed a mail like this to the Transport Area and
>TSVWG
> > chairs earlier...
> >
> > Re-ECN wouldn't have the same community of interest as PCN. Re-ECN
>requires
> > a traffic policing, security type community. PCN requires a QoS
>community.
> >
> > PCN seems to be on the way to making a home of its own quite nicely.
>At
> > IETF-66, the transport area chairs suggested I needed to go through
>the
> > motions of doing the same for re-ECN. I figured this community should
>be
> > wider than just re-ECN, titled something like "misbehaving traffic" or
>
> > "enforcing fairness".
> >
> > However, over the last couple of months I have realised just how much
> > people in the Internet community have completely misunderstood the
>relevant
> > research about fairness in an non-cooperative environment - research
>that
> > has been around for 9 years now. This research completely discredited
>the
> > idea that fairness is about allocation of rates to flows. But I'm only
>now
> > realising that most (if not all) at the IETF didn't notice. I find
>this
> > unbelieveable, but it seems to be true. So I seem to have been reading
>from
> > the Koran at a Barmitzvah.
> >
> > Hence, my request to deconstruct people's ideas of fairness through a
>talk
> > in TSV-AREA (and an I-D I'm putting the final touches to right now).
> >
> > I just wouldn't be able to bring myself to bring together a community
>of
> > people who have a set of "these things we hold true" that were shown
>to be
> > misguided 9 years ago.
> >
> >
> >
> > Bob
> >
> > At 16:18 11/10/2006, [email-masked] wrote:
> > >Stupid question - should re-ECN be part of the PCN BOF?
> > >
> > >More to the point, it would be easier to deal with this set
> > >of issues if there was a single point of focus among PCN,
> > >TSVWG and TSVAREA, although the latter is a fine place to
> > >expose topics being worked on elsewhere.
> > >
> > >Thanks,
> > >--David
> > >----------------------------------------------------
> > >David L. Black, Senior Technologist
> > >EMC Corporation, 176 South St., Hopkinton, MA  01748
> > >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> > >[email-masked]        Mobile: +1 (978) 394-7754
> > >----------------------------------------------------
> > >
> > > > -----Original Message-----
> > > > From: Bob Briscoe [mailto:[email-masked]]
> > > > Sent: Wednesday, October 11, 2006 10:47 AM
> > > > To: [email-masked]
> > > > Cc: tsvwg
> > > > Subject: Re: [Tsvwg] Re: HEADS UP: agenda requests for San Diego
> > > >
> > > > Lars, Magnus, James,
> > > >
> > > > Concerning re-ECN...
> > > >
> > > > I'd like 10mins on draft-briscoe-tsvwg-re-ecn-tcp-03.txt (to be
>uploaded soon)
> > > >
> > > > Aim: To clarify the position of re-ECN wrt the ECN nonce,
>explaining the
> > > > response I gave to Sally on the list. Also we have some deltas to
>the draft
> > > > to explain.
> > > >
> > > >
> > > > I have another request for an agenda slot, but I think it is more
> > > > appropriate for TSV-AREA, so I will post a second request to two
>of you as
> > > > chairs of that group, cc'd to that list. One aim will be to answer
>Aaron
> > > > Falk's question: "What are you trying to achieve architecturally
>with
> > > > re-ECN?" But it is much wider than just re-ECN. Do you agree this
>second
> > > > talk should be TSV-AREA?
> > > >
> > > >
> > > > Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

8.158]) by
	cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a
	P0803.399); id 1160757994948; Fri, 13 Oct 2006 17:46:34 +0100
Date: Fri, 13 Oct 2006 17:46:32 +0100
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: RE: [Tsvwg] Re: HEADS UP: agenda requests for San Diego
Cc: [email-masked], [email-masked]

David,

[I allowed tsvwg to drop off the distribution. I've cc'd it this time 
quoting the missing exchange between us. Brief digest: David & I are 
agreeing that re-ECN shouldn't be in with PCN. But a wider home is needed 
for work like re-ECN, then PCN (and everyone else) can use the results.]

Yes, you're correct, traffic policing is more part of QoS than security. 
But the problem is that traffic policing has historically been a simple 
function on a box, so the community that do it don't do architecture. Here 
we are talking about policing the whole congestion feedback loop, the 
integrity of the information passed, and the responses of sources: 
architecture. As Mark Handley said, the IETF, IESG, IAB etc don't do 
architecture at all well.

As I say below, once we have enough folks at the IETF on the same page (the 
purpose of my request to talk in tsv-area to deconstruct dominant fairness 
concepts), I'm more than happy to do whatever it takes to plough a furrow 
through the IETF to get architectural change going. I've blacked out the 
next seven years in my diary for this. And actually I'm not joking. Given 
I'm leading BT's future comms architecture programme, I've made this my job 
- much wider than just re-ECN. And there's got to be a way for any the 
useful results from all this new future architecture research (FIND etc) to 
get standardised eventually, so hey, let's get started!

Regarding whether this is another QoS architecture beyond Intserv & 
Diffserv, it is. And yes, we are well on the way to a non-AIMD world within 
BE already. But once you can police congestion control, you have a QoS 
architecture at the datagram level. You don't need to signal to the 
forwarding plane of routers (as Intserv). You don't need to provision loads 
of classes for customers (as Diffserv), but you do need at least two 
classes. I explained this in our SIGCOMM paper on re-feedback.

Bob

At 15:19 13/10/2006, [email-masked] wrote:
>Bob,
>
> > Re-ECN wouldn't have the same community of interest as PCN. Re-ECN
>requires
> > a traffic policing, security type community. PCN requires a QoS
>community.
>
>To the extent that you're arguing that traffic policing is a security
>issue and not a QoS issue, I disagree.  Traffic policing *is* part of
>QoS; it just happens to have security implications.  For example, see
>the Security Considerations section of RFC 2475 (Diffserv Architecture).
>
> > PCN seems to be on the way to making a home of its own quite nicely.
>At
> > IETF-66, the transport area chairs suggested I needed to go through
>the
> > motions of doing the same for re-ECN.
>
>And I'm not sure whether that's the right approach, as it's based on
>a priori assumptions about how to divide up the larger problem space.
>
> > I figured this community should be wider than just re-ECN, titled
> > something like "misbehaving traffic" or "enforcing fairness".
>
>I think I may be pushing you to widen this community further -
>one of the things that has been frustrating me about this overall area
>is the lack of a forum to effectively focus on that larger problem
>space.
>We are dealing with some of the scarcest resources that the IETF is
>responsible for (between the DSCP and ECN fields, we have exactly 8
>bits in the IP header to work with, and there are no lack of other
>potential uses for them), so I'd like to have some confidence that
>we've sliced up the problem space correctly (or at least plausibly)
>among the various pieces that we are moving forwards.
>
>I shudder to think that I may be pushing for another Internet
>QoS architecture effort (after Intserv and Diffserv), but I suspect
>the non-AIMD response of the increasing level of real-time traffic
>plus the availability of call admission control (and preemption)
>mechanisms for that traffic are in the process of creating one,
>whether we acknowledge it or not.
>
>Thanks,
>--David
>----------------------------------------------------
>David L. Black, Senior Technologist
>EMC Corporation, 176 South St., Hopkinton, MA  01748
>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>[email-masked]        Mobile: +1 (978) 394-7754
>----------------------------------------------------
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: Friday, October 13, 2006 6:23 AM
> > To: Black, David; [email-masked]
> > Subject: RE: [Tsvwg] Re: HEADS UP: agenda requests for San Diego
> >
> > David, Transport chairs,
> >
> > I should have addressed a mail like this to the Transport Area and
>TSVWG
> > chairs earlier...
> >
> > Re-ECN wouldn't have the same community of interest as PCN. Re-ECN
>requires
> > a traffic policing, security type community. PCN requires a QoS
>community.
> >
> > PCN seems to be on the way to making a home of its own quite nicely.
>At
> > IETF-66, the transport area chairs suggested I needed to go through
>the
> > motions of doing the same for re-ECN. I figured this community should
>be
> > wider than just re-ECN, titled something like "misbehaving traffic" or
>
> > "enforcing fairness".
> >
> > However, over the last couple of months I have realised just how much
> > people in the Internet community have completely misunderstood the
>relevant
> > research about fairness in an non-cooperative environment - research
>that
> > has been around for 9 years now. This research completely discredited
>the
> > idea that fairness is about allocation of rates to flows. But I'm only
>now
> > realising that most (if not all) at the IETF didn't notice. I find
>this
> > unbelieveable, but it seems to be true. So I seem to have been reading
>from
> > the Koran at a Barmitzvah.
> >
> > Hence, my request to deconstruct people's ideas of fairness through a
>talk
> > in TSV-AREA (and an I-D I'm putting the final touches to right now).
> >
> > I just wouldn't be able to bring myself to bring together a community
>of
> > people who have a set of "these things we hold true" that were shown
>to be
> > misguided 9 years ago.
> >
> >
> >
> > Bob
> >
> > At 16:18 11/10/2006, [email-masked] wrote:
> > >Stupid question - should re-ECN be part of the PCN BOF?
> > >
> > >More to the point, it would be easier to deal with this set
> > >of issues if there was a single point of focus among PCN,
> > >TSVWG and TSVAREA, although the latter is a fine place to
> > >expose topics being worked on elsewhere.
> > >
> > >Thanks,
> > >--David
> > >----------------------------------------------------
> > >David L. Black, Senior Technologist
> > >EMC Corporation, 176 South St., Hopkinton, MA  01748
> > >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> > >[email-masked]        Mobile: +1 (978) 394-7754
> > >----------------------------------------------------
> > >
> > > > -----Original Message-----
> > > > From: Bob Briscoe [mailto:[email-masked]]
> > > > Sent: Wednesday, October 11, 2006 10:47 AM
> > > > To: [email-masked]
> > > > Cc: tsvwg
> > > > Subject: Re: [Tsvwg] Re: HEADS UP: agenda requests for San Diego
> > > >
> > > > Lars, Magnus, James,
> > > >
> > > > Concerning re-ECN...
> > > >
> > > > I'd like 10mins on draft-briscoe-tsvwg-re-ecn-tcp-03.txt (to be
>uploaded soon)
> > > >
> > > > Aim: To clarify the position of re-ECN wrt the ECN nonce,
>explaining the
> > > > response I gave to Sally on the list. Also we have some deltas to
>the draft
> > > > to explain.
> > > >
> > > >
> > > > I have another request for an agenda slot, but I think it is more
> > > > appropriate for TSV-AREA, so I will post a second request to two
>of you as
> > > > chairs of that group, cc'd to that list. One aim will be to answer
>Aaron
> > > > Falk's question: "What are you trying to achieve architecturally
>with
> > > > re-ECN?" But it is much wider than just re-ECN. Do you agree this
>second
> > > > talk should be TSV-AREA?
> > > >
> > > >
> > > > Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196