Subject: [conex] Review of draft-ietf-conex-abstract-mech-06

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 4 Jun 2013 16:12:25 +0200

Hi,

sorry for the very late review. The draft reads actually very well. I only 
have some high level comments:

1) The very long title of Figure 1 was kind of confusing me.

2) Section 'Overview' is very long (for an overview). Don't know if per-flow 
state, byte vs. packet and partial deployment needs to be discussed here. 
Maybe think about a subsection on discussion points instead (which could also 
include some discussion on attacks against the audit). On the other hand 
potentially introduce briefly the credit concept here.

3) Maybe define the term 'congestion signal' in section 2.1

4) I'm not sure that section 4.6 is at the right postion as it seems to me 
more related to requirements on the encoding.

5) Maybe address briefly how to handle ConEx-not-Marked and not ConEx-capable 
packets (not only for partial deployment but also in regular operation). They 
need to be limited somehow as well, otherwise a sender can easily cheat by 
sending ConEx-not-Marked. And this has to be done by the policer (and not the 
audit though).

8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss 
estimation.

9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of 
credits is well enough specified here. My personal option is that credits 
should somehow get invalid (at some point in time). This is left open in the 
current text.

10) In section 6 it is stated that 'Networks MUST NOT change ConEx marked 
packets to not_ConEx. [...]'. Maybe move this to the requirement section, 
otherwise it might be easily overread. 

11) Security Considerations lists a number of attacks. Shouldn't this document 
also give hints how to handle these attacks? Especially for the 'Dragging 
Down a Spoofed Flow ID', I can't really come up with a good solution...?

Mirja

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 4 Jun 2013 20:12:38 +0100

Mirja,

Tx for this. Matt & I were recently discussing 
how to get this one moving, given we hadn't 
really had many specific criticisms, so this is very useful - thanks.

I'll respond with my personal reactions, and 
leave my co-author, Matt, to come back on anything.

>1) The very long title of Figure 1 was kind of confusing me.

OK, we need a caption like "The flow of ConEx 
signals in the context of the pre-existing flows 
of congestion signals over an end-to-end connection"

Then fold the 3-sentence post-amble under the 
Figure into the body text, where it refers to the Figure.

>potentially introduce briefly the credit concept here.

Flow-state:
I'd be happy to move most of the first half of 
the para into an introductory paragraph under 
S.5.4. "Policy Devices" about flow-state. That 
would leave just a high level sentence about the 
trade-off in the introduction, with a pointer to S.5.4. Something like:

"  One of the design goals of the ConEx protocol is that the important
    policy mechanisms can be implemented for heavily aggregated traffic in the
    core of the Internet per logical link without 
per flow state (see Section 5.4).
    However, the price to pay for avoiding flow state for policy is flow state
    to audit ConEx signals, which is discussed further in Section 5.5.  In
    summary: i) flow state for auditing does not require route pinning;
    ii) auditing at the edges, with limited per flow state, enables
    policy elsewhere, including in the core, without any per flow state.
"

>3) Maybe define the term 'congestion signal' in section 2.1

Would the following change to the start of the 2nd para be enough:

OLD
    Networks indicate congestion by three possible signals: packet loss,
    ECN marking or queueing delay.
NEW
    Networks indicate congestion by three 
possible congestion signals: packet loss,
    ECN marking or queueing delay.

>more related to requirements on the encoding.

We already have the two requirements sentences 
from Section 4.6 as items D & E in Section 3.3.

Would it fix your concern if, instead of just 
stating these two requirements, we make the 
SHOULDs lower case and refer back to the actual SHOULD requirements earlier:

OLD
    Therefore a ConEx encoding SHOULD explicity specify whether it
    assumes units of bytes or packets for both congestion indications and
    ConEx markings.

    [I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications
    SHOULD be interpreted in units of bytes when responding to
    congestion, at least on today's Internet.  In any TCP implementation
    this is simple to achieve for varying size packets, given TCP SACK
    tracks losses in bytes.  If an encoding is specified in units of
    bytes, the encoding SHOULD also specify which headers to include in
    the size of a packet.
NEW
    This is why a ConEx encoding should explicity specify whether it
    assumes units of bytes or packets for both congestion indications and
    ConEx markings (see requirement D in Section 3.3.).

    [I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications
    SHOULD be interpreted in units of bytes when responding to
    congestion, at least on today's Internet.  In any TCP implementation
    this is simple to achieve for varying size packets, given TCP SACK
    tracks losses in bytes.  If an encoding is specified in units of
    bytes, the encoding should also specify which headers to include in
    the size of a packet (requirement E in Section 3.3).

>sending ConEx-not-Marked. And this has to be done by the policer (and not the

I think you mean solely Not-ConEx.
(ConEx-Not-Marked means Conex-enabled but not 
marked - this highlights that we haven't defined 
that word well; Section 4.5. defines it with the 
same meaning as before, but it hasn't been defined before.).

There is a para about this in S.6, starting "A 
network operator can create incentives for 
senders to voluntarily reveal ConEx information. ..."

Nonetheless, that in a bullet about senders, so I 
would be happy to write something more specific 
in the section on policy devices, which is where 
this is more relevant. Also, a very simple 
sentence under audit, saying it ignores Not-ConEx.

>8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss

Perhaps this would be solved by moving Generic 
loss auditing before the more specific loss 
auditing bullets, because it basically says 
generic isn't possible. Then ending generic loss 
auditing with a linking sentence saying 
"Nonetheless, loss auditing is possible in the following specific scenarios."

In hindsight, we now have another way of doing 
generic loss auditing, which I'd like to add. A 
network can tunnel traffic and turn on ECN in the 
outer, just for the length of the tunnel. Then, 
by RFC6040, the tunnel egress will drop any 
ECN-marked packets with an the inner showing that 
the e2e transport is Not-ECN-capable.

So, an auditor at the tunnel egress will see all 
the congestion signals from within the network as 
ECN, then the tunnel egress will transform ECN 
into drop for those transports that don't support ECN.

>should somehow get invalid (at some point in time). This is left open in the

I think we need to agree before we can talk about writing down what we agree...

Rather than thinking of Credit expiring after a 
time, one can think of the combination of recent 
Re-Echo signals and earlier Credit signals 
keeping the Credit state fresh within a flow. As 
long as you've sent Credit before a round of 
congestion, then if you send Re-Echo after the 
Auditor can switch it round as if you sent the 
Re-Echo before and the Credit after.

So, when the Auditor holds Credit, it allows up 
to that amount of Re-Echo to be considered as 
having been sent before the congestion, rather 
than after. Then, as it switches the Re-Echoes 
back in time, it switches the Credits forward, so they always stay recent.

Credit is primarily a mechanism to ensure the 
sender has to suffer some cost before it is 
trusted to pay back some cost. Credit doesn't 
need to degrade over time if the cost to the 
sender of introducing credit doesn't degrade over time.

Does this move us forward, or do you still 
disagree? If so, I suggest a new thread would be useful.

>otherwise it might be easily overread.

Yes. Thanks. And the same goes for collecting any 
the other later normative language into the requirements section.

>Down a Spoofed Flow ID', I can't really come up with a good solution...?

You're right that this is the hardest known 
attack to defend against. The draft currently 
refers to my thesis for two solutions. See Section 7.5.3 of
<http://bobbriscoe.net/projects/refb/#refb-dis>
It also includes an analysis of how difficult 
this attack is for a blind attacker. The attack 
only works while it sends numerous packets over a 
5-tuple that matches a target flow. It only has 
to scan the most fruiful parts of the 5-tuple 
space, but it can't detect when it has hit a 
match, so it has to send large numbers of packets 
over each 5-tuple just in case. BTW, the attack 
is trivial for a man-in-the-middle, but he can drop everything anyway.

I have promised to transcribe that material into 
the RFC series eventually, but it's not a 
priority before we get experimental use of ConEx. 
I believe it's OK at this stage as long as the 
solutions are documented /somewhere/ and referred to.

Is that acceptable?

Thanks v much for this full review. We needed this.

Bob

>Mirja

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Matt Mathis <[email-masked]>
Date: Wed, 5 Jun 2013 23:02:06 -0700

Follow up to Mirja's and Bob's comments, inline.   most are "Looks Good to
Me".

On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe <[email-masked]> wrote:

> OK, we need a caption like "The flow of ConEx signals in the context of
> the pre-existing flows of congestion signals over an end-to-end connection"
>
> Then fold the 3-sentence post-amble under the Figure into the body text,
> where it refers to the Figure.
>
This is supposed to be a caption (not a title), but yes the RFC formatting
is confusing.   I would suggest something even simpler "The flow of
congestion and ConEx signals."  and move the rest into the running text.

> I'd be happy to move most of the first half of the para into an
> introductory paragraph under S.5.4. "Policy Devices" about flow-state. That
> would leave just a high level sentence about the trade-off in the
> introduction, with a pointer to S.5.4. Something like:
>
>    core of the Internet per logical link without per flow state (see
> Section 5.4).

I would make the 2nd part even simpler  "A suitable auditing design enables
policy elsewhere, including the core, without any per flow state".

>    Networks indicate congestion by three possible congestion signals:
> packet loss,

LGTM

> We already have the two requirements sentences from Section 4.6 as items D
> & E in Section 3.3.
>
> Would it fix your concern if, instead of just stating these two
> requirements, we make the SHOULDs lower case and refer back to the actual
> SHOULD requirements earlier:
>
> OLD
>    [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion indications
>    [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion indications

LGTM

> (ConEx-Not-Marked means Conex-enabled but not marked - this highlights
> that we haven't defined that word well; Section 4.5. defines it with the
> There is a para about this in S.6, starting "A network operator can create
> incentives for senders to voluntarily reveal ConEx information. ..."
>
> Nonetheless, that in a bullet about senders, so I would be happy to write
> something more specific in the section on policy devices, which is where
> this is more relevant. Also, a very simple sentence under audit, saying it
> ignores Not-ConEx.
>

 I want to think about this one more: propose something more specific.

> estimation.
Today essentially all encryption is above TCP, because IPsec does not play
nice with NATs, and I can't see that changing.    Furthermore there is
already quite a menagerie of FW class devices that refuse non-TCP and TCP
with nonsensical sequence numbers (to thwart various injection attacks).
 We already encrypt nearly all of our payload, except some services and
some countries.

It feels like this is important from pedantic completeness standpoint but
not much of an issue in the real world.

Let me think about this before you reorganize the section.

Perhaps this would be solved by moving Generic loss auditing before the
> more specific loss auditing bullets, because it basically says generic
> isn't possible. Then ending generic loss auditing with a linking sentence
> saying "Nonetheless, loss auditing is possible in the following specific
> scenarios."
>
> In hindsight, we now have another way of doing generic loss auditing,
> which I'd like to add. A network can tunnel traffic and turn on ECN in the
> outer, just for the length of the tunnel. Then, by RFC6040, the tunnel
> egress will drop any ECN-marked packets with an the inner showing that the
> e2e transport is Not-ECN-capable.
>
> So, an auditor at the tunnel egress will see all the congestion signals
> from within the network as ECN, then the tunnel egress will transform ECN

This isn't really audit is it?  What happens if a transport says it can do
ECN, but just ignores it?

> I think we need to agree before we can talk about writing down what we

I think that abstract-mech needs to embrace *both*, explicitly if not
implicitly.  I need to think about this some more, but I suspect that it
means we have unnecessarily over constrained audit here.

> Rather than thinking of Credit expiring after a time, one can think of the
> combination of recent Re-Echo signals and earlier Credit signals keeping
> the Credit state fresh within a flow. As long as you've sent Credit before
> a round of congestion, then if you send Re-Echo after the Auditor can
> switch it round as if you sent the Re-Echo before and the Credit after.
>
> So, when the Auditor holds Credit, it allows up to that amount of Re-Echo
> to be considered as having been sent before the congestion, rather than
> after. Then, as it switches the Re-Echoes back in time, it switches the
> Credits forward, so they always stay recent.
>
> Credit is primarily a mechanism to ensure the sender has to suffer some
> cost before it is trusted to pay back some cost. Credit doesn't need to
> degrade over time if the cost to the sender of introducing credit doesn't
> degrade over time.
>
> Does this move us forward, or do you still disagree? If so, I suggest a
> new thread would be useful.
>

This is probably correct, but I really don't think it belongs in A-M.

> Yes. Thanks. And the same goes for collecting any the other later
> normative language into the requirements section.
>

Yep, I agreee

> You're right that this is the hardest known attack to defend against. The
> draft currently refers to my thesis for two solutions. See Section 7.5.3 of
> <http://bobbriscoe.net/**projects/refb/#refb-dis<http://bobbriscoe.net/projects/refb/#refb-dis>
> >
> It also includes an analysis of how difficult this attack is for a blind
> attacker. The attack only works while it sends numerous packets over a
> 5-tuple that matches a target flow. It only has to scan the most fruiful
> parts of the 5-tuple space, but it can't detect when it has hit a match, so
> it has to send large numbers of packets over each 5-tuple just in case.
> BTW, the attack is trivial for a man-in-the-middle, but he can drop
> everything anyway.
>
> I have promised to transcribe that material into the RFC series
> eventually, but it's not a priority before we get experimental use of
> ConEx. I believe it's OK at this stage as long as the solutions are
> documented /somewhere/ and referred to.
>
> Is that acceptable?
>

LGTM

> Thanks v much for this full review. We needed this.

Except for the couple of items for more thought, dig in!

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 7 Jun 2013 00:57:26 +0100

Matt,

A few rejoinders inline...

At 07:02 06/06/2013, Matt Mathis wrote:
>Follow up to Mirja's and Bob's comments, 
>inline.   most are "Looks Good to Me".
>
>
>On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:

[snip]

>    core of the Internet per logical link 
> without per flow state (see Section 5.4).
>I would make the 2nd part even simpler  "A 
>suitable auditing design enables policy 
>elsewhere, including the core, without any per flow state".

[BB]: Not sure where you intend 'the 2nd part' to 
start. I'd like some residual hint left in the 
Intro that we don't need route pinning. How about:

"  One of the design goals of the ConEx protocol is that the important
    policy mechanisms can be implemented for heavily aggregated traffic in the
    core of the Internet per logical link without 
per flow state (see Section 5.4).
    However, the price to pay for avoiding flow state for policy is flow state
    to audit ConEx signals, which is discussed further in Section 5.5.  In
    summary, a suitable edge-based auditing 
design using soft per-flow state enables
    policy elsewhere, including the core, without any per flow state.
"

Also, I forgot to address Mirja's request to move 
most of the byte-pkt text from the Intro into the 
body. I pushed for that before, so I'll leave you 
to argue if you don't agree. While, if you do 
agree, you can suggest what to leave, and what to move.

>Nonetheless, that in a bullet about senders, so 
>I would be happy to write something more 
>specific in the section on policy devices, which 
>is where this is more relevant. Also, a very 
>simple sentence under audit, saying it ignores Not-ConEx.
>
>
>Today essentially all encryption is above TCP, 
>because IPsec does not play nice with NATs, and 
>I can't see that changing.    Furthermore there 
>is already quite a menagerie of FW class devices 
>that refuse non-TCP and TCP with nonsensical 
>sequence numbers (to thwart various injection 
>attacks).  We already encrypt nearly all of our 
>payload, except some services and some countries.
>
>It feels like this is important from pedantic 
>completeness standpoint but not much of an issue in the real world.

[BB]: Mirja's point was we don't say what can (or 
cannot) be done with encrypted TCP. I don't think 
she's looking for an evasive answer like "There 
probably isn't much encrypted TCP". I don't 
believe we should base protocol design on 
predictions of the future traffic mix. We should 
make the admission clear that we can't do 
anything with encrypted TCP (and similarly multipath is tough).

>network can tunnel traffic and turn on ECN in 
>the outer, just for the length of the tunnel. 
>Then, by RFC6040, the tunnel egress will drop 
>any ECN-marked packets with an the inner showing 
>that the e2e transport is Not-ECN-capable.
>
>the congestion signals from within the network 
>as ECN, then the tunnel egress will transform 
>ECN into drop for those transports that don't support ECN.
>
>
>This isn't really audit is it?  What happens if 
>a transport says it can do ECN, but just ignores it?

[BB]: Audit checks whether the transport receiver 
and/or sender expose the congestion they see 
(then policy devices can rely on this exposed 
info to police anyone ignoring congestion - if that's the policy).

The tunnel turns on ECN support in the outer to 
ensure any congestion at intermediate nodes can 
all be exposed to the auditor as ECN marks not 
losses. It works for all packets (even DNS), 
whatever the e2e transport says about ECN support (in the inner).

Nonetheless, for those transports that say they 
don't support ECN, the tunnel egress converts all 
congestion signals into drops (after the auditor 
has read the ECN signals). This 'just works' if 
the tunnel complies with RFC6040.

>I think that abstract-mech needs to embrace 
>*both*, explicitly if not implicitly.  I need to 
>think about this some more, but I suspect that 
>it means we have unnecessarily over constrained audit here.

[BB]: We need to allow multiple experiments at 
this experimental stage. But ultimately, sources 
will need to unambiuously know what Credit means, 
so they know how much to introduce and when.

>congestion, then if you send Re-Echo afterwards 
>the Auditor can switch it round as if you sent 
>the Re-Echo before and the Credit after.
>

[BB]: I don't think it should either. This is a 
discussion with Mirja, rather than a proposal for text.

>Except for the couple of items for more thought, dig in!

Looking forward to the rest.

CHeers

Bob

>Privacy matters!  We know from recent events 
>that people are using our services to speak in 
>defiance of unjust governments.   We treat 
>privacy and security as matters of life and 
>death, because for some users, they are.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sun, 9 Jun 2013 16:34:19 +0200

Hi Bob, hi Matt,

see inline....

On Friday 07 June 2013 01:57:26 Bob Briscoe wrote:
> >2) Section 'Overview' is very long (for an overview). Don't know if
> > per-flow state, byte vs. packet and partial deployment needs to be
> > discussed here. Maybe think about a subsection on discussion points
> > instead (which could also include some discussion on attacks against the
> > audit). On the other hand potentially introduce briefly the credit
> > concept here.
> >
> >
> >Flow-state:
> >    policy mechanisms can be implemented for heavily aggregated traffic in
> > the core of the Internet per logical link
> >    However, the price to pay for avoiding flow state for policy is flow
> > state to audit ConEx signals, which is discussed further in Section 5.5. 
> > In summary: i) flow state for auditing does not require route pinning;
> > ii) auditing at the edges, with limited per flow state, enables policy
> > elsewhere, including in the core, without any per flow state.
> >
> >"
> >
> >
>     policy mechanisms can be implemented for heavily aggregated traffic in
> the core of the Internet per logical link without
>     However, the price to pay for avoiding flow state for policy is flow
> state to audit ConEx signals, which is discussed further in Section 5.5. 
> In summary, a suitable edge-based auditing

Fine with me!

> agree, you can suggest what to leave, and what to move.

Maybe we can have the same approach here. Just leave one sentence saying that 
it is defined in this to count congestion byte-wise and give a reference for 
a later section for the reasoning.

> >packets (not only for partial deployment but also in regular operation).
> > They need to be limited somehow as well, otherwise a sender can easily
> > cheat by sending ConEx-not-Marked. And this has to be done by the policer
> > (and not the audit though).
> >
> >

No, I meant also ConEx-Not-Marked because even when you support ConEx you 
could still send all your packets with ConEx-Not-Marked and the policer and 
the audit will not do anything...

> >  I want to think about this one more: propose something more specific.

Okay.

> >
> >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for
> > loss estimation.
> >
> >

Eventhough encrypted TCP is not very common today, if this is the most simple 
way to cheat ConEx, more ConEx deployment could incentivize to send more 
encrypted packet. Thus there has to be a way to handle this. Maybe we can say 
something like: "If the TCP header information is encrypted and loss-based 
Conex signaling is used, a policer should threat this traffic like not 
ConEx-capable as auditing is not possible." 

> >"Nonetheless, loss auditing is possible in the following specific

I believe reordering would also help.

> >ECN into drop for those transports that don't support ECN.
That's a good idea. I would support to put this in the draft.

> >a transport says it can do ECN, but just ignores it?

It gets more and more ECN markings and will sooner or later get policing 
drops. That exactly the case were we need ConEx!

> >should somehow get invalid (at some point in time). This is left open in
> > the current text.
> >
> >

I'll send a new main on crediting...

-- 
-------------------------------------------------------------------
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: Mirja Kuehlewind <[email-masked]>
Date: Sun, 9 Jun 2013 16:47:07 +0200

Hi Bob , hi Matt,

quickly addressing those points which were not present anymore in the other 
mail.... see below...

> congestion and ConEx signals."  and move the rest into the running text.

Yes, i would prefer something very short here as well, as the image is well 
explained in the text. (Actually the text just above the image basically says 
the same that the current caption)

[snip]

> >    ECN marking or queueing delay.

I was think about add this definition to 2.1. Terminology like this:

Congestion Signal: packet loss or a packet holding the Congestion Experienced 
(CE) ECN marking

I would like to see this to make once again clear, that we only look at loss 
and ECN when we talk about congestion in ConEx. 

> > We already have the two requirements sentences from Section 4.6 as items
> > D & E in Section 3.3.
> >
> >    [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion
> > indications SHOULD be interpreted in units of bytes when responding to
> >    [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion
> > indications SHOULD be interpreted in units of bytes when responding to

Okay.

[snip]

> >> the
> > Rather than thinking of Credit expiring after a time, one can think of
> > the combination of recent Re-Echo signals and earlier Credit signals
> > keeping the Credit state fresh within a flow. As long as you've sent
> > Credit before a round of congestion, then if you send Re-Echo after the
> > Auditor can switch it round as if you sent the Re-Echo before and the
> > Credit after.
> >

Where does it belong?

> >> packets to not_ConEx. [...]'. Maybe move this to the requirement
> >> section, otherwise it might be easily overread.
> >

Okay.

>
> >  11) Security Considerations lists a number of attacks. Shouldn't this
> >
> >> document
> >> also give hints how to handle these attacks? Especially for the
> >> 'Dragging Down a Spoofed Flow ID', I can't really come up with a good
> >> solution...?
> >
> > parts of the 5-tuple space, but it can't detect when it has hit a match,
> > so it has to send large numbers of packets over each 5-tuple just in
> > case. BTW, the attack is trivial for a man-in-the-middle, but he can drop
> > everything anyway.

I would prefer a little extra text in this document just like the explanation 
above.

tel: +49(0)711/685-67973

---

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 9 Jun 2013 17:03:33 +0200

Hi,

> so they know how much to introduce and when.

Yes, but we need to propose a mechanism when to send credits for the TCP mod 
draft and this means we need to have a common understanding how to handle 
credits in the endsystem and the audit. I guess that's what standards are 
good for. We might need a separate document for this. Not sure we are able to 
agree on this right now. As an alternative, I could also add some text in the 
TCP mod draft that the crediting is an open issue for experiments...?

> >the Re-Echo before and the Credit after.

I don't think this would change anything. Maybe make it even worse. As you 
could also just send credit instead of ConEx marks and moreover there is 
still no incentive to send further marks when you have build up a large 
number of credits during Slow Start.

> >disagree? If so, I suggest a new thread would be useful.

I have two concerns:
1) As mentioned above if a sender has sent a large number of credits during 
Slow Start and causes only few congestion during the rest of the transmission 
(as today's TCP usually does), there is no incentive to send further ConEx 
marks at all (neither credits nor loss/ECN ConEx marks).
2) When sufficient markings has been sent during Slow Start, no further 
credits should be needed. But if the audit for any reason will loose state 
(e.g. because of memory restriction or a new audit is used due to rerouting), 
the sender will still not send new credits as will and thus will cause the 
audit penalize the flow eventhough the sender did do nothing wrong.

> >This is probably correct, but I really don't think it belongs in A-M.

We might need an own document but there might also be some additional 
requirements that should be added to this document.

---

From: David Wagner <[email-masked]>
Date: Mon, 10 Jun 2013 19:44:38 +0200

Hi, 

I think there are some strong arguments for "aging" credits: 
1) they avoid problems with restarted audits / rerouting: if credits are valid for e.g. 1 hour, any newly started auditer should not indicate reliable information for that time. 
This can be extended to running auditers seeing new (rerouted?) IP addresses, but of course there is a trade-off for coverage. 
2) the value for credit is likely to degrade over time for the sender, typically already sent credits will count less than credits to be sent now. 
This applies for rate-based credit / ConEx allowance mechanisms since, if using non-vanishing credits, the starting phase is much more costly than maintaining a flow. In other words: non-vanishing credit is an incentive to keep connections open. Do we want that?

Anyway, I don't yet have a good credit concept. 
Which also needs to address handling loss of ConEx-marked packets, at the sender and at the audit. 

David 

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

-- 
Dipl.-Inf. David Wagner
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart
Pfaffenwaldring 47, D-70569 Stuttgart, Germany

web: www.ikr.uni-stuttgart.de   email: [email-masked]
phone: +49 711 685-67965        fax: +49 711 685-57965
-------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 13 Jun 2013 17:19:20 +0100

Mirja,

Sorry this thread got split up. I haven't 
responded to any of you points in the other part, 
because I would just be repeating what I said - 
I'd like to hear Matt's responses instead.

Responses to this part inline...

[snip]

>the audit will not do anything...

[BB]: ConEx-Not-Marked are ConEx enabled, they 
just say "there is no re-echo". So if, there is 
congestion but the source only sends 
ConEx-Not-Marked, it is suppressing re-feedback 
of the congestion, and the audit function will squash the flow.

This is the whole point of the audit function. So 
perhaps I am misunderstanding your point?

>[Mirja]: Okay.

[BB]: Matt, no time to write text at the mo 
(about to take a week off, so I'm having to do 
the week's extra work beforehand). I planned to do this when we add the edits.

>ConEx-capable as auditing is not possible."

[BB]: Superficially, that seems a good sentence. 
But it wouldn't apply in the cases described 
where audit can be done against losses. So I would append:

..."unless the operator knows it is using one of 
the techniques described in Section xxx to audit against losses".

>I believe reordering would also help.

[BB]: Matt, have you pondered?

Regards

Bob

---

From: Matt Mathis <[email-masked]>
Date: Thu, 13 Jun 2013 17:48:15 -0700

I am buried again - I can't do this justice, nor is it fair for me to hold
it up.  You may proceeded.

Please do the reordering last (or at least late) and capture a copy of the
.xml for me just before the reordering so I can easily see the independent
changes without the confusion that chaff that the reordering will introduce.

If something makes me too uncomfortable, I will have to argue the changes
after the fact.

Thanks,
--MM--

On Thu, Jun 13, 2013 at 9:19 AM, Bob Briscoe <[email-masked]> wrote:

> Mirja,
>
> Sorry this thread got split up. I haven't responded to any of you points
> in the other part, because I would just be repeating what I said - I'd like
> to hear Matt's responses instead.
>
>> > ><<mailto:[email-masked]>[email-masked] <[email-masked]>>
>> wrote:
> [BB]: ConEx-Not-Marked are ConEx enabled, they just say "there is no
> re-echo". So if, there is congestion but the source only sends
> ConEx-Not-Marked, it is suppressing re-feedback of the congestion, and the
> audit function will squash the flow.
>
> This is the whole point of the audit function. So perhaps I am
> misunderstanding your point?
>
>  > >
> [BB]: Matt, no time to write text at the mo (about to take a week off, so
> I'm having to do the week's extra work beforehand). I planned to do this
> when we add the edits.
>
>
>
>  > >
> [BB]: Superficially, that seems a good sentence. But it wouldn't apply in
> the cases described where audit can be done against losses. So I would
> append:
>
> ..."unless the operator knows it is using one of the techniques described
> in Section xxx to audit against losses".
>
>
>
>  >
>> > ______________________________**______________________________**____
>> > Bob Briscoe,                                                  BT
>>
>>
>>
>> --
>> ------------------------------**------------------------------**-------
>> email: [email-masked]**stuttgart.de<[email-masked]>
>> ------------------------------**------------------------------**-------
>>
>
> ______________________________**______________________________**____
> Bob Briscoe,                                                  BT
>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 14 Jun 2013 22:36:53 +0100

Matt,

I won't be doing the edits for a week at least. We can wait for your thoughts.

Bob

At 01:48 14/06/2013, Matt Mathis wrote:
>I am buried again - I can't do this justice, nor 
>is it fair for me to hold it up.  You may proceeded.
>
>Please do the reordering last (or at least late) 
>and capture a copy of the .xml for me just 
>before the reordering so I can easily see the 
>independent changes without the confusion that 
>chaff that the reordering will introduce.
>
>If something makes me too uncomfortable, I will 
>have to argue the changes after the fact.
>
>Thanks,
>--MM--
>On Thu, Jun 13, 2013 at 9:19 AM, Bob Briscoe 
>responded to any of you points in the other 
>part, because I would just be repeating what I 
>said - I'd like to hear Matt's responses instead.
>
> > ><<mailto:[email-masked]><mailto:bob.brisc 
> [email-masked]>[email-masked]> wrote:
>This is the whole point of the audit function. 
>So perhaps I am misunderstanding your point?
>
> > >
>tel: <tel:%2B49%280%29711%2F685-67973>+49(0)711/685-67973
>email: 
><mailto:[email-masked]>[email-masked]
>web: <http://www.ikr.uni-stuttgart.de>www.ikr.uni-stuttgart.de

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 16 Jun 2013 07:34:35 +0100

Mirja,

>TCP mod draft that the crediting is an open issue for experiments...?

I would rather we supported diversity by stating 
one concrete definition, and allowed experiments 
with other definitions. But I would (naturally) 
prefer my definition (ie credit lasts for as long 
as a flow is active, and an auditor MAY time out 
a flow after no less than 1 second of inactivity).

Actually, I think this is the only concrete 
definition on the table, unless you have a 
proposal for exactly how to define your idea of credit gradually expiring.

>could also just send credit instead of ConEx marks

That's not such a big problem, although I admit 
it devalues the distinction between Credit & 
Re-Echo, and I admit too that I don't have a solution to that.

>and moreover there is

My proposed definition of credit means that the sender wouldn't need to.

It's not ideal from a network monitoring point of 
view for the network to see such an anomalous 
amount of credit and nothing to be able to 
monitor recent actual congestion. But at least it 
still provides full incentives against cheating.

And, much more importantly, it also provides 
incentives to slow-start more carefully (e.g. 
watching the ACK timing to detect onset of 
overshoot a round trip earlier), so that so much 
credit isn't wasted. The Linux patch to do this 
was too gentle, but the developers gave up 
because at the time there was no way to reason 
about how much less gentle it should be - ConEx provides that.

>marks at all (neither credits nor loss/ECN ConEx marks).

See above.

>audit penalize the flow eventhough the sender did do nothing wrong.

Audit would only lose state due to a re-route.* 
Then, admittedly it would lose a load of credit, 
but if the sender's flow was in progress, it 
wouldn't need a huge repeat of credit again. Just 
one, or perhaps two, ConEx re-echoes in response 
to the ensuing audit losses would be sufficient to re-instate the audit state.

* = (If audit has mem restrictions it would not 
have set the state in the first place.)

>requirements that should be added to this document.

Going back on what I say below, I think it would 
be better to state one full definition of credit 
in abstr mech, just to be concrete, but then say 
that if anyone prefers another definition, they 
are encouraged to experiment with it and write up the outcome.

> > discussion with Mirja, rather than a proposal for text.

Tx again for you review.

Bob

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 26 Jun 2013 13:37:29 +0200

Hi Bob,

another definition could be:

A credits gets invalid/is used when a new congestion signal (CE or loss) 
arrives at the audit and the number of congestion-marked or lost packets 
(red) is currently larger than ConEx-marked ones (black/purple).

This would mean you potentially have to resend credits when congestion occurs.

Mirja

On Sunday 16 June 2013 08:34:35 Bob Briscoe wrote:
> > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning
> > > > of credits is well enough specified here. My personal option is that
> > > > credits should somehow get invalid (at some point in time). This is
> > > > left open in the current text.
> > > >
> > > >
> >Yes, but we need to propose a mechanism when to send credits for the TCP
> > mod draft and this means we need to have a common understanding how to
> > handle credits in the endsystem and the audit. I guess that's what
> > standards are good for. We might need a separate document for this. Not
> > sure we are able to agree on this right now. As an alternative, I could
> > also add some text in the TCP mod draft that the crediting is an open
> > issue for experiments...?
>
> >1) As mentioned above if a sender has sent a large number of credits
> > during Slow Start and causes only few congestion during the rest of the
> > transmission (as today's TCP usually does), there is no incentive to send
> > further ConEx marks at all (neither credits nor loss/ECN ConEx marks).
>
> See above.
>
> >(e.g. because of memory restriction or a new audit is used due to
> > rerouting), the sender will still not send new credits as will and thus
> > will cause the audit penalize the flow eventhough the sender did do
> > nothing wrong.
>

tel: +49(0)711/685-67973