Subject: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt

From: [email-masked]
Date: Mon, 14 Mar 2011 16:00:02 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion Exposure Working Group of the IETF.

    Title         : Congestion Exposure (ConEx) Concepts and Abstract Mechanism

    Author(s)     : M. Mathis, et al
    Filename      : draft-ietf-conex-abstract-mech-01.txt
    Pages         : 18
    Date          : 2011-03-14
    
This document describes an abstract mechanism by which senders inform
   the network about the congestion encountered by packets earlier in
   the same flow.  Today, the network may signal congestion to the
   receiver by ECN markings or by dropping packets, and the receiver
   passes this information back to the sender in transport-layer
   feedback.  The mechanism to be developed by the ConEx WG will enable
   the sender to also relay this congestion information back into the
   network in-band at the IP layer, such that the total level of
   congestion is visible to all IP devices along the path, from where it
   could, for example, provide input to traffic management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Michael Menth <[email-masked]>
Date: Sat, 26 Mar 2011 22:36:42 +0100

Hi Bob, hi Matt,

I read the conex concepts draft.

The section on audits needs rework. An explantation of audits must go 
first, then the two different approaches may come.

Why do you differentiate between re-echo-ECN, re-echo-loss, and credits?
The conex policer treats them all just as conex-marked, right?
But the auditing device respects only re-echo-ECN and credits. Why? Is 
that because it cannot see losses in the data path?

Best wishes,

     Michael

Am 15.03.2011 00:00, schrieb [email-masked]:
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: Nandita Dukkipati <[email-masked]>
Date: Mon, 28 Mar 2011 21:11:44 +0200

My comments on this draft are as an individual contributor.

First of, nice draft! Overall reads well and the points being made are
clear. A couple of high level questions and a few minor ones.

1) Of the three kinds of encoding schemes described (ECN based, independent
bits, and codepoint), ultimately we have to go with one - which one would
you recommend and why? What are the other factors external to this draft
that the choice is dependent on?

2) The use of credit to simplify audit is a nice concept. While it makes
audit easier, it does push the onus onto the hosts to build up sufficient
credit. Any thoughts on how a transport may know in advance on how to build
up credit prior to receiving any ECN signals? It's out of scope for this
draft, but the TCP modifications draft needs to address this.

[Clarification qs]
3) Sec. 2 - "For congestion signaled by ECN, auditing is most accurate when
located near the transport receiver.  Within any flow or aggregate of flows,
the volume of data tagged with ConEx Signals should never be less than the
total volume of ECN marked data seen near the receiver."
This statement doesn't necessarily hold true in the presence of reverse
congestion when ACKs may get lost. Correct?

4) Sec 3.3.2 Codepoint Encoding
What's the purpose of ConEx-Not-Marked? Is there an equivalent of it with
independent bits encoding?

5) Sec 4.3 Audit
Is it fair to assume that Re-Echo-Loss signal is marked only on
retransmitted packets? If not, what are the scenarios where non-retrans.
packets can carry Re-Echo-Loss?

6) Sec. 1.1 Terminology
What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I didn't see
the use of them in rest of the draft.

-Nandita

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Mar 2011 01:31:00 +0100

Nandita,

At 20:11 28/03/2011, Nandita Dukkipati wrote:
>First of, nice draft! Overall reads well and the points being made 
>are clear. A couple of high level questions and a few minor ones.

Mikael's comments make me realise though that we still have to be a 
lot clearer about what ConEx is not.

Also, I've recently read RFC4301 Writing Protocol Models, which we 
ought to try to follow - it has good advice for writing protocol 
drafts, especially this abstract one ought to follow it.

And I think it would help to put the policy function & audit function 
in a second figure that is otherwise similar to the first (which we 
do when presenting slides).

>1) Of the three kinds of encoding schemes described (ECN based, 
>independent bits, and codepoint), ultimately we have to go with one 
>- which one would you recommend and why? What are the other factors 
>external to this draft that the choice is dependent on?

This is intended to remain open while encoding issues are discussed.

I would say
- independent bits is overkill
- Codepoint is sufficient, and
- ECN is last resort if we only have one bit.
I guess we could say that (if Matt agrees).

