Subject: [ppsp] Review of draft-grishchenko-ppsp-swift-03.txt

From: Martin Stiemerling <[email-masked]>
Date: Thu, 1 Dec 2011 13:35:42 +0000

[speaking as individual contributor and not as chair of the PPSP WG]

Hi there, 

Here is my review of draft-grishchenko-ppsp-swift-03 in the light of selecting a peer protocol proposal as basis for the PPSP peer protocol:

- Good: flexibility to use different congestion control mechanisms
  BUT what does this mean in the protocol. Isn't more different transport protocols in general?
- Good: clear definition of the messages.
- Missing: timers for time outs, e.g., when is a peer considered to be dead? After x seconds or after x messages not acknowledged?
- Bad: Section 3 "Messages" is saying that no error codes are defined. This is typically a bad design choice. I could at least see the need for some error codes, such as "syntax error", "I'm not in that swarm", etc. 
- the bits on the wire presentation is not necessarily required in a draft, if it is clear what type endian ordering and syntax is used. 
- remove Section 6.3 "RTP Profile for PPSP".
- Section 8.3 is too weak, as the peers would need to use the same congestion control mechnaism between two communicating peers. This could be negotiated in the setup phase/capability exchange.

Questions:
- Does the HANDSHAKE message create state in the responding peer? This will need a 3-way handshake to make it secure. 
- Which transport to chose. UDP and TCP are in, though TCP may be optional. However, we need to work on the congestion control.
- Is there an explicit keep-alive message? I wasn't sure after reading the document
- Do we need a BYE message to allow a graceful disconnection between two peers? 
- Update interval of the HAVE message? Or does each retrieved chunk result in sending a HAVE message?
- Why is it allowed to have multiple HINT messages in a single datagram?
- Why is the PEX_ADD message not called PEX_RES which would make the relationship to PEX_REQ much clearer and easier to understand.
- The whole punching mechanisms needs to be explained a bit better, especially in the light of STUN and ICE.

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Arno Bakker <[email-masked]>
Date: Tue, 6 Dec 2011 09:31:56 +0100

>    BUT what does this mean in the protocol. Isn't more different transport protocols in general?

Hi

I'm not sure what you mean. Different congestion control mechanisms are 
only possible over UDP, but I know you know that.

> - remove Section 6.3 "RTP Profile for PPSP".

RTP still is a feasible option, IMHO, which I'd like to keep in mind in 
case the higher-ups in IETF don't like raw UDP or TCP. But I guess you 
definitely want to remove the HTTP encapsulation section?

> - Does the HANDSHAKE message create state in the responding peer? This will need a 3-way handshake to make it secure.

Yes. E.g. a channel ID will be allocated. I don't directly see the 3-way 
requirement, if the initiating peer doesn't send a new packet soon the 
state can be garbage collected.

> - Which transport to chose. UDP and TCP are in, though TCP may be optional. However, we need to work on the congestion control.

We prefer UDP for flexibility, with perhaps TCP for very limited hardware.

> - Is there an explicit keep-alive message? I wasn't sure after reading the document

Not a present. In the UDP encapsulation a datagram consisting just of a 
channel ID is used as keep-alive.

> - Do we need a BYE message to allow a graceful disconnection between two peers?

The UDP encapsulation defines an explicit close as a HANDSHAKE with an 
all 0 channel ID. Popular operating systems return ICMP unreachable when 
sending to a peer that is no longer there, enabling garbage collection.

> - Update interval of the HAVE message? Or does each retrieved chunk result in sending a HAVE message?

That is our proposed model of operation, although Csaba wants to allow 
different models (mail dd. Nov 30). I await his well-founded 
modification proposal.

> - Why is it allowed to have multiple HINT messages in a single datagram?

E.g. to request multiple rare chunks at the same time, instead of whole 
subtrees.

> - Why is the PEX_ADD message not called PEX_RES which would make the relationship to PEX_REQ much clearer and easier to understand.

Renaming is fine with me.

I hope this answers your questions. Other rewriting remarks I'll take 
into account when updating the draft.

CU,
     Arno

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 06 Dec 2011 14:48:13 -0500

On 12/6/2011 3:31 AM, Arno Bakker wrote:
>> ...

My interpretation of Martin's comment (which I may be wrong about) is
that if the protocol is flexible to use different congestion control
algorithms, those algorithms may have different requirements which would
have to be supported by both ends.  That might require signalling or
negotiating the algorithm to be used.  For instance, some algorithms may
require more feedback than others, or may require specific lost packet
numbers versus loss rates over a period, as an example.

> definitely want to remove the HTTP encapsulation section?

In my opinion, RTP should only be used if it really makes sense and we
are using some features of it that it would not be sane to reinvent.
The decision should be based on technical merit rather than policy.

In my opinion, the HTTP option doesn't make technical sense given the
rest of the assumptions about how PPSP functions.

I believe "raw UDP" is a good approach, though we should definitely not
call it that, since we intend to do LEDBAT or other acceptable
control mechanisms on top of it, and "raw" leaves a bad initial
impression in that respect.  I think I would say that we're using a
"congestion-controlled UDP-based transport".

>> Questions:
>> - Does the HANDSHAKE message create state in the responding peer? This
>> will need a 3-way handshake to make it secure.
> 

I think the issue is that if you need a mechanism to cope with the
potential for someone to send you a whole lot of HANDSHAKEs that
they have no intention of turning into useful flows.  If there's a
limit to the amount of state that can be kept, then it may be
exhausted for some time waiting for the state to expire, and new
legitimate flows get drowned out or can't be started.

There are probably several ways to deal with this; extension of the
handshake is one approach.

>> - Which transport to chose. UDP and TCP are in, though TCP may be
>> optional. However, we need to work on the congestion control.
> 

You may prefer UDP for very limited hardware as well.  I think for this
application, it is all-around better.

> sending to a peer that is no longer there, enabling garbage collection.

Hopefully we will not rely on ICMP, though we can certainly use it as
one signal that the peer is gone.

-- 
Wes Eddy
MTI Systems

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 8 Dec 2011 22:09:09 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Wesley Eddy
> Sent: Tuesday, December 06, 2011 8:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ppsp] Review of draft-grishchenko-ppsp-swift-03.txt
> 

The interpretation is correct.

> "congestion-controlled UDP-based transport".

+1

> handshake is one approach.

I brought up this issue, as I know about another IETF protocol which uses UDP for a first hand-shake (RFC 5971, http://tools.ietf.org/html/rfc5971, GIST: General Internet Signalling Transport). In GIST the issue of a single UDP packet creating state on the responder to this packet raised a lot of questions, such as the creation of state without verifying that there is an actual real sender of this packet, to how many initial packets per time unit you respond, etc. 

> one signal that the peer is gone.

+1, as ICMP datagrams will not always make it to the receiving host, as there firewalls, NATs and other highwayman suppressing icmp datagrams. 
  
Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 9 Dec 2011 08:06:47 +0000

Hi Arno,

I'm replying to the remaining parts which have not been addressed by email in my email just before this email:

> Arno Bakker
> Sent: Tuesday, December 06, 2011 9:32 AM
> To: [email-masked]

[...]

> different models (mail dd. Nov 30). I await his well-founded

Ok.

> E.g. to request multiple rare chunks at the same time, instead of whole

Ok, now I see!

> 
> 
> > - Why is the PEX_ADD message not called PEX_RES which would make the
> relationship to PEX_REQ much clearer and easier to understand.
> 

Yes, the questions are answered. 

Thanks,

  Martin