Subject: [conex] draft-ietf-conex-abstract-mech-00

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 Mar 2011 00:00:12 +0000

Marcelo, Nandita, list

FYI, draft-ietf...-00 is broadly the same text as draft-mathis...-00
Just a change of filename, date etc.

We're working on updates to the text right now for -01 by Monday:

Things on our list to add:
* make Fig 1 ASCII art better, which is critical for understanding
* rationale for credit signal (promised in Beijing after requested by 
Mirja on list & others)
* normative text on the audit device (also promised in Beijing)
* A few things that ConEx is not (will address some of Nandita's 
review comments about ConEx generally when the w-g first started, and 
also suggested by Caitlin Bestler off list)

Any other suggestions?

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Nandita Dukkipati <[email-masked]>
Date: Thu, 10 Mar 2011 00:23:32 -0800

Bob, Matt,

Things on our list to add:
> * rationale for credit signal (promised in Beijing after requested by Mirja
> on list & others)
>

> * normative text on the audit device (also promised in Beijing)

So, one of the points from Beijing notes was that the content of App. A
(ConEx architectural elements) from draft-moncaster-conex-concepts-uses-02
will be included into the mechanisms draft. Is that what you mean in the
above point?

-Nandita

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 Mar 2011 11:11:46 +0000

Nandita,

2 out of 3 aspects of that appx are largely already in 
conex-abstract-mech. The third brings out an awkward problem with the 
split between docs...

1/ abstract-mech has the separation of policing into monitoring and policing
   - but we ought to bring out this distinction in the section heading
     s/Other Policy Devices/Policy Monitoring Devices/
     and switch round sections 4.4.2 & 4.4.1 with suitable adjustment of text.

2/ There's a 'ToDo' already in conex-abstract-mech to include a 
diagram like the one in the conex-concepts-uses slidesets (based on 
Fig 1 in conex-concepts-uses appxA) to show function placement This 
ought to have some textual discussion of function placement around it as well.

3/ However,...
This leaves the question of where we have discussion of partial 
deployment scenarios. To me the obvious doc for that is 
concepts-uses, which is where use-cases are. abstract-mech is 
primarily about components.

I had to rely on the notes from Beijing, because the audio didn't 
come through until later in the session (I had to rush home from 
Beijing before the session for a family matter).

The notes record agreement to remove Appx A from concepts-uses, 
describing it as "mechanism". But I didn't think of the detailed 
implications of moving the whole of appx A of concepts-uses to abstract-mech.

