Subject: [conex] Observations regarding the Conex concept

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 22 Mar 2011 20:17:45 +0000

Hi all

After discussing with Mirja and based on the previous Conex email
discussions with Bob, I have derived some observations regarding the
Conex concept, see below. These observations are expressed in questions.
Hopefully we can answer them easily.

Observation 1:
Must the sender (of the data path and Conex exposure signals) be able to
identify which packets were lost in the downstream direction, in
addition to the calculated number of ECN marked packets in the
downstream direction?

Observation 2:
If a sender sent a packet that carried a Congestion exposure signal and
realizes that this packet is lost, should this sender include the same
Congestion exposure signal in a retransmitted packet?

Observation 3:
Should a router/device not preferentially drop ECN congested marked
packets?

Observation 4:
Should a router/device not preferentially drop Conex exposure marked
packets?

Observation 5:
Should the Conex WG specify the operation of all Conex aware nodes?

Best regards,
Georgios

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Mar 2011 15:32:14 -0400

> addition to the calculated number of ECN marked packets in the

   No.

   Well, at least not in order to be fully ConEx-enabled...

   _If_ the sender is speaking TCP, that is required by TCP; but for
ConEx purposes, whether the lost packets are ever re-transmitted is
quite strictly out-of-scope.

> Congestion exposure signal in a retransmitted packet?

   Generally not.

   There is an assumption that ConEx will operate in an environment where
the same packet can't be dropped twice. ;^)

   While it is possible that the same packet will be marked at one node
and dropped at another, this is considered an outlier; and re-marking
a retransmitted packet in hopes of exposing the right expected-congestion
to yet a third node really doesn't make sense.

   (Of course, the re-transmitted lost-packet might be marked for a
different reason...)

> Should a router/device not preferentially drop ECN congested marked

   Not sure I understand the question, with a double-negative...

   I'm guessing you mean, is there a reason to drop something else in
preference to dropping a ConEx-marked packet. I'd answer that there is
a reason, though I don't think we have consensus to recommend it yet:
the reason being that the backoff by the sender can come sooner (just
as is the case for ECN-marking instead of dropping).

> Should a router/device not preferentially drop Conex exposure marked

   I'm left guessing again: the same reason applies to any ConEx-marked
packet that would otherwise be eligible for drop due to congestion --
whether it is marked ConEx-aware or Congestion-Expected.

> Should the Conex WG specify the operation of all Conex aware nodes?

   We should specify what it means to be ConEx-aware, which will constrain
the operation of a "ConEx-aware" node, but not fully specify other actions
it may take.

--
John Leslie <[email-masked]>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 24 Mar 2011 15:31:14 +0100

Hi John

Please see in line!

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]] 
> Sent: woensdag 23 maart 2011 20:32
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [conex] Observations regarding the Conex concept
> 
> > Must the sender (of the data path and Conex exposure 
> signals) be able 
> > to identify which packets were lost in the downstream direction, in 
>    _If_ the sender is speaking TCP, that is required by TCP; 
> but for ConEx purposes, whether the lost packets are ever 
> re-transmitted is quite strictly out-of-scope.

Georgios: But if the sender is not be able to identify which packets were
lost in the downstream direction, 
then the calculation of the congestion rate will be inaccurate. Note that
the congestion rate is the sum of the rate of packets that are lost 
and the packets that were ECN marked in the downsstream direction.

> 
> > Observation 2:
> > If a sender sent a packet that carried a Congestion exposure signal 
> > and realizes that this packet is lost, should this sender 
> include the 
> > same Congestion exposure signal in a retransmitted packet?
> 
>    Generally not.
> 
>    There is an assumption that ConEx will operate in an 
> environment where the same packet can't be dropped twice. ;^)
> 
>    While it is possible that the same packet will be marked 
> at one node and dropped at another, this is considered an 
> outlier; and re-marking a retransmitted packet in hopes of 
> exposing the right expected-congestion to yet a third node 
> really doesn't make sense.
> 
>    (Of course, the re-transmitted lost-packet might be marked 
> for a different reason...)

Georgios: I think that the answer of this question is more complex than your
answer!
In my opinion we need to do evaluation studies to find out what is the
impact of 
retransmitting or not retransmitting lost Congestion exposure signals.

>    I'm guessing you mean, is there a reason to drop something 
> else in preference to dropping a ConEx-marked packet. I'd 
> answer that there is a reason, though I don't think we have 
> consensus to recommend it yet:
> the reason being that the backoff by the sender can come 
> sooner (just as is the case for ECN-marking instead of dropping).

Georgios: Yes, the reason is a congestion. In a congestion situation a
router might drop packets. Most routers implement the simple FIFS/FIFO Tail
drop queing mechanism. This means that ECN marked packets may be dropped by
congested routers. This will mean that the receiver might not receive ECN
marked packets when one or more routers in the downstream path from sender
to receiver are congested. This will aslo mean that the Sender will not be
able to know that the lost packet was ECN marked. If the queuing mechanims
in the router is such that ECN marked packets are not dropped in congestion
situations then the problem that I mentioned earlier will not occur and the
receiver and Sender will be notified about the ECN marked packet.

