Subject: [P2PSIP] Comment on p2psip-diagnostics

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Mar 2009 13:22:58 -0800

One comment on the Echo design.... I'm worried about a method where  
sending a single request can cause a whole bunch of responses. This  
has congestion and DOS issues. It is also not clear how all the  
retransmissions timers would work with it.

We should think about if it is possible to move away from the one  
request, multiple responses design.

Cullen <as an individual contributor>

---

From: Song Haibin <[email-masked]>
Date: Tue, 03 Mar 2009 14:26:43 +0800

Dear Cullen,

You have the same concern with Bruce and Henning. The authors do not think
this method is broadly suitable for the diagnostics in the open Internet
environment either. However, it may be used in some administrative p2p
overlays. The usage of Echo method is limited to certain application
scenarios.

As we said in the draft: "An Echo request message is used to retrieve the
diagnostic information of the specified path in administrative p2p overlays
where all the peers in the overlay are trusted or based on specific
authorization.  For example, it can be used in a p2p overlay where all peers
deployed by the operator to provide services to the customers (clients),
where the diagnostics happens between peers in the p2p overlay.  For the
untrusted p2p overlays, e.g. some end user equipments can be the peers in
the overlay network, then the Echo method must be used with care for the
consideration of potential DoS attack.  Compared with Path_Track method,
Echo method brings less messages to the p2p overlay network."

Best Regards,
Haibin
Skype: alexsonghw

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Cullen Jennings
>Sent: Tuesday, March 03, 2009 5:23 AM
>To: P2PSIP WG
>Subject: [P2PSIP] Comment on p2psip-diagnostics
>
>
>_______________________________________________
>P2PSIP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/p2psip

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 16 Mar 2009 16:29:47 -0400

So I wanted to pick back up on this thread since it didn't go too far,
but I think this is a very important area. I think that the diagnostic
mechanisms are something we really need to have, and I have been
re-reading and think that the work in the diagnostic draft is the
right direction, so I wanted to get a bit more discussion going on
this item before the meeting, hoping that we can resolve this and have
a good path for the authors on the diagnostics draft to go forward
with for a new version coming out of San Francisco.

For those of you who aren't familiar, the basic idea is that you want
some mechanism to be able to collect diagnostic information from each
peer that comprises a path through the overlay, in order to be able to
diagnose any problems that may exist in that path/evaluate the
peers/etc., so there is a problem that you really do want information
from each peer along the path.

Cullen's concern here is with the mechanism described in 4 (1) of the
draft: ECHO message being sent out, and getting back a response from
each peer along the path. You have something like this:

a->b->c->d->e

but generate responses at each hop:

b->a
c->a
d->a
e->a

Hence a ddos risk if I send out a bunch of messages randomly and claim
they are all from a...(understanding that other mechanisms in RELOAD
may prevent that of course)

The alternative in 4 (2) is an iterative mechanism:

a->b
b->a (and suggests c)
a->c
c->a (and suggests d)
a->d
d->a (and suggest e)
e->a

In the draft, the suggestion is that 4 (1) may be appropriate in a
managed network. I think that we would want to clarify the definition
of managed network, for example perhaps these type of requests are
only valid when signed by a? This may still be problematic (I can no
longer dos someone else, but I may be able to generate a lot of
unneeded traffic, which still could severely compromise the overlay)
in terms of generating lots of traffic. Perhaps even a stronger
requirement that the signer be an admin of some sort (although now
determining who is an admin and the mechanisms for deciding that a
message is signed by the admin crop up -- this starts to be in BCP
land)

4 (2), using the recursive mechanism eliminates the specific issue I
think Cullen brought up, but of course opens the problems of NAT
traversal.

Another idea that struck me (rather complex timer issues make it
rather ugly) was to have the request go out using standard symmetric
recursive routing, with each peer appending information as it returns.
There is a timer issue here in that if the message fails on some leg,
the last one to send it needs to send back a response anyway. In
otherwords if the path should have been:

a->b->c->d->e->d->c->b->a

but d is dead, you still need that as diagnostic information, and need
something like:

a->b->c->XXX  ...some time passes... c(w/XXX)->b->a

The timers there look ugly (a is likely to time out first, not c, and
if c times out last and sends, how do we prevent this turning into
recursive (i.e., b fails and sends back, then c fails and sends, etc),
and also the messages could be very large for large path lengths (good
thing we are talking about fragmentation now :) )

I don't have a particular solution I think makes sense here, and it
may be that we want to offer each as a mechanism. However, I think
that having something like what is in the diagnostics draft is
essential, but I read Cullen's email and he certainly has some valid
ddos issues with the echo approach. I wanted to share my thoughts and
see if we could get some list discussion here to try to get this one
ironed out...

David (as individual)

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 16 Mar 2009 14:02:36 -0700

>I think that we would want to clarify the definition
>of managed network

I fully agree, since some naïve folks out there (including me) think that:

 1.  p2p is self organizing - not managed - unless fixing node software is called management.
 2.  p2p works across the Internet and crosses many ISP networks,  several times even for any one ISP. The p2p operator may not even be in friendly relations with some the ISPs and compete with them.

