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

[Mirja Kuehlewind <[e-mail]>]

Hi Bob , hi Matt,

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


On Thursday 06 June 2013 08:02:06 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 <[e-mail]> wrote:
> > At 15:12 04/06/2013, Mirja Kühlewind wrote:
> >> 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.
>
> 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.

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]


> >  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.
>
> LGTM

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. 

>
> >  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.
> >
> > 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).
>
> LGTM

Okay.

[snip]

>
> 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.
> >
> > I think we need to agree before we can talk about writing down what we
> > agree...
>
> 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.

Where does it belong?

>
> >  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.
> >
> > Yes. Thanks. And the same goes for collecting any the other later
> > normative language into the requirements section.
>
> Yep, I agreee

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...?
> >
> > 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/pr
> >ojects/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 would prefer a little extra text in this document just like the explanation 
above.

> >
> > 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.



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

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------