>    I'm left guessing again: the same reason applies to any 
> ConEx-marked packet that would otherwise be eligible for drop 
> due to congestion -- whether it is marked ConEx-aware or 
> Congestion-Expected.

Georgios: The reason is again a congestion. In a congestion situation a
router might drop packets. Most routers implement the simple FIFS/FIFO Tail
drop queing mechanism. This means that Conex exposure marked packets may be
dropped by congested routers. This will mean that Audit devices and the
receiver might not receive Conex exposure marked packets when one or more
routers in the path from sender to receiver are congested. This will aslo
mean that the Audit devices and the receiver will not be able to calculate
in an accurate way the rate of the Conex exposure signals apassing by. If
the queuing mechanims in the router is such that Conex exposure marked
packets are not dropped in congestion situations then the problem that I
mentioned earlier will not occur.

>    We should specify what it means to be ConEx-aware, which 
> will constrain the operation of a "ConEx-aware" node, but not 
> fully specify other actions it may take.

Georgios: Yes that is true! What I actually mean is: Shoud the Conex WG
specify how the Sender, Receiver and Audit devices should process the ECN
marked packets and the Conex exposure signals? Should the Conex WG, for
example, also specify that if a router processes Conex exposure signals,
then in case of congestion these packets should be treated differently than
other packets?

Best regards,
Georgios

---

From: John Leslie <[email-masked]>
Date: Thu, 24 Mar 2011 12:05:30 -0400

Georgios Karagiannis <[email-masked]> wrote:
> [John Leslie wrote:]
>>> Must the sender (of the data path and Conex exposure signals) be able 
> But if the sender is not be able to identify which packets were
> lost in the downstream direction, then the calculation of the
> congestion rate will be inaccurate.

   There is a possible minor inaccuracy if the sender guesses wrong
on the _size_ of a dropped packet. We do not consider that important.

> Note that the congestion rate is the sum of the rate of packets
> that are lost and the packets that were ECN marked in the downsstream
> direction.

   No.

   Well, not the arithmetic sum, anyway -- we could play word games
and call it a "combinatorial sum". The point is, a packet can only
be dropped once, and an ECN mark is equivalent to a drop.

>>> and realizes that this packet is lost, should this sender include
>>> the same Congestion exposure signal in a retransmitted packet?
>> 
>> Generally not.
>> 
> I think that the answer of this question is more complex than your
> answer! In my opinion we need to do evaluation studies to find out
> what is the impact of retransmitting or not retransmitting lost
> Congestion exposure signals.

   Feel free to do those yourself, as part of the experiment evaluation.
We are designing according to an assumption that packet drops should
be rare, and that exacting accuracy is less important as congestion
rate grows large.

> Yes, the reason is a congestion. In a congestion situation a router
> might drop packets. Most routers implement the simple FIFS/FIFO Tail
> drop queing mechanism.

   I'm not sure that's true any longer -- in any case, we can't assume
it to be true, except for routers that essentially never drop anyway.

> This means that ECN marked packets may be dropped by congested routers.

   That is true. Most routers (today) aren't ECN-aware.

> This will mean that the receiver might not receive ECN marked packets
> when one or more routers in the downstream path from sender to receiver
> are congested.

   But the packets, being dropped, count towards congestion anyway.

> This will aslo mean that the Sender will not be able to know that the
> lost packet was ECN marked.

   That does not follow -- though it's unlikely the Sender would care...

> If the queuing mechanims in the router is such that ECN marked packets
> are not dropped in congestion situations then the problem that I
> mentioned earlier will not occur and the receiver and Sender will be
> notified about the ECN marked packet.

   Which is a happy thing...

   But not particularly critical to ConEx operation -- it only helps
to react more quickly to congestion.

> The reason is again a congestion. In a congestion situation a router
> might drop packets. Most routers implement the simple FIFS/FIFO Tail
> drop queing mechanism.

   Again, a poor assumption.

> This means that Conex exposure marked packets may be dropped by
> congested routers.

   Again, true.

