Subject: [conex] WG energy

From: Lars Eggert <[email-masked]>
Date: Thu, 17 Feb 2011 15:30:09 +0200

Hi, folks,

this WG has become very quiet very quickly after being chartered. Given the significant community building that will be required for CONEX mechanisms to succeed in the broader IETF and ISP space, this is not a good sign.

Lars

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 17 Feb 2011 14:00:00 -0000

Hi Lars,

I know things have been quiet over the past couple of months. There has been
some off-list activity among authors, and we (the authors of the concepts
and use cases draft) are intending to post an update in a week or two.
Before that we will be starting a conversation on-list about which elements
of Dave McDysan's draft will be incorporated into the existing draft.

What worries me is the relatively limited input from outside the small group
of people that were active during the chartering of the group. That may be
down to a lack of prodding by us authors or may be a sign that people are
getting spread rather thin and are choosing not to commit cycles to ConEx.

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lars Eggert
> Sent: 17 February 2011 13:30
> To: [email-masked]
> Subject: [conex] WG energy
> 
> Hi, folks,
> 
> this WG has become very quiet very quickly after being chartered. Given
> the significant community building that will be required for CONEX
> mechanisms to succeed in the broader IETF and ISP space, this is not a
> good sign.
> 
> Lars

---

From: ken carlberg <[email-masked]>
Date: Thu, 17 Feb 2011 09:18:41 -0500

One thing that may be helpful is if the "small group of people" post some open issues to the list for input or discussion.  I know its more comfortable to have a consensus voice amoung authors, but I find it refreshing to see various opinions and open thought on lists -- regardless of where they come from.  Otherwise, the rest of us will just be lurkers and remain quiet :-)

cheers,

-ken

On Feb 17, 2011, at 9:00 AM, Toby Moncaster wrote:

> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 17 Feb 2011 08:07:16 -0800

As of the first draft the proposal was a bit too vague to champion it internally with your employer.
In particular, the degree to which an implementation could be synergistic with 802.1 DCB 
ccongestion control is still very vague.

An ideal conex draft, in my evaluation, would allow forwarding elements to implement 
*both* DCB and Conex, and suggest a method by which DCB congestion could be
reporrted to the IP stack as though it had been reported by a CONEX device.

--
Caitlin Bestler
[email-masked]
http://www.asomi.com/CaitlinBestlerResume.html

---

From: John Leslie <[email-masked]>
Date: Thu, 17 Feb 2011 13:04:11 -0500

> internally with your employer.

   Speaking as an author, I don't believe that was our aim. It's a
critical-path item for IESG approval to submit anything else.

   Nonetheless,

> In particular, the degree to which an implementation could be synergistic
> with 802.1 DCB ccongestion control is still very vague.

   Hmm...

   I suspect most of us on this list aren't terribly familiar with
802.1Qau. (That is what you're referring to, right?)

> An ideal conex draft, in my evaluation, would allow forwarding elements
> to implement *both* DCB and Conex, and suggest a method by which DCB
> congestion could be reported to the IP stack as though it had been
> reported by a CONEX device.

   I'm guessing here... 

   We've been writing in terms of something very like ECN to mark
congestion, which marks according to a queue filling.

   802.1Qau has an out-of-band mechanism to report "percent congestion"
from receiving switch to sender (if I read it correctly, I presume that
to be between two routers). This does sound like promising information,
but it's not immediately clear how it should get reported to a Layer 3
device.

   In any case, I don't believe we're wedded to ECN as the congestion-
sensing mechanism -- and I, at least, would want ConEx to be extensible
to new congestion-sensing mechanisms.

   Perhaps Caitlin could expand a bit?

--
John Leslie <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Feb 2011 04:45:06 +0100 (CET)

On Thu, 17 Feb 2011, Toby Moncaster wrote:

> What worries me is the relatively limited input from outside the small 
> group of people that were active during the chartering of the group. 
> That may be down to a lack of prodding by us authors or may be a sign 
> that people are getting spread rather thin and are choosing not to 
> commit cycles to ConEx.

If you want operational input, I suggest taking things to NANOG and other 
equivalent operational forums. Fred Baker has successfully done this with 
IPv6 stuff.

You have to face it, operators don't really come to IETF that much, so if 
you want input, you have to go to them.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 18 Feb 2011 09:53:32 -0000

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: 18 February 2011 03:45
> To: Toby Moncaster
> Cc: 'Lars Eggert'; [email-masked]
> Subject: Re: [conex] WG energy
> 

Not sure it's lack of operators that is the real problem... After all 3 of
the authors on the concepts and use cases draft work for operators.

I think where the issue comes is in convincing people that there is a
roadmap to adoption that can happen over sensible timescales. In the current
climate companies are (understandably) reluctant to stick their necks out
too far and so are tending to be fairly conservative in what they choose to
invest in. The worry I have is that the Internet is still firmly following
Moore's Law and if people are too conservative they will find they have got
left far behind.

Toby

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 22 Feb 2011 20:41:53 -0800

>   Perhaps Caitlin could expand a bit?

Each protocol has its own constraints about where the information is encoded and how often it is sent.
But I think it would be of great value to be measuring the same things in 802.1Qau congestion reporting
and IETF congestion reporting. Certainly there are many implementations where a packet may be assigned
to an output queue based on L2 factors or on L3 factors, but they are frequently the same queues.

The network stacks on end stations could really benefit from having uniform handling by a device that could
report congestion using either 802.1Qau or conex. Is 802.1Qau used universally when there is no "routing"
involved, and never when a frame is "routed"? That would seem a bit extreme when the "routing" was essentially
just relabeling the VLAN tag and the full 802.1Qau information was available.

On the other hand a conex aware forwarding element would know when a flow was not confined to the scope
required for 802.1Qau, and could properly provide feedback to the true endpoints rather than just the local
L2 endpoints. The actual source of a flow is actually capable of slowing the flow down, while an ingress
router could generally only drop packets or do ECN marking.

The other area where convergence would be useful is coming up with an abstract way to report "congestion
detected" with more precision than just an ECN bit, so that L4 can utilize this information wihtout having to
learn the specifics of L2 congestion control protocols.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 24 Feb 2011 10:21:29 -0000

> but it's not immediately clear how it should get reported to a Layer 3

Isn't 802.1Qau supposed to throttle / stop all traffic of an offending
flow (as classified by 802.1Qau - which could be of variable granularity
depending on the capabilities of the device IIRC) when congestion is
experienced?

Also, the sender in the 802.1Qau case is a L2 MAC device - which is
doing the throttling. 

The only thing a L3+ sender would notice would either be queues building
at the L3/L2 interface, or calls to send data would block instead of
immediately return. 

Obvioulsy, filling some queue right in the sender (be it a hardware or
software queue) is  a bad thing (www.bufferbloat.net), so there might be
some merit in signaling this between layers. However, as all that is
required happens within the same host, it's more of an API question
between device driver and software stack, rather than a protocol issue
concerning the explicit signaling in a L3 header... 

Of course, if the egress side of a Router is 802.1Qau, but the ingress
side is not, the router may want to inform the flow - but standard ECN
marking (available with IPv4 and IPv6) should do that... 

Or am I missing something more?

Best regards,
   Richard