Item 2. has prevented me to understand how in the world ALTO may work, but that's another story.

Note: I contributed to some of the diagnostic scenarios, but not anything about management of p2p.

Henry

On 3/16/09 3:29 PM, "David A. Bryan" <[email-masked]> wrote:

I think that we would want to clarify the definition
of managed network

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 16 Mar 2009 17:16:57 -0400

Hi Henry:

I think there are many possible levels of "management" here from
central to none. In the case I was talking about in this email, I'm
think the authors were talking about a system where there is a central
manager and they are using a mechanism (certificates?) to limit who
can join, who can manage etc.. It may even not go outside a particular
provider or enterprise. Obviously many of us (myself included) want to
see some nice open P2P network out there, but I am quite certain there
will be managed uses of this technology as well, and I think we are
better off considering them, and providing mechanisms that are
standardized that recognize they will exist than pretending they
don't, and having non-standard implementations, so I think it makes
sense that the authors are considering that.

Obviously there are many case like what you describe, where the system
will span the internet and have no admin, and I think we need a
diagnostic package that works for those, so it is very important to
find an approach that allows one to diagnose a network just as you
describe -- one that is open, and self organized. That is actually the
harder part of this problem, and the one I want to discuss. We don't
want to take the easy way out and only design for managed either.
Thanks for reminding us!

David

On Mon, Mar 16, 2009 at 5:02 PM, Henry Sinnreich <[email-masked]> wrote:
> p2p is self organizing – not managed – unless fixing node software is called
> management.
> p2p works across the Internet and crosses many ISP networks,  several times
> even for any one ISP. The p2p operator may not even be in friendly relations
> with some the ISPs and compete with them.
>
> Item 2. has prevented me to understand how in the world ALTO may work, but
> that’s another story.
>

---

From: John Buford <[email-masked]>
Date: Wed, 18 Mar 2009 12:01:21 -0400

2009/3/16 Henry Sinnreich [email-masked]

 I fully agree, since some naïve folks out there (including me) think that:
>
>    1. p2p is self organizing – not managed – unless fixing node software
>    is called management.
>    2. p2p works across the Internet and crosses many ISP networks,
>     several times even for any one ISP. The p2p operator may not even be in
>    friendly relations with some the ISPs and compete with them.
>
> Henry,

Current overlays have limitations.  Here's a partial list of problems, I
expect others on this list can add more:

- potentially long delays to respond to and correct from network partitions
- inability to detect and correct load imbalance, such as flash crowd effect
- inability to detect and respond to DDOS attacks
- inability to enforce different classes of service for different peers
- overlay instability at high churn rates, that might be caused by
increases  in the number of mobile peers
- no one knows what happens if the overlay population exceeds some large
number, say 100M, sinces no overlays have been deployed or simulated at that
size - does it degrade gracefully or become inoperable
While there are some research proposals to address some of these problems
individually, it is safe to say that no single design covers all of them.

In general as long as there are overlay algorithm performance areas which can
not be automatically detected and corrected by self-organizing algorithms, then
there is a need for management agent(s) to be able to monitor and intervene.

Sure this boundary is likely to shift over time as algorithms get better.
And monitoring the overlay can help the development of better algorithms.

Here's a detailed discussion of the limits of today's P2P systems w.r.t.
self-organization:

B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of
self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, 1
(March 2007), 34 pp.
Here's a look at how overlay management might work:

J. Buford, Management of peer-to-peer overlays, International J. of Internet
Protocol Technology, Special Issue on Management of IP Networks and
Services, Vol. 3, No.1, 2008, 2–12.

Bottom line, ideally P2P doesn't need to be managed, but depending on user
expectations for service quality and willingness to pay, there could  be
deployments with overlay operators who provide this for users by managing
the overlay.

John

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 18 Mar 2009 12:37:18 -0700

Well, maybe management of overlays works and also maybe it makes economic sense (for who?).
This would have to be proven however not in papers, but in running systems as well in market for acceptance.
Too bad the Skype and Bittorrent folks who have proven both do not care to participate in this debate.
As an engineer, I may be excused for not believing in p2p management, until I see the measurements and numbers.

> no one knows what happens if the overlay population exceeds some large number, say >100M, sinces no overlays have been deployed or simulated at that size - does it degrade >gracefully or become inoperable

My Skype panel shows right now 16,659,464 people on line and I believe they have 400 million subscribers.
Skype works exceedingly well for our daily family a/v sessions, coast to coast.
Does Skype have network management agreements with all the ISPs their p2p is crossing? :-)

>but depending on user expectations for service quality and willingness to pay
This alone is worth a good beer BOF.
Let's plan for one.

Henry

On 3/18/09 11:01 AM, "John Buford" <[email-masked]> wrote:

Henry,

Current overlays have limitations.  Here's a partial list of problems, I expect others on this list can add more:

- potentially long delays to respond to and correct from network partitions
- inability to detect and correct load imbalance, such as flash crowd effect
- inability to detect and respond to DDOS attacks
- inability to enforce different classes of service for different peers
- overlay instability at high churn rates, that might be caused by increases  in the number of mobile peers
- no one knows what happens if the overlay population exceeds some large number, say 100M, sinces no overlays have been deployed or simulated at that size - does it degrade gracefully or become inoperable
While there are some research proposals to address some of these problems individually, it is safe to say that no single design covers all of them.

In general as long as there are overlay algorithm performance areas which can not be automatically detected and corrected by self-organizing algorithms, then there is a need for management agent(s) to be able to monitor and intervene.

Here's a detailed discussion of the limits of today's P2P systems w.r.t. self-organization:
B. Biskupski, J. Dowling, and J. Sacha, Properties and mechanisms of self-organizing MANET and P2P systems, ACM Trans. Auton. Adapt. Syst. 2, 1 (March 2007), 34 pp.

J. Buford, Management of peer-to-peer overlays, International J. of Internet Protocol Technology, Special Issue on Management of IP Networks and Services, Vol. 3, No.1, 2008, 2-12.

Bottom line, ideally P2P doesn't need to be managed, but depending on user expectations for service quality and willingness to pay, there could  be deployments with overlay operators who provide this for users by managing the overlay.

John

---

From: John Buford <[email-masked]>
Date: Wed, 18 Mar 2009 16:16:57 -0400

I am starting a thread on the samrg mailing list entitled
"Can Managed Overlays Prevent 2-Day Outages Such as Skype's in 2007"
to discuss the engineering/econonic issues.  Please join
if you are interested in such a discussion.

Thanks,
John

On Wed, Mar 18, 2009 at 3:51 PM, Brian Rosen <[email-masked]> wrote:

> This sounds like a discussion for which the beer part is an order of
> magnitude more important than the BOF part.
>
> I’m not sure we’re going to get anywhere arguing whether management is a
> good or bad thing.
>
> Can we get back to the discussion about p2psip-diagnostics?
>
> Brian
>
> Henry Sinnreich
> Sent: Wednesday, March 18, 2009 3:37 PM
> To: [email-masked]
> Cc: P2PSIP WG
> Subject: Re: [P2PSIP] Comment on p2psip-diagnostics
>
> > no one knows what happens if the overlay population exceeds some large
> number, say >100M, sinces no overlays have been deployed or simulated at
> that size - does it degrade >gracefully or become inoperable
>
> Does Skype have network management agreements with all the ISPs their p2p
> is
> crossing? :-)
>
> Let’s plan for one.
> 1. p2p is self organizing – not managed – unless fixing node software is
> called management.
> 2. p2p works across the Internet and crosses many ISP networks,  several
>  times even for any one ISP. The p2p operator may not even be in friendly
> relations with some the ISPs and compete with them.
> Henry,
>
> In general as long as there are overlay algorithm performance areas which
> can not be automatically detected and corrected by self-organizing
> algorithms, then there is a need for management agent(s) to be able to
> monitor and intervene.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Mar 2009 15:51:46 -0400

Brian 

Well, maybe management of overlays works and also maybe it makes economic
sense (for who?).
This would have to be proven however not in papers, but in running systems
as well in market for acceptance.
Too bad the Skype and Bittorrent folks who have proven both do not care to
participate in this debate.
As an engineer, I may be excused for not believing in p2p management, until
I see the measurements and numbers.

My Skype panel shows right now 16,659,464 people on line and I believe they
have 400 million subscribers. 
Skype works exceedingly well for our daily family a/v sessions, coast to
coast.
Does Skype have network management agreements with all the ISPs their p2p is
crossing? :-)

Henry

 

 

 

John

---

From: Song Haibin <[email-masked]>
Date: Thu, 19 Mar 2009 11:27:56 +0800

Hi Henry,

I have seen that the management of overlays has been a hot topic for ISPs
and telecom equipment vendors. Some of the thought is to use p2p technology
in the ISP’s network to manage their network equipments. I would like to
invite you to the PPSP bar bof meeting which will be held on Monday 8PM to
10 PM at Continental 3, and there the guys from China Mobile will give a
great introduction to their ongoing DSN network project which utilize the
p2p technology.  It is exactly a good example of management of overlay.
Please refer to this draft: 

http://www.ietf.org/internet-drafts/draft-zhang-ppsp-dsn-introduction-00.txt

Hope this can help to clarify your doubt. 

Dear Henry, the authors are really appreciated to your contribution to the
p2psip diagnostics draft, and we would like to see more comments to the
p2psip diagnostics draft.

Best Regards,
Haibin
Skype: alexsonghw

  _____  

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, March 19, 2009 3:37 AM
To: [email-masked]
Cc: David A. Bryan; Song Haibin; P2PSIP WG
Subject: Re: [P2PSIP] Comment on p2psip-diagnostics

Henry

 

Henry,

- overlay instability at high churn rates, that might be caused by increases
in the number of mobile peers

 

 
 
John