> This will mean that Audit devices and the receiver might not receive
> Conex exposure marked packets when one or more routers in the path
> from sender to receiver are congested.

   That is certainly possible. (It might help if you specified what
particular ConEx marking you're worried about.)

> This will also mean that the Audit devices and the receiver will not
> be able to calculate in an accurate way the rate of the Conex exposure
> signals apassing by.

   IMHO you're worried about an unimportant corner case. Any ConEx or
ECN marking may get dropped anywhere along the remaining path. I expect
we will specify something like ECN marking for congestion experienced
and a ConEx congestion-expected marking for "building credit" They will
be orthogonal bits but in the same packet. If that packet is dropped
the effects will cancel each other.

   Only if these two marks are in different packets and the two marks
have a different probability of being dropped would we have a significant
imbalance.

> If the queuing mechanims in the router is such that Conex exposure
> marked packets are not dropped in congestion situations then the
> problem that I mentioned earlier will not occur.

   You seem to be assuming a rather full deployment where all routers
that might drop packets are ConEx enabled. That is actually out-of-scope
per our charter.

> Georgios: Yes that is true! What I actually mean is: Shoud the Conex
> WG specify how the Sender, Receiver and Audit devices should process
> the ECN marked packets and the Conex exposure signals?

   I would much prefer not to.

   A number of WGs make the mistake (IMHO) of specifying algorithms
rather than meanings. Inevitably the actual implementations of these
algorithms diverge, and the divergence can't be fully tested by
interoperability testing. Sooner or later, a mess appears, and there's
no good way to clean it up.

> Should the Conex WG, for example, also specify that if a router
> processes Conex exposure signals, then in case of congestion these
> packets should be treated differently than other packets?

   We might want to specify a lower drop probability, but only to
encourage faster reaction to congestion. I'd be happy without any such
MUST in the spec.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 24 Mar 2011 17:51:37 +0100

Hi John

Thanks for the answers. However, I think that we will need to discuss these
issues in 
more detail during the Conex WG meeting in Prague!

Best regards,
Georgios

> Sent: donderdag 24 maart 2011 17:06
> To: Georgios Karagiannis
> Cc: [email-masked]
> >>> Must the sender (of the data path and Conex exposure signals) be 
> >>> able to identify which packets were lost in the downstream 
> >>> direction, in addition to the calculated number of ECN marked 
> >>> packets in the downstream direction?
> >> 
> >> No.
> >> 
> > But if the sender is not be able to identify which packets 
> were lost 
> > in the downstream direction, then the calculation of the congestion 
> > rate will be inaccurate.
> 
>    There is a possible minor inaccuracy if the sender guesses 
> wrong on the _size_ of a dropped packet. We do not consider 
> that important.
> 
> > Note that the congestion rate is the sum of the rate of 
> packets that 
> > are lost and the packets that were ECN marked in the downsstream 
> > direction.
> 
>    No.
> 
>    Well, not the arithmetic sum, anyway -- we could play word 
> games and call it a "combinatorial sum". The point is, a 
> packet can only be dropped once, and an ECN mark is 
> equivalent to a drop.
> 
> >> There is an assumption that ConEx will operate in an environment 
> >> where the same packet can't be dropped twice. ;^)
> >> 
> at one node 
> >> a retransmitted packet in hopes of exposing the right 
> >> expected-congestion to yet a third node really doesn't make sense.
> >> 
> We are designing according to an assumption that packet drops 
> should be rare, and that exacting accuracy is less important 
> as congestion rate grows large.
> 
> >> preference to dropping a ConEx-marked packet. I'd answer 
> that there 
> >> is a reason, though I don't think we have consensus to 
> recommend it 
> >> yet:
> sooner (just 
>    I'm not sure that's true any longer -- in any case, we 
> can't assume it to be true, except for routers that 
> essentially never drop anyway.
> 
> > when one or more routers in the downstream path from sender to 
> > receiver are congested.
> 
>    But not particularly critical to ConEx operation -- it 
> only helps to react more quickly to congestion.
> 
> ConEx-marked 
>    That is certainly possible. (It might help if you 
> specified what particular ConEx marking you're worried about.)
> 
>    IMHO you're worried about an unimportant corner case. Any 
> ConEx or ECN marking may get dropped anywhere along the 
> remaining path. I expect we will specify something like ECN 
> marking for congestion experienced and a ConEx 
> congestion-expected marking for "building credit" They will 
> be orthogonal bits but in the same packet. If that packet is 
> dropped the effects will cancel each other.
> 
>    Only if these two marks are in different packets and the 
> two marks have a different probability of being dropped would 
> we have a significant imbalance.
> 
>    You seem to be assuming a rather full deployment where all 
> routers that might drop packets are ConEx enabled. That is 
> actually out-of-scope per our charter.
> 
> >>> Observation 5:
> >> We should specify what it means to be ConEx-aware, which will 
> >> constrain the operation of a "ConEx-aware" node, but not fully 
> >> specify other actions it may take.
> > 
>    A number of WGs make the mistake (IMHO) of specifying 
> algorithms rather than meanings. Inevitably the actual 
> implementations of these algorithms diverge, and the 
> divergence can't be fully tested by interoperability testing. 
> Sooner or later, a mess appears, and there's no good way to 
> clean it up.
> 
>    We might want to specify a lower drop probability, but 
> only to encourage faster reaction to congestion. I'd be happy 
> without any such MUST in the spec.
> 
> --