Subject: Re: [re-ECN] Conex draft charter

From: Adrian Farrel <[email-masked]>
Date: Mon, 01 Feb 2010 14:32:41 +0000

Hi Lars,

All sounds in order. Looking forward to seeing revised text.

A
----- Original Message ----- 
From: "Lars Eggert" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Magnus Westerlund" <[email-masked]>; <[email-masked]>
Sent: Monday, February 01, 2010 1:27 PM
Subject: Re: Conex draft charter

Hi,

if possible, I'd like to CC all such issues to the CONEX list (still 
[email-masked]). Haven't done so here because I'm not sure if you're OK 
with that. If you are, just add the CC on your reply.

On 2010-2-1, at 15:17, Adrian Farrel wrote:
> I am having trouble parsing some of the text in the Conex draft charter.
> This doesn't mean that I don't think the WG should be formed, just that I
> can't parse the text :-)
>
> I see...
>
>  The purpose of the CONEX working group is to develop a mechanism
>  to allow senders to inform the network of the level of congestion
>  they expect their packets to encounter end-to-end. This information
>  is currently only visible at the transport layer in the end systems.
>  With the CONEX mechanism, it will be possible to provide sufficient
>  information in each IP datagram so that any node along the network
>  path can see the expected rest-of-path congestion.
>
> The sender will have no understanding or expectation of the congestion 
> that
> will be encountered unless the sender has some observational or reported
> information about congestion already seen. If this is the case, then the 
> WG
> needs closer links to congestion observation and reporting mechanisms than 
> I
> can currently see in the charter.

Good catch, this is unclearly as worded for folks who haven't followed the 
discussion closely. The intent is that the sender continuously piggybacks 
path congestion information it learned *during the previous roundtrip* when 
sending new packets.

The charter should definitely say something about what the assumptions about 
that process are & how the two are linked.

> But maybe "encounter" is intended to meld with "cause" because the next
> paragraph says...
>
>  Once any node can see the impact it causes (and suffers) by sending
>  or forwarding packets, it will be possible to hold senders and whole
>  networks accountable for the congestion they cause downstream. The
>  CONEX mechanism could be used for mitigating distributed denial of
>  service (DDoS) attacks; simplifying differentiation of quality of
>  service (QoS); policing compliance to congestion control; and so
>  on.
>
> It certainly does not seem to me that an objective of a sender stating the
> amount of congestion it expects to see can be directly linked to a node
> understanding the impact within the network it causes by sending a packet.
>
> Lighten my darkness, I beseech you.

Like above, I believe that there is a leap here in the argumentation that 
needs to be fleshed out.

Lars

---

From: <[email-masked]>
Date: Tue, 2 Feb 2010 18:56:13 -0000

Adrian
Thanks for the comments, here's my take on them.

Draft charter is at
http://www.ietf.org/mail-archive/web/re-ecn/current/msg00497.html 

> that process are & how the two are linked.

[phil] yes. This was supposed to be captured by the sentence "This
information is currently only visible at the transport layer in the end
systems." ie feedback of tcp (say) means the sender has a view of the
end-to-end congestion.

I think the charter needs some text adding - how about adding to the
sentence so it reads:
"This information is currently only visible at the transport layer in
the end systems; the CONEX mechanism builds on transport layer
feedback."

Does this work?

Adrian said: 
> > But maybe "encounter" is intended to meld with "cause" because the 
> > next paragraph says...
> >
> > service (QoS); policing compliance to congestion control; 
> and so  on.
> >
> > It certainly does not seem to me that an objective of a 
> sender stating 
> > the amount of congestion it expects to see can be directly 
> linked to a 
> > node understanding the impact within the network it causes 
> by sending 
> > a packet.
> >

[phil]
If there is congestion on a link, then:
- you say that you suffer congestion caused by my pkts
- I say that I suffer congestion caused by your pkts

Ie suffering and causing congestion are 2 sides of the same coin.
The amount of traffic that suffers congestion equals the amount causing
congestion. Where 'cause' means the fraction of the total congestion on
the path that's attributable to you. 
[of course an individual pkt either suffers congestion (it gets marked
or dropped) or causes congestion (another pkt gets marked or dropped).
Over several pkts this averages out so that the amounts suffered and
caused are equal - assuming there's no bizarre correlation leading to
all pkts from one source getting marked.] 

