Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06

From: Arno Bakker <[email-masked]>
Date: Wed, 1 May 2013 15:58:15 +0200

Hi Martin

thanks for the in-depth review. The authors will go over them in detail, 
but two remarks need to be made now. Please see inline.

On 30/04/2013 11:18, Martin Stiemerling wrote:
>
> Please find here the review of your Area Director for
> draft-ietf-ppsp-peer-protocol-06. This includes all sections except 12
> and 13.
>

The draft cannot be fully understood without reading Section 13 about 
the Security Considerations. This will resolve some of the points you 
made (channel IDs, PEX_REScert). We welcome recommendations on items 
from that section that should be moved forward in the document. Of 
course, we will look at them ourselves.

> ***High-level issues:
> 1) Merkle Hash Trees
> I have found the document very confusing on whether Merkle Hash Trees
> (MHTs) and the for the MHT required bin numbering scheme are now
> optional or mandatory. Parts of the draft make the impression that
> either of them or both or optional (mainly in the beginning of the
> document), while Section 5 and later Sections are relying heavily on MHTs.
>

MHTs are mandatory to implement for static content. I.e., all 
implementations should at least support this mechanism. It is not 
required to be used for all swarms. This is to ensure there is at least 
one secure configuration of the protocol that all implementations speak 
(an IETF goal AFAIK). So mandatory to implement, optional to use. We'll 
make sure this is clearer.

> My naive reading of the current draft is that you could rely on
> start-end ranges for chunk addressing and MHTs for content protection.
> However, I do know that this combination is not working.
>

Section 5, last paragraph clearly states: "The Merkle hash tree scheme 
can use different chunk addressing schemes.  All it requires is the 
ability to address a range of chunks." Hence, MHTs work with all 
numbering schemes defined in the spec.

What makes you think it doesn't work with start-end ranges? The 
compliant implementation is working fine with this scheme.

Regards,
       Arno

---

From: Arno Bakker <[email-masked]>
Date: Wed, 8 May 2013 11:49:17 +0200

Hi Martin

we agreed with the document sheperd, Stefano, that we would request 
clarification of issues directly from you, instead of via him.
So can you please clarify your comments, as indicated below?
Once all issues are clarified we will address each of them
in a subsequent mail.

 > However, I do know that this combination is not working.

Can you clarify why this combination does not work in your view?

 > If MHTs are really optional, including the bin numbering, the document
 > should really state this and make clear what the operations of the
 > protocol are with the mandatory to implement (MTI) mechanisms. The
 > MHT, bins, and all the protocol handling should go in an appendix.

Questions from our side:

* Given MHTs are intended to be mandatory-to-implement, is the current
presentation in the main body of the text OK?

* Given start-end ranges of chunks are intended to be 
mandatory-to-implement,  do you want other optional chunk addressing 
schemes, such as bins, to be moved to appendices?

* Do you have a reference to the syntax for specifying MTI. Or is that 
just the phrase "mandatory to implement" and MUST clauses?

 > 3) No formal protocol message definition
 > Section 7 and more specific Section 8 describe the protocol syntax of
 > the protocol options and the messages, though Section 8 is talking
 > about UDP encapsulation.
 > Section 7 is hard to digest if someone should implement the options,
 > see also later, but Section 8 is almost impossible to understand by
 > somebody who has not been involved in the PPSP working group. See
 > also further down for a more detailed review of the sections.

Do you mean the draft should have a ABNF specification of the protocol?

 > 4) Implicit use of default values
 > There are a number of places all over the draft where default values
 > are defined. Many of those default values are used when there are no
 > values explicitly signaled, e.g., the default chunk size of 1 Kbyte
 > in Section 8.4 or Section Section 7.5. with the default for the
 > Content Integrity Protection Method.
 > I have the feeling that the protocol and the surroundings (e.g., what
 > comes in via the 'tracker') are over-optimized, e.g., always providing
 > the Content Integrity Protection Method as part of the Protocol
 > options will not waste more than 2 bytes in a HANDSHAKE message.
 > Further, I do not see the need to define a default chunk size in the
 > base protocol specification, as this default can look very different,
 > depending on who is deploying the protocol and in what context. This
 > calls for a more dynamic way of handling the system chunk size, either
 > as part of an external mechanisms (e.g. via the tracker) or in the
 > HANDSHAKE message.
 >