>2) The use of credit to simplify audit is a nice concept. While it 
>makes audit easier, it does push the onus onto the hosts to build up 
>sufficient credit. Any thoughts on how a transport may know in 
>advance on how to build up credit prior to receiving any ECN 
>signals? It's out of scope for this draft, but the TCP modifications 
>draft needs to address this.

My thesis has loads of simulation expts on this. I plan to publish it 
by May'11 (I have to by Uni regulations). Mirja has also reported on 
her expts (first ConEx mtg I think).

The idea is that it depends how well other parts of the code avoid 
overshoot at the end of slow-start. For instance, the latest Linux 
does packet-pair on each pair of packets released by each ack during 
slow-start, and gets a good estimate of where ssthresh should start this way.

>[Clarification qs]
>3) Sec. 2 - "For congestion signaled by ECN, auditing is most 
>accurate when located near the transport receiver.  Within any flow 
>or aggregate of flows, the volume of data tagged with ConEx Signals 
>should never be less than the total volume of ECN marked data seen 
>near the receiver."
>This statement doesn't necessarily hold true in the presence of 
>reverse congestion when ACKs may get lost. Correct?

If working with an unmodified recvr, I agree.

However, the scheme for modifying TCP's ECN feedback (in re-ECN, 
which I believe Mirja is going to put in the ConEx TCP draft) 
maintains a correct count robust to ack loss (at least once you get 
an ack again after a loss).

>What's the purpose of ConEx-Not-Marked? Is there an equivalent of it 
>with independent bits encoding?

It means ConEx is supported, but nothing is being re-echoed. The need 
to distinguish ConEx from non-ConEx packets is motivated at the start.

Relative to independent bits, it's equivalent to 'ConEx' with all the 
other flags off (Not-*).

>retransmitted packets? If not, what are the scenarios where 
>non-retrans. packets can carry Re-Echo-Loss?

If TCP or a reliable transport, former is correct.
But ConEx is for any transport.

In the detailed TCP spec, we will need to say what the sender does in 
response to a ConEx marked packet being dropped etc. (one of 
Georgios's points).

>6) Sec. 1.1 Terminology
>What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I 
>didn't see the use of them in rest of the draft.

They tend to get used a lot when explaining ConEx, so we thought it 
best to put them in here, even though we don't use them ourselves.

Black, Red, Green & Grey have fairly intuitive meanings (at least for 
me from a western culture) of Credit, debit, start and neutral.

Purple was an attempt to find a colour that hadn't already been used 
and that was close to black.

HTH

Bob

>-Nandita
>
>On Mon, Mar 14, 2011 at 4:00 PM, 
><<mailto:[email-masked]>[email-masked]> wrote:
><http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt>http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>
><mailto:[email-masked]>[email-masked]

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: John Leslie <[email-masked]>
Date: Tue, 29 Mar 2011 07:03:26 -0400

> My comments on this draft are as an individual contributor.

   Nonetheless, Nandita, you can't entirely escape your WGC role...

> external to this draft that the choice is dependent on?

   I don't think it's appropriate for the authors to choose one yet.

   As far as external factors, that's certainly appropriate to discuss,
but you're not clear whether you are suggesting discussing it _in_ the
I-D.

> sufficient credit. Any thoughts on how a transport may know in advance
> on how to build up credit prior to receiving any ECN signals? It's out
> of scope for this draft, but the TCP modifications draft needs to
> address this.

   As you said, out of scope for this draft. I suggest it be discussed
in a separate thread.

> [Clarification qs]
> 3) Sec. 2 - "For congestion signaled by ECN, auditing is most accurate
> when located near the transport receiver.  Within any flow or aggregate
> of flows, the volume of data tagged with ConEx Signals should never be
> less than the total volume of ECN marked data seen near the receiver."

   I don't follow...

   Are you concentrating on the "never"?

   Lost ACKs merely delay the signal. I read this text to say that, in
aggregate, ConEx congestion-expected markings should equal or exceed
ECN congestion-experienced markings. Both travel the same direction
(and arguably the same path) and neither is affected by the particulars
of how the sender learns of congestion.

> with independent bits encoding?

   I'll leave that one for Bob...

> packets can carry Re-Echo-Loss?

   Likewise.

> 6) Sec. 1.1 Terminology
> What is the purpose of colors (Re-Echo-Loss aka Purple etc.)? I didn't
> see the use of them in rest of the draft.

   I believe that's a historical artifact. It _did_ make things easier
to follow on some old Bob Briscoe slides. ;^)

--
John Leslie <[email-masked]>

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 29 Mar 2011 16:07:01 +0100

Inline marked {TM}

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bob Briscoe
Sent: 29 March 2011 01:31
To: Nandita Dukkipati
Cc: [email-masked]
Subject: Re: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt

Nandita,

Mikael's comments make me realise though that we still have to be a lot
clearer about what ConEx is not.

Also, I've recently read RFC4301 Writing Protocol Models, which we ought to
try to follow - it has good advice for writing protocol drafts, especially
this abstract one ought to follow it.

And I think it would help to put the policy function & audit function in a
second figure that is otherwise similar to the first (which we do when
presenting slides).

I would say 

{TM} I would suggest that rather than specify this too precisely, give some
commentary on what might influence the decision (e.g. trade-off between
efficient use of bits and effective provision of ConEx functionality)

My thesis has loads of simulation expts on this. I plan to publish it by
May'11 (I have to by Uni regulations). Mirja has also reported on her expts
(first ConEx mtg I think).

The idea is that it depends how well other parts of the code avoid overshoot
at the end of slow-start. For instance, the latest Linux does packet-pair on
each pair of packets released by each ack during slow-start, and gets a good
estimate of where ssthresh should start this way.

[Clarification qs]

However, the scheme for modifying TCP's ECN feedback (in re-ECN, which I
believe Mirja is going to put in the ConEx TCP draft) maintains a correct
count robust to ack loss (at least once you get an ack again after a loss).

It means ConEx is supported, but nothing is being re-echoed. The need to
distinguish ConEx from non-ConEx packets is motivated at the start.

Relative to independent bits, it's equivalent to 'ConEx' with all the other
flags off (Not-*).

5) Sec 4.3 Audit

In the detailed TCP spec, we will need to say what the sender does in
response to a ConEx marked packet being dropped etc. (one of Georgios's
points).

6) Sec. 1.1 Terminology

They tend to get used a lot when explaining ConEx, so we thought it best to
put them in here, even though we don't use them ourselves.

Black, Red, Green & Grey have fairly intuitive meanings (at least for me
from a western culture) of Credit, debit, start and neutral.

{TM} Although using green for start does give a possible connotation of red
for stop... 

Purple was an attempt to find a colour that hadn't already been used and
that was close to black.

{TM} If the colours aren't going to be used in this document it may not be
the best place to define them...

HTH

Bob

-Nandita

On Mon, Mar 14, 2011 at 4:00 PM, <[email-masked] > wrote:

A new Internet-Draft is available from the on-line Internet-Drafts
directories.

This draft is a work item of the Congestion Exposure Working Group of the
IETF.

   Title         : Congestion Exposure (ConEx) Concepts and Abstract
Mechanism

   Pages         : 18

   Date          : 2011-03-14

Internet-Draft.

conex mailing list

[email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 30 Mar 2011 13:42:09 +0100

Toby,

>Inline marked {TM}

snip

>{TM} I would suggest that rather than specify this too precisely, 
>give some commentary on what might influence the decision (e.g. 
>trade-off between efficient use of bits and effective provision of 
>ConEx functionality)

Sounds reasonable.

>{TM} If the colours aren't going to be used in this document it may 
>not be the best place to define them...

On balance we thought it best to include them here - I think we 
should actually use them in this doc, which would make your objection go away.

Cheers

Bob

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 30 Mar 2011 13:59:59 +0100

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 30 March 2011 13:42
> To: Toby Moncaster
> Cc: 'Nandita Dukkipati'; [email-masked]
> Subject: RE: [conex] I-D ACTION:draft-ietf-conex-abstract-mech-01.txt
> 
> Toby,
> 

> should actually use them in this doc, which would make your objection

Indeed it would... And as experience suggests many people find the colours
helpful, perhaps it would be wise to use them in the document.

Toby

---

From: Nandita Dukkipati <[email-masked]>
Date: Thu, 31 Mar 2011 12:21:47 +0200

>> {TM} I would suggest that rather than specify this too precisely, give
>> some commentary on what might influence the decision (e.g. trade-off between

I like the comment made by Toby - to discuss the tradeoffs with various
encoding schemes. That way we know precisely the pros/cons of each one when
it comes to the point of choosing one.