Subject: Re: [ppsp] WG item adoption confirmation

From: Martin Stiemerling <[email-masked]>
Date: Wed, 11 May 2011 09:22:19 +0000

[writing as individual contributor and not as chair]
Hi, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yingjie Gu(yingjie)
> Sent: Monday, April 18, 2011 3:25 AM
> To: 'Xiao, Lin (NSN - CN/Beijing)'; 'ext Ping Pan'
> Cc: [email-masked]
> Subject: Re: [ppsp] WG item adoption confirmation
> 
[...]
> 
> As answer to chairs’ and other experts comments,
> 
> 1)     composing a section to ‘analyze the strengh and drawback of both
> encodings in the protocol draft’, It’s okay to add some analysis text
> in the draft, but since we can not make an accurate calculation on
> bandwidth consuming before we make exact messages definition, I don’t
> think the analysis text will include bandwidth consuming calculation
> comparison between text-based and binary based. Besides, since we
> already have a rough consensus on Text-based encoding, I think we can
> answer the encoding question as “text-based encoding”.  Any objection
> to this? The draft has described a HTTP-based encoding.

HTTP-based encoding seems to be a good choice for the tracker protocol. The analysis could be rather short and just be an explanation why a text/http-based encoding was selected.

> 
> 2)     As for Transport protocol, as Yunfei has said as a chair, this
> has been clarified in Charter.  Personally, I think TCP is okay for
> Tracker protocol, but UDP is better for Peer protocol. This is idea is
> also from some other people I talked with. But currently, the WG has
> not make any decision that Transport protocol choice is in scope of
> Tracker and Peer Protocol, so Tracker protocol authors will follow WG
> Charter for now, unless Transport protocol choice is pushed to PPSP
> protocol design.

The choice seems to be easy, once you go for HTTP. It requires TCP as transport and it relieves you from define congestion control mechanisms for a potential UDP transport. There is also no need to go for UDP, as the tracker protocol operation isn’t time sensitive, as for instance, VoIP would be. 

> 
> 3)     As for NAT Traversal, there is already a good draft to analyzing
> and providing solution to it. Tracker protocol will receive the
> requirements from the NAT draft and make sure Tracker protocol is able
> to support common requirements for various NAT Traversal solution.

HTTP/TCP would suite your needs best here for this purpose. 

> 
> 4)     There is some confusing description, most in introduction
> section, the authors promise to revise it next version.

This would be good and it would be good to have rather soon!

> 
> 5)     The Binary encoding, which is in appendix now, will be removed
> in next version.

good. 

> 
> Are there other major comments I missed?

What about the issues out of the presentation from the last IETF meeting? Please check the minutes. 

> 
> 
> 
> If you have any objection to the above answer, please voice out, so
> that the WG can have a discussion on that.
> 
> If there is no objection, will the Chairs be glad with rough consensus
> on the above comments?

Speaking now as chair: no need to call consensus on the comments above. Please apply them to the draft, so we can call for comments on the text and for adoption as WG item. 

  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: Martin Stiemerling <[email-masked]>
Date: Wed, 11 May 2011 09:32:07 +0000

Hi Bryan,

> David A. Bryan
> Sent: Monday, April 18, 2011 4:26 PM
> To: Yingjie Gu(yingjie)
> Cc: [email-masked]
> So a few comments here. In full disclosure, I'm an author on the
> draft, and so would personally like to see it adopted and think it is
> a good base, but there is obviously some inherent bias on my part...
> 
> My experience in the past has been that until you have a draft of some
> kind (protocol or a design document) in which to document consensus it
> is very hard to drive forward. Some folks don't even read drafts or
> get involved in a group until it has WG items. We have had debate at
> several meetings on some of these issues (HTTP/Binary, offline
> support, etc.) and it has been tough to drive toward consensus, get it
> documented, and move on. Newcomers join and the same issues get hashed
> again and again since there isn't a document to track consensus.
> (Sometimes you are lucky if you can get the comments until last
> call...)

I subscribe to the first point of having the need to document decisions and design in a draft. However, I oppose the second part of having first a WG item before people start reading. I still see the need to have a technical sound document before moving it to a WG item. This is not yet the case for the tracker protocol draft. 

It is indeed a pity that many people only read drafts once they are in WGLC. 

> 
> In P2PSIP, we had several competing (and in function, very similar,
> with one exception) proposals, and the authors spent lots of time
> incorporating each other's tweaks into their drafts. It took years
> (literally) to resolve, finally by merging the drafts. Once that
> happened, the group debated the technical points, and had a clear
> place to document the consensus -- the adopted draft. Other groups
> achieve the same goal using a design draft.

I guess we are fine with the single draft, but we need an update of the draft right now. There is no way of moving forward without having an updated version of the draft rather soon and not just before the meeting. I see this draft on the right track, but the response time to get a new draft out of the door isn't that good at this point of time.

> 
> I prefer we adopt, but if we don't adopt
> draft-gu-ppsp-tracker-protocol as a WG item, then I would at least
> suggest a WG item for a new design draft that does nothing but list
> the big questions, and use that to drive and document WG consensus
> (i.e., discussion, then slides and hums on each question, then confirm
> it on list and wrap up that document), or appoint a design team to go
> make either a design or protocol draft so that we can spend time
> productively. What I'd like to avoid is spending time nailing down
> every detail of multiple proposals when there is no place to clearly
> document the direction the group wants to go in the first place.

We do not need another design draft, but should make some decisions and document them in the tracker protocol. And we need it now :)

> 
> On a few specific issues raised about the draft:
> 
> The binary encoding remains in the draft simply because while the
> authors prefer HTTP, we haven't been able to get a clear WG consensus.
> We would be willing to adjust the draft to reflect the desired
> encoding (and change/modify as the group discussion evolves
> accordingly). We spend more time on the operations -- I feel the
> encoding is much less important than getting the operations right
> (which we would love feedback on -- we may very well have them wrong,
> but there hasn't been much discussion on list about that, despite it
> being the most important question in my opinion)

It is still draft and you do need WG consensus on that draft. However, it is preferable to capture the WGs decision for the encoding. I would say the WG tends towards HTTP. 

> 
> On the offline question, there has been a great deal of discussion in
> the early meetings (I missed Prague, so forgive me if things changed)
> to allow time-shifted, BT style designs as well. We reflected that in
> the draft, but again, it would be good to discuss further. For those
> asking about this, it might be good to go back and listen to the old
> minutes (particularly the BoF). There was very strong consensus in the
> room to support offline as well as real-time. I do agree this is
> perhaps not well reflected in the charter, and again, it would be good
> to document this consensus -- one way or another -- somewhere.

Why not go first with real-time? Isn't it better to get started with near-term issues, such as real-time, and deal with offline afterwards? 

I personally do not see yet the impact on the tracker protocol by this issue, but if there is a bigger issue, one could write a separate draft which deals with that. The outcome of that draft could be integrated in the tracker protocol later on.

> 
> As mentioned, bootstrapping is explicitly out of scope in the charter
> at present.

ACK.

> 
> Security definitely needs more work and Akbar's comment is valid -- we
> need to reorganize the text into one location. We would also love
> comments on list about this topic. The discussion online has been
> pretty quiet.

The discussion is indeed quiet.

However, please update the document in May to get a new basis for the discussions.

Thank you

  Martin