RFC5706 "Guidelines for [...] Operations and Management" calls for
"a sensible default value for all parameters." Do you want us:

i) to rephrase the 1K default chunk size as sensible default (so a 
suggestion instead of a standard-setting value)

ii) just explain considerations for choosing this value, without an
explicit default?

 > 5) Concept of channels
 > The concept of channels is good but it is introduced too late in the
 > draft, namely in Section 8.3, and it is introduced with very few
 > words. Why isn't this introduced as part of Section 2 or Section 3,
 > also in the relationship to the used transport protocol?

In our design channels only exist in the UDP encapsulation to allow 
several swarms to use the same UDP port. As Sec. 2 and 3 discuss the 
protocol at an abstract level it is (/should) not mentioned there. Do 
you propose to:

i) have the concept of channels in all encapsulations, as the reason for
reusing ports exists for e.g. TCP as well?

ii) explain parts of the UDP encapsulation in Sec. 2 and 3 already?

 > I.e., the intention is to keep only one transport 'connection' between
 > two distinct peers and to allow to run multiple swarm instances at the
 > same time over the same transport.
 > And how do swarms and channels correlate?
 >

Is this last line is a question from you, or something that should be
addressed better in the draft? The answer is there is a single channel
for each swarm. So if two peers A and B want to exchange chunks in
multiple swarms Si (i=1...N) in parallel, there are N channels between A
and B.

 > ***Technicals:
 > - Section 2.1, 2nd paragraph, about the tracker:
 > I haven't seen a single place where the interaction with a tracker is
 > discussed or where the tracker less operation is discussed in
 > contrast. It is further unclear what type of information is really
 > required from a tracker.
 > A tracker (or a resource directory) would need to provide more then IP
 > address & port, e.g., the used transport protocol for the protocol
 > exchange (given that other transports are allowed), used chunk size,
 > chunk addressing scheme, etc
 >

The WG charter has always had a usage guide planned for describing
these scenarios. Do you suggest describing them here? If so,
at an abstract level detailing which information is minimally required,
or very concretely referencing the tracker protocol spec? Note the 
latter may complicate standardization progress as the tracker protocol 
spec is not as far along as the peer protocol.

 > - Section 3.7, 2nd paragraph
 >    - all 'MAY' are actually not right here. Please remove or replace
 > them with lower letters if appropriate.

Are there more exact guidelines on the use of these words than RFC2119?
We have used them to describe required and optional protocol behaviour,
both in terms of what data fields are required and what the
request/response behaviour to messages is. Using these words for
optional behaviour is incorrect? In this specific paragraph, how
should we indicate that replying to REQUESTs is optional?

 > - Section 3.10.2
 > This whole section about PEX hole punching reads very, very
 > experimental. The STUN method is ok, but PEX isn't.
 > First of all, the safe behavior for a peer when it receives
 > unsolicited PEX messages, is to discard those messages. Second, this
 > unsolicited PEX messages trigger some behavior which may open an
 > attack vector.
 > The best way, but this needs more discussion, is to include to some
 > token in the messages that are exchanged in order to make avoid any
 > blind attacks here. However, this will need more and detailed
 > discussions of the purpose of this.
 >

The attack issues are discussed in Sec. 13.2. Does that section 
sufficiently cover possible attack scenarios, and/or should parts of 
that discussion be moved here?

 > - Section 3.11
 > I don't see the 'MUST send keep-alive' as a mandatory requirement, as
 > peers might have good reasons not to send any keep alive. Why not
 > saying 'A peer can send a keep-alive' and it 'MUST use the simple
 > datagram...' as already described. Though there is also no really
 > need to say MUST.
 >