Is it enough to add, in the middle of the first para:
Note that the amount of congestion a sender sees is equal to the amount
it causes by sending packets.

I must admit I find this hard to explain without just using a different
form of words to say "they're equal" - so would appreciate someone else
suggesting a better way of putting it!

Best wishes
phil

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 02 Feb 2010 19:29:50 +0000

Hi Phil,

Thanks for the time.

>>> The sender will have no understanding or expectation of the
>>> congestion that will be encountered unless the sender has some
>>> observational or reported information about congestion already
>>> seen. If this is the case, then the WG needs closer links to
>>> congestion observation and reporting mechanisms than I
>> Good catch, this is unclearly as worded for folks who haven't
>> followed the discussion closely. The intent is that the sender
>> continuously piggybacks path congestion information it learned
>> *during the previous roundtrip* when sending new packets.
>>
>> The charter should definitely say something about what the
>> assumptions about that process are & how the two are linked.
>
> yes. This was supposed to be captured by the sentence "This

Yeah, that helps.
If you have some specific transport layer feedback in mind, then it would be 
great to call it out.

>>>  Once any node can see the impact it causes (and suffers)
>>>  by sending or forwarding packets, it will be possible to hold
>>>  senders and whole networks accountable for the congestion
>>>  they cause downstream. The CONEX mechanism could be
>>>  used for mitigating distributed denial of service (DDoS)
>>>  attacks; simplifying differentiation of quality of service (QoS);
>>>  policing compliance to congestion control; and so on.
>>>
>>> sender stating the amount of congestion it expects to see
>>> can be directly linked to a node understanding the impact
>>> within the network it causes by sending a packet.
>
> The amount of traffic that suffers congestion equals the amount
> causing congestion. Where 'cause' means the fraction of the total
> congestion on the path that's attributable to you.
>

Well, I can sort of buy your description within some definitions of 
fairness.

But my problem remains that the purpose of Conex seems to be to allow a 
sender to signal the congestion it expects to see. Yet here you are saying 
that the ability for a node to know how much congestion it is causing is 
important. And in the first part of your answer you say that the knowledge 
of the congestion comes from the transport layer.

Soooo, it seems to me that the paragraph I highlighted may be a truism, but 
has nothing to do with the Conex working group.

Cheers,
Adrian

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 03 Feb 2010 13:09:51 +0000

Adrian,

This is the strategic game as I see it:

* If the transport uses a protocol that doesn't have sufficient 
feedback, it can still use ConEx but it will have to state expected 
congestion conservatively (otherwise the source risks triggering 
mechanisms that detect cheating). Then, because the source tells the 
network an overstated expected congestion level, the network might 
rate-police more than it would otherwise need to...

* Alternatively, the transport doesn't have to identify its packets 
as ConEx-enabled. But networks will want to encourage sources to give 
them ConEx congestion info, so I guess they might one-day rate-limit 
non-ConEx packets.

This all creates the incentives to ensure:
i) future protocol designs *do* provide adequate feedback to the source and
ii) the source tells the network using ConEx.
And it ensures the risk of doing neither falls only on those not 
giving adequate feedback, while leaving all the good citizens alone.

But it still allows legacy protocols to work even if they have no 
feedback at all (e.g. Digital Fountain with tornado code FEC). Such 
protocols were designed for cases where providing a back-channel is 
complex (e.g. satellite). They would either have to risk being rate 
limited for not using ConEx, or they could be updated to use ConEx 
but still without a feedback channel (so they would have to state a 
conservative level of expected congestion).

[I know you were satisfied with Phil's response, but I thought the 
above reasoning might be of interest to the wider list too.]

Cheers

Bob

At 19:29 02/02/2010, Adrian Farrel wrote:
>If you have some specific transport layer feedback in mind, then it 
>would be great to call it out.
>
>>Adrian said:
>Well, I can sort of buy your description within some definitions of fairness.
>
>But my problem remains that the purpose of Conex seems to be to 
>allow a sender to signal the congestion it expects to see. Yet here 
>you are saying that the ability for a node to know how much 
>congestion it is causing is important. And in the first part of your 
>answer you say that the knowledge of the congestion comes from the 
>transport layer.
>
>Soooo, it seems to me that the paragraph I highlighted may be a 
>truism, but has nothing to do with the Conex working group.
>
>Cheers,
>Adrian
>_______________________________________________
>re-ECN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design