What I do know is that concepts-uses has to go through the IESG 
first, and if it doesn't address the issue of partial deployment 
itself, it won't get through. I don't think it will be acceptable to 
the IESG to refer off to another doc for partial deployment (Section 
5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion 
of partial deployment scenarios. Yes, it should refer to 
abstract-mech for what the components are. But then it should talk 
about how they would work in a partial deployment scenario (which was 
in the original Appx A as well).

It's unfortunate we've noticed this at such a late stage, but I'm 
glad you did notice it.

Bob

==============================================================================
PS. For convenience, I have pasted the headings of the relevant 
sections from each doc below:

draft-moncaster-conex-concepts-uses-02 had:

    Appendix A.  ConEx Architectural Elements  . . . . . . . . . . . . 20
      A.1.  ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 20
        A.1.1.  Edge Monitoring  . . . . . . . . . . . . . . . . . . . 21
        A.1.2.  Border Monitoring  . . . . . . . . . . . . . . . . . . 22
      A.2.  ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 22
        A.2.1.  Egress Policing  . . . . . . . . . . . . . . . . . . . 23
        A.2.2.  Ingress Policing . . . . . . . . . . . . . . . . . . . 24
        A.2.3.  Border Policing  . . . . . . . . . . . . . . . . . . . 25

draft-ietf-conex-abstract-mech-00 has:

    4.  Congestion Exposure Components . . . . . . . . . . . . . . . . 10
      4.1.  Modified Senders . . . . . . . . . . . . . . . . . . . . . 10
      4.2.  Receivers (Optionally Modified)  . . . . . . . . . . . . . 10
      4.3.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
      4.4.  Policy Devices . . . . . . . . . . . . . . . . . . . . . . 11
        4.4.1.  Congestion Policers  . . . . . . . . . . . . . . . . . 12
        4.4.2.  Other Policy Devices . . . . . . . . . . . . . . . . . 12

Bob

At 08:23 10/03/2011, Nandita Dukkipati wrote:
>* rationale for credit signal (promised in Beijing after requested 
>by Mirja on list & others)
>
>
>So, one of the points from Beijing notes was that the content of 
>App. A (ConEx architectural elements) from 
>draft-moncaster-conex-concepts-uses-02 will be included into the 
>mechanisms draft. Is that what you mean in the above point?
>
>-Nandita
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 11 Mar 2011 12:34:01 -0500

HI Bob,

Some responses to item 3 in line below prefixed by DM.

Thanks,

Dave

From: Bob Briscoe <[email-masked]<mailto:[email-masked]>>
Date: Thu, 10 Mar 2011 06:11:46 -0500
To: Nandita Dukkipati <[email-masked]<mailto:[email-masked]>>
Cc: ConEx IETF list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Nandita,

2 out of 3 aspects of that appx are largely already in conex-abstract-mech. The third brings out an awkward problem with the split between docs...

Snipped …

3/ However,...
This leaves the question of where we have discussion of partial deployment scenarios. To me the obvious doc for that is concepts-uses, which is where use-cases are. abstract-mech is primarily about components.

I had to rely on the notes from Beijing, because the audio didn't come through until later in the session (I had to rush home from Beijing before the session for a family matter).

The notes record agreement to remove Appx A from concepts-uses, describing it as "mechanism". But I didn't think of the detailed implications of moving the whole of appx A of concepts-uses to abstract-mech.

What I do know is that concepts-uses has to go through the IESG first, and if it doesn't address the issue of partial deployment itself, it won't get through. I don't think it will be acceptable to the IESG to refer off to another doc for partial deployment (Section 5.5.  Partial vs. Full Deployment is too high level IMO).

I propose that concepts-uses should still be the place for discussion of partial deployment scenarios. Yes, it should refer to abstract-mech for what the components are. But then it should talk about how they would work in a partial deployment scenario (which was in the original Appx A as well).

DM – Although partial deployment is not explicitly listed in the conex charter, I believe it is very important. In particular, I hope that some conex deployment would realize some benefit. A compromise that I would propose instead of ncluding all detail from the appendix in the use case document is to include a higher level narrative in the use cases document, and then have the detail in the mechanisms document.

DM – I am interpreting partial deployment from the charter in terms of experiments in operational networks (I.e., not just lab experiments or trial networks).

It's unfortunate we've noticed this at such a late stage, but I'm glad you did notice it.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 12 Mar 2011 00:25:45 +0000

David,

inline prefixed BB..

At 17:34 11/03/2011, Mcdysan, David E wrote:
>From: Bob Briscoe <<mailto:[email-masked]>[email-masked]>
>To: Nandita Dukkipati <<mailto:[email-masked]>[email-masked]>
>Cc: ConEx IETF list <<mailto:[email-masked]>[email-masked]>
>2 out of 3 aspects of that appx are largely 
>already in conex-abstract-mech. The third brings 
>out an awkward problem with the split between docs...
>
>Snipped …
>
>3/ However,...
>This leaves the question of where we have 
>discussion of partial deployment scenarios. To 
>me the obvious doc for that is concepts-uses, 
>which is where use-cases are. abstract-mech is primarily about components.
[snip]

>What I do know is that concepts-uses has to go 
>through the IESG first, and if it doesn't 
>address the issue of partial deployment itself, 
>it won't get through. I don't think it will be 
>acceptable to the IESG to refer off to another 
>doc for partial deployment (Section 
>I propose that concepts-uses should still be the 
>place for discussion of partial deployment 
>scenarios. Yes, it should refer to abstract-mech 
>for what the components are. But then it should 
>talk about how they would work in a partial 
>deployment scenario (which was in the original Appx A as well).
>
>DM – Although partial deployment is not 
>explicitly listed in the conex charter, I 
>believe it is very important. In particular, I 
>hope that some conex deployment would realize 
>some benefit. A compromise that I would propose 
>instead of ncluding all detail from the appendix 
>in the use case document is to include a higher 
>level narrative in the use cases document, and 
>then have the detail in the mechanisms document.

BB: Trouble is, this is not what abstract-mech is 
about at all. Partial deployment requires talking 
about node placement. Correct me if I'm wrong, 
but that's really out of scope for abstract-mech.

>DM – I am interpreting partial deployment from 
>the charter in terms of experiments in 
>operational networks (I.e., not just lab experiments or trial networks).

BB: Definitiely.

Bob

>It's unfortunate we've noticed this at such a 
>late stage, but I'm glad you did notice it.
>
>
>Bob
>

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 13 Mar 2011 23:51:39 +0000

Marcelo, Nandita,

Thinking more about where partial deployment text should go...

There are four different aspects to partial deployment:
1. ConEx and/or non-ConEx packets       (abstract-mech: encoding)
2. ConEx and/or non-ConEx receivers     (abstract-mech: ConEx Components)
3. Interwork with loss and/or ECN queues (abstract-mech: encoding & reqs)
4. Some networks use ConEx signals, others don't        (concepts-uses).

abstract-mech isn't a natural home for #4 because 
it's not designed to talk about why a network 
would want to use ConEx. It doesn't even mention 
networks as autonomous from each other. This is 
all the territory of concepts-uses.

BTW, David, the charter does ask us to consider partial deployment. Quoting:
         "However, the CONEX WG will initially 
focus on one use case, where the end hosts and 
the network that contains the destination end 
host are CONEX-enabled but other networks need not be."

Bob

At 00:25 12/03/2011, Bob Briscoe wrote:
>>already in conex-abstract-mech. The third 
>>brings out an awkward problem with the split between docs...
>>
>>Snipped …
>>
>>3/ However,...
>>I propose that concepts-uses should still be 
>>the place for discussion of partial deployment 
>>scenarios. Yes, it should refer to 
>>abstract-mech for what the components are. But 
>>then it should talk about how they would work 
>>in a partial deployment scenario (which was in the original Appx A as well).
>>
>>instead of ncluding all detail from the 
>>appendix in the use case document is to include 
>>a higher level narrative in the use cases 
>>document, and then have the detail in the mechanisms document.
>
>BB: Trouble is, this is not what abstract-mech 
>is about at all. Partial deployment requires 
>talking about node placement. Correct me if I'm 
>wrong, but that's really out of scope for abstract-mech.
>
>

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 14 Mar 2011 07:47:09 -0400

Hi Bob,

Do 1 and 2 in your list below include (sending) hosts (on the same network as the receiver) who do not use conex signals?

I believe this is an important aspect of partial deployment that may not fit well in the abstract mechanism draft.

Thanks,

Dave

From: Bob Briscoe <[email-masked]<mailto:[email-masked]>>
Date: Sun, 13 Mar 2011 19:51:39 -0400
To: Nandita Dukkipati <[email-masked]<mailto:[email-masked]>>, Marcelo BAGNULO BRAUN <[email-masked]<mailto:[email-masked]>>
Cc: David McDysan <[email-masked]<mailto:[email-masked]>>, ConEx IETF list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [conex] draft-ietf-conex-abstract-mech-00

Marcelo, Nandita,

abstract-mech isn't a natural home for #4 because it's not designed to talk about why a network would want to use ConEx. It doesn't even mention networks as autonomous from each other. This is all the territory of concepts-uses.

BTW, David, the charter does ask us to consider partial deployment. Quoting:
        "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."

Bob

inline prefixed BB..

Thanks,

Dave

Nandita,

Snipped …

3/ However,...

BB: Trouble is, this is not what abstract-mech is about at all. Partial deployment requires talking about node placement. Correct me if I'm wrong, but that's really out of scope for abstract-mech.

BB: Definitiely.

Bob

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 15:51:20 +0000

David,

At 11:47 14/03/2011, Mcdysan, David E wrote:
>Hi Bob,
>
>Do 1 and 2 in your list below include (sending) 
>hosts (on the same network as the receiver) who do not use conex signals?

Yes.

Well, strictly #2 is about receivers not senders. 
But 1 is about senders being free to choose 
whether to send ConEx packets or not. That is 
fundamental to partial deployment. It means some 
transports on a sender can be ConEx-enabled and others not.

But you're right. Abstract-mech only talks about 
ensuring the encoding allows ConEx or Not-ConEx 
in packets. It doesn't talk about how a network 
incentivises senders to send ConEx packets rather 
than Not-ConEx packets, wherever possible.

As Matt has said, abstract-mech doesn't have 
humans and companies in it. It just has the 
abstractions of source, network, destination, 
transport, etc. So it can't talk about deployment incentives.

Bob

>I believe this is an important aspect of partial 
>deployment that may not fit well in the abstract mechanism draft.
>
>Thanks,
>
>Dave
>
>To: Nandita Dukkipati 
><<mailto:[email-masked]>[email-masked]>, 
>Marcelo BAGNULO BRAUN <<mailto:[email-masked]>[email-masked]>
>Cc: David McDysan 
><<mailto:[email-masked]>[email-masked]>, 
>ConEx IETF list <<mailto:[email-masked]>[email-masked]>
>abstract-mech isn't a natural home for #4 
>because it's not designed to talk about why a 
>network would want to use ConEx. It doesn't even 
>mention networks as autonomous from each other. 
>This is all the territory of concepts-uses.
>
>
>>>address the issue of partial deployment 
>>>itself, it won't get through. I don't think it 
>>>will be acceptable to the IESG to refer off to 
>>>another doc for partial deployment (Section 
>>>some benefit. A compromise that I would 
>>>propose instead of ncluding all detail from 
>>>the appendix in the use case document is to 
>>>include a higher level narrative in the use 
>>>cases document, and then have the detail in the mechanisms document.
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 14 Mar 2011 17:57:37 +0100

Hi Bob, Hi Matt

I have read the draft-ietf-conex-abstract-mech-00 draft. The concept
desribed in 
this draft is very interesting. However, I have a comment related to the
measurement 
of the congestion rate at the receiver side. I think that there is a
possible 
accuracy problem related to the measurement of the congestion rate at the
receiver 
side. This problem occurs when multiple ConEx nodes that are located on the
same 
communication path are congested and therefore, marked packets might be
dropped. 

This problem, see below Figure is identified within the context of PCN and
is denoted as 
the multiple bottlenecks problem in the PCN domain, see e.g., Section B.4 in
[RFC5670]. 
In particular, consider that the nodes Q1, Q2 and Q3 are all congested. This
means that 
Q1, Q2 and Q3 will start marking the packets with the Re-Echo-ECN ConEx
code. Due to 
the fact that Q2 and Q3 are also congested, it could mean that Re-Echo-ECN 
packets that were marked by Q1 might be dropped. This might result in the
fact that 
the measured Congestion-rate at the receiver R, related to a flow, might not
be 
accurate enough. 
 
       +---+  +----+   +----+         +----+  +---+
       | S |--| Q1 |---| Q2 |---------| Q3 |--| R |
       +---+  +----+   +----+         +----+  +---+
                 ^        ^              ^
                 |        |              |
           Congested  Congested      Congested

A possible solution to this measurement accuracy problem is that in
congestion situations 
the receiver measures for each flow the Throughput instead of measuring the
congestion 
rate. In congestion situations the measured Throughput at the receiver is
sent periodically 
as feedback to the sender, see below Figure. Throughput can be defined as
the instantaneous 
rate of traffic measured at one receiver that is (1) belonging to the same
flow, (2) that is 
Not-Re-Echo-ECN marked and (3) is sent by the same sender. 

The sender always measures the Incoming rate associated with a flow. The
Incoming rate is
the instantaneous rate of traffic that is belonging to the same flow and is
sent by a sender towards 
the same receiver.
In order to calculate the Congestion rate, the sender subtracts the
Troughput from the 
Incoming rate. 

Using this calculated Congestion rate, the sender calculates the Congestion
exposure signal 
using the same method as described in draft-ietf-conex-abstract-mech-00.

   123456789012345678901234567890123456789012345678901234567890123456789
   +---------+                                               +---------+
   |         |<==Feedback Path==============================<|         |
   |         |<----------returned throughput ---------------<|         |
   |         |                                               |         |
   |Transport|                                               |Transport|
   | Sender  |>---------(new)-IP layer ConEx Signal--------->| Receiver|
   |         |        (Carried in Data Packet Headers)       |         |
   |         |             +-----------+                     |         |
   |         |>=Data=Path=>|(Congested)|>=====Data=Path=====>|         |
   |         |             |  Network  |>-Congestion-Signal->|         |
   |         |             |   Device  |                     |         |
   +---------+             +-----------+                     +---------+

    Overview ConEx architecture with throughput feedback

In order to describe this possible accuracy problem on the measurement of
the congestion rate 
and its solutions I have made an Internet draft that I would like to submit
once the IETF submission 
possibility opens again!

A preversion of this Internet draft can be found under:
http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-conex-through
put-exposure-00_not_published.txt

Best regards,
Georgios

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 17:58:22 +0000

Georgios,

I think you've misunderstood. Network nodes like Q1, Q2 & Q3 don't 
mark packets with the ConEx codes.

I hope the doc makes it clear (I just read it over and it seemed 
clear) that only the source sets ConEx markings, which then remain 
immutable through the network.

Bob

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 14 Mar 2011 20:12:15 +0000

Hi Bob

Thanks for the reply!

You are right, I misunderstood the fact that all the CoNex codes can only
be set by the sender. Can you please explain in the text that the
Congestion-Signal shown in Figure 1 is not a ConEx signal, but an ECN
marked packet.

What I actually mean is that the multiple bottlenecks accuracy problem
can occur on measuring the congestion rate using the Congestion-Signal
(e.g., ECN signal), shown in Figure 1. Taking this into account then the
nodes Q1, Q2, and Q3 shown in my example will represent three Congested
Network devices.

In order to be sure that I understood the concept correctly, can you
please inform me which node is measuring the Congestion rate. Is it the
sender by measuring the feedback signals sent by TCP Acks, or is it the
Receiver?

Can you please make this clear in the draft?

In my explanation of the accuracy problem caused by multiple bottlenecks,
I assumed that the Receiver is measuring the Congestion rate, which is
then sent back to the sender using the feedback signal.

Thus to be clear, if the Sender calculates the congestion rate using the
TCP Acks received, then the accuracy problem caused by multiple
bottlenecks might not occur, since the Sender will be able to count the
number of ECN marked packets as well as the lost packets.

However, if another type of transport protocol is used, e.g., UDP, then
my comment on the acuracy problem on measuring the congestion rate at
the Receiver will apply.

Best regards,
Georgios

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 22:55:27 +0000

Georgios,

Whoa! You're trying to correct something that is actually already 
correct. You are mistakenly thinking it's wrong.

When an ECN marked packet is dropped by another congested node 
downstream, certainly one of the two congestion events is missed, but 
that is what makes the congestion measurement *accurate*, not an 
inaccuracy that needs correcting.

Explanation:
* Congestion at one node is defined as the probability that it will 
not serve a packet (or will not serve a packet without ECN-marking it).
* End-to-end congestion is defined as the probability that a packet 
will not get through the whole path (or not get through unmarked), 
which is the combinatorial probability of it not being served by each 
node on the path (or not being served without ECN marking).

So if Q1, Q2, Q3 = 1%, 0% 2% respectively (whether loss or ECN on 
each node), then e2e congestion p is defined as:

p = 1 - (1-Q1)(1-Q2)(1-Q3)
   = 1 - 0.99*1*0.98
   = 2.98%

Importantly,
p != Q1 + Q2 + Q3
   != 3%

IOW, it's not correct to try to ensure that e2e congestion = 3%, 
because that's not the probability that a packet will not get through 
(or not get through unmarked). The right answer is meant to be 2.98%

Similarly, it would be incorrect to try to measure both congestion 
events when one packet gets marked then lost, or marked then marked 
again. It's the small probability that these multiple congestion 
events will happen to one packet that makes the correct answer 2.98% 
rather than 3%.

So it is correct that congestion is detected by the transport (the 
receiver and sender together) as either loss or ECN. If a CE marked 
packet is dropped, congestion will still be detected as a loss.

--------------------------------------------------------------------------

ConEx merely builds on the pre-existing congestion detection 
capability of Internet transports. Whether they are accurate or not 
(they are actually accurate) the idea is merely for the transport to 
tell the network what it knows.

Even if a transport wasn't accurate, I'm not interested in changing a 
transport protocol to make it slightly more accurate, before it 
reports congestion with ConEx.

Bob

---

From: Nandita Dukkipati <[email-masked]>
Date: Mon, 14 Mar 2011 18:03:19 -0700

> abstract-mech isn't a natural home for #4 because it's not designed to talk
> about why a network would want to use ConEx. It doesn't even mention
> networks as autonomous from each other. This is all the territory of
> concepts-uses.
>

Yes, agree that #4 does not belong to abstract-mech and the concepts-uses
seems a better home for it.

-Nandita

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 15 Mar 2011 05:22:39 +0000

Hi Bob

Please see in line!

>correct. You are mistakenly thinking it's wrong.

Georgios: Maybe it is correct, but the operation was not clear to me.
Please note that I was talking about Congestion rate in my email.

draft-ietf-conex-concepts-uses-01 defines Congestion rate as:

Congestion-rate:  For any granularity of traffic (packet, flow,
      aggregate, etc.), the instantaneous rate of traffic discarded or
      marked due to congestion.  Conceptually, the instantaneous bit-
      rate of the traffic multiplied by the instantaneous congestion it
      is experiencing.

As I already mentioned, my assumption was that the Receiver would measure
the congestion rate and it will then report this to the Sender. From
what I understood now is that the Receiver does not do that, but it just
uses the reliability feature of TCP (combinated with ECN). Meaning that
actually the Sender is measuring the Congestion rate (not the Receiver).
Please note that I am not sure if it is clear in the current
draft-ietf-conex-abstract-mech-01 text that the Sender is measuring the
Congestion rate.

As I already mentioned this situation can provide accurate measurements,
since the Sender, using the TCP Ack can deduce whether a downstream
packet was congested ECN marked or was dropped. Thus when a reliable
transport protocol, like TCP, is used then the calculation of the
Congestion rate at the Sender can be considered to be accurate enough.

>inaccuracy that needs correcting.

Georgios: Yes, assuming that the transport protocol is reliable and that
the congstion rate is calculated at the Sender side.

>p = 1 - (1-Q1)(1-Q2)(1-Q3)

Georgios: Okay, assuming that these probabilities (on Q1, Q2, Q3) are
independent of each other.

>(or not get through unmarked). The right answer is meant to be 2.98%

Georgios: That was not my point! In my opinion, what it should be made
clear in the draft is that CoNex should use a reliable transport
protocol that caries feedback sgnals to the Sender. Based on these
feedback signals, the Sender can accurately calculate the Congestion
rate, since it can calculate the number of congested ECN marked packets
on the downstream and as well as the number of packets that were dropped
in the downstream direction. If the Congestion rate is calculated only
at the Receiver (independent of the transport) protocol then this
measurement can be inaccurate.

>packet is dropped, congestion will still be detected as a loss.

Georgios: That was not my point, see above!

Georgios: Yes, assuming that the transport is reliable and is able to
measure not only the congestion marked packets at the downstream
direction, but also the dropped packets in the downstream direction.

>reports congestion with ConEx. 

Georgios: Yes, but then the calculation of the Congestion rate and the
use of the CoNex exposure signals in different use cases will be
inaccurate.

Best regards,
Georgios

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 15 Mar 2011 11:31:35 +0100

Hi,

just side remark: Do we cover the case what happens when a ConEx (Re-Echo) 
marked packet get dropped by a non-ConEx-aware node...?

Mirja

On Monday 14 March 2011 23:55:27 Bob Briscoe wrote:
> > >>this draft is very interesting. However, I have a comment related to
> > >> the measurement
> > >>accuracy problem related to the measurement of the congestion rate at
> > >> the receiver
> > >>side. This problem occurs when multiple ConEx nodes that are located on
> > >> the same
> > >>This problem, see below Figure is identified within the context of PCN
> > >> and is denoted as
> > >>the multiple bottlenecks problem in the PCN domain, see e.g.,
> >
> > Section B.4 in
> >
> > >>[RFC5670].
> > >>In particular, consider that the nodes Q1, Q2 and Q3 are all
> >
> > congested. This
> >
> > >>means that
> > >>the fact that Q2 and Q3 are also congested, it could mean that
> > >> Re-Echo-ECN packets that were marked by Q1 might be dropped. This
> > >> might result in the fact that
> > >>the measured Congestion-rate at the receiver R, related to a
> >
> > flow, might not
> >
> > >>be
> > >>accurate enough.
> > >>
> > >>the receiver measures for each flow the Throughput instead of measuring
> > >> the congestion
> > >>rate. In congestion situations the measured Throughput at the receiver
> > >> is sent periodically
> > >>as feedback to the sender, see below Figure. Throughput can be defined
> > >> as the instantaneous
> > >>rate of traffic measured at one receiver that is (1) belonging to the
> > >> same flow, (2) that is
> > >>The sender always measures the Incoming rate associated with a flow.
> > >> The Incoming rate is
> > >>the instantaneous rate of traffic that is belonging to the same flow
> > >> and is sent by a sender towards
> > >>the same receiver.
> > >>Using this calculated Congestion rate, the sender calculates the
> > >> Congestion exposure signal
> > >>    |         |<==Feedback Path==============================<|        
> > >>    |         | | <----------returned throughput ---------------<|     
> > >>    |         |    |
> > >>    |
> > >>    |Transport|                                              
> > >>    | |Transport| Sender  |>---------(new)-IP layer ConEx
> > >>    | Signal--------->| Receiver|
> > >>    |
> > >>    |         |        (Carried in Data Packet Headers)       |        
> > >>    |         | | +-----------+                     |         |
> > >>    |         |
> > >>    |         |>=Data=Path=>|(Congested)|>=====Data=Path=====>|        
> > >>    |         |> |
> > >>    |         |>
> > >>    |         |             |  Network  |>-Congestion-Signal->|        
> > >>    |         |             | | Device  |                     |        
> > >>    |         |             | |
> > >>
> > >>In order to describe this possible accuracy problem on the measurement
> > >> of the congestion rate
> > >>and its solutions I have made an Internet draft that I would like to
> > >> submit once the IETF submission
> > >>possibility opens again!
> > >>
> > >>http://wwwhome.cs.utwente.nl/~karagian/conex/draft-karagiannis-con
> >
> > ex-through
> >

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 15 Mar 2011 12:45:12 +0100

Hi Mirja

Before this question can be answered, I think that it is important that two
questions are answered:

Are the Audit devices the only CoNex devices that are actually comparing an
actual congestion signal
with a Congestion Exposure Signal sent from the sender?

Are the used ConEx aware packets using TCP as transport protocol?

Does the TCP connection used by these ConEx aware packets starting/ending at
the Sender (Host) and at the Audit devices? 
Or is this starting/ending at the Sender (host) and Receiver (host)?

Best regards,
Georgios

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]] 
> Sent: dinsdag 15 maart 2011 11:32
> To: [email-masked]
> Cc: Bob Briscoe; Georgios Karagiannis
> Subject: Re: [conex] comments on draft-ietf-conex-abstract-mech-00
> 
> Hi,
> 
> just side remark: Do we cover the case what happens when a 
> ConEx (Re-Echo) marked packet get dropped by a 
> non-ConEx-aware node...?
> 
> Mirja
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 16 Mar 2011 06:57:05 +0000

Hi Bob

I think that I was probably not clear enough in one of my statements
below.
Consider that the following statement that I have used in the email
below, should be changed from:

>If the Congestion rate is calculated only

INTO:

When a transport protocl is not able to count the lost packets at the
Receiver side and when the Congestion rate is calculated at the Receiver
then the Congestion rate measurement can be inaccurate.

This change in my statement is needed since in TCP, the receiver by using
the receiver window, see RFC5681, could calculate the number of lost
packets.

Thus in case of TCP, the Congestion rate could also be calculated at the
Receiver side.

So the multiple bottleneck problem associated with the measurement of the
Congestion rate that I have emphasized in the previous emails apply to
situations where the Congestion rate is measured at the Receiver and
when the used transport protocol is not able to count the lost packets
at the Receiver side.

Best regards,
Georgios