Can you give an example of why peers would not want to send keep-alives,
given that peer-liveliness detection (Sec. 8.14) depends on them?

 > - Section 4
 > The syntax definition for each of the chunk addressing schemes is
 > missing. This is not suitable for any specification that aims at
 > interoperable implementations.
 >

So an ABNF specification should be added?

 > ***Editorials:
 >
 > - Section 2.1: What is the PPSP Url?
 >

We envisioned this to be defined in a usage guide. Do you want this to
be defined here? Or an example?

 > - Section 8.1
 > 1 kibibyte is 1 kbyte?

We assumed the IETF would follow ISO/IEC 80000-13 standard to avoid the
kilo = 1000 or 1024 confusion. Are we wrong?

 > - Section 8.14
 > There is no single place where all the constants are collected and
 > also documented what the default values or the recommended values.

Do you want a separate section with all the defaults listed?

 > - Section 11
 > This section needs to be overhauled once the document is ready for the
 > IESG. The section is not wrong but can be improved to help IANA.
 >

Can you say how can it be improved so we can do that now?

Regards,
      Arno and Riccardo

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 09 May 2013 21:28:28 -0400

On 4/30/2013 5:18 AM, Martin Stiemerling wrote:
> 2) LEDBAT as congestion control vs. PPSPP
> The PPSP peer protocol is intended for the Standards Track and relies in
> a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an
> **experimental** delay-based congestion control algorithm.
> A Standards Track protocol cannot normatively rely on an Experimental
> congestion control mechanism (or RFC in general).
> There are ways out of this situation:
> i) Do not use ledbat: this would call for another congestion control
> mechanism to be described in the PPSPP draft.
> ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track:
> Possible, but a very long way.
> iii) Agree on having PPSPP also as Experimental protocol.
> 
> I'm currently leaning towards option iii), but this is my pure personal
> opinion as an individual in the IETF.

Another option would be to mark it as a DOWNREF during the
IETF Last Call, right?  That assumes the WG can make the
case for why this is okay as a DOWNREF (e.g. wide deployment
experience, and lack of cataclysms).

Maybe someone can comment on whether alternatives like TFRC
were investigated or not?  TFRC is Standards Track, and intended
for providing a smoother rate like we talked about in the
past (LEDBAT may not be good for relatively rate-inelastic
flows), but I don't know if the feedback it requires would be
compatible with what the PPSPP framing provides or not.

I also would not think it wise to change to something else
that doesn't match the implemented and deployed base, unless
the people implementing and deploying agree that something
else is clearly better and will be implemented and deployed
by them.

-- 
Wes Eddy
MTI Systems

---

From: Riccardo Petrocco <[email-masked]>
Date: Fri, 10 May 2013 10:16:24 +0200

Dear Wesley and All,

> compatible with what the PPSPP framing provides or not.

We are currently looking into alternatives to LEDBAT for the PPSPP.
The majority of CCs will require some small modifications to the content
of the DATA and ACK messages as defined in the draft.

> else is clearly better and will be implemented and deployed

We will also run some large experiments in a controlled environment to
evaluate the effect and feasibility of the different solutions.

Regards,
    Riccardo and Arno

>
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 10 May 2013 13:17:43 -0400

> of the DATA and ACK messages as defined in the draft.

That is good to hear.  I don't know if it's helpful or not, but
one example of how to implement TFRC in a non-DCCP UDP-based
protocol is:
http://tools.ietf.org/html/draft-eddy-tsvwg-saratoga-tfrc-03
I don't think it necessarily has to be as painful as some have
found in the past.

> evaluate the effect and feasibility of the different solutions.

Excellent!

-- 
Wes Eddy
MTI Systems