I think we can use the aggregator to reduce false positives. If an agent
experiences blockage or throttling while connecting to a super peer based on
a service protocol, it can then try to repeat the test with the aggregator.
If the results of both the super peer and aggregator tests match then the
result should be reported, otherwise it will marked as a false positive.
Alan, Diogo, Luis, any thoughts?
On Tue, Jun 14, 2011 at 5:23 PM, Adriano Monteiro Marques <
[email protected]> wrote:
>
> On Jun 14, 2011, at 5:33 AM, Zubair Nabi wrote:
>
> > I completely agree.
> >
> > For the ICM we're interested in two types of service differentiation: 1)
> > Blockage, 2) Throttling.
> > Instead of measurement at the server end, in our case the measurement
> would
> > be at the client but we still need a server like entity with which the
> agent
> > can establish a TCP connection and start 2 flows. These 2 flows would be
> > identical to the ones described in the paper. But this would be our
> > measurement metric:
> > 1) Blockage
> > If Flow 1 fails but Flow 2 goes through then Flow 1 (which represents a
> > service) is being blocked.
> > 2) Throttling
> > If the throughput (or goodput) of Flow 2 is greater than Flow 1, then
> Flow 1
> > is being throttled.
> >
> > These server like entities in case of the ICM can be one of the 3 options
> > that I described earlier, i.e. 1) The super peers, 2) Server code hosted
> on
> > M-Lab like platforms, 3) Existing Glasnost servers.
> > To have maximum control over the entire set-up, using the super peer as a
> > server would be our best option. Mind you, as a server the super peer
> > wouldn't have to do anything special like measurement or anything; The
> > server would just respond to the agents TCP packets based on the
> protocol.
> > Nothing more.
>
> It must be the super peers, then. Otherwise, it would be too easy for ISPs
> to block them. We can also have the aggregator to do some part of the deal.
>
> >
> > To achieve optimum load balancing, a server should be assigned to an
> agent
> > by the aggregator during the register_peer phase.
> >
> >
> >
> > On Tue, Jun 14, 2011 at 5:09 AM, Adriano Monteiro Marques <
> > [email protected]> wrote:
> >
> >> Hi Zubair,
> >>
> >> Very nice finding!
> >>
> >> I read the paper, and I found it very nice their description of how
> traffic
> >> differentiation can occur. This is something we must know by heart.
> >> Another thing, was the first condition of having a very low barrier for
> >> use. This is pretty much what we want to achieve with ICM too: we don't
> want
> >> any users to need to setup any rules in their routers or firewalls in
> order
> >> to get this system to work. What I didn't like in it, though, was that
> it
> >> relies heavily on measurement servers, and what we really want is to
> have
> >> the measurement to take place in the client without external help. I'm
> not
> >> sure on what you're suggesting at the end when you say that we could use
> >> super peers, m-lab like platforms or existing glasnost servers. Could
> you
> >> explain it further?
> >>
> >> On Jun 13, 2011, at 6:09 PM, Zubair Nabi wrote:
> >>
> >> Hi Everyone,
> >>
> >> According to my timeline, this week I'm supposed to implement the
> services
> >> connectivity sub-module. I've spent the entire day looking into
> different
> >> services and their protocols etc. I also looked into existing mechanisms
> and
> >> came across something interesting and directly relevant to our work.
> It's
> >> called Glasnost. Basically, it has a client/server architecture based on
> >> flows to detect "differentiation" of different kinds of traffic by ISPs.
> >> Differentiation is an umbrella term for blocking, throttling etc. Here's
> the
> >> project website: http://broadband.mpi-sws.org/transparency/glasnost.phpand
> >> here's a link to a research paper about the system:
> >> http://broadband.mpi-sws.org/transparency/results/10_nsdi_glasnost.pdf
> >> The paper is a must read for everyone involved in the ICM project. Other
> >> than the mechanism, it has some very nice design considerations that we
> >> should follow as well.
> >> In a nutshell, if we want to check if BitTorrent is being
> differentiated,
> >> we would start two TCP flows to a server from the user client. One flow
> >> would have BitTorrent headers and content in the payload while the
> second
> >> (sent after an offset interval) would have random bytes in the payload.
> We
> >> would run both flows for X time for the protocol to stabilize. If
> there's a
> >> problem with Flow 1 and not Flow 2 then that would mean that Flow 1 is
> being
> >> differentiated. This can also be used to check if there's any throttling
> of
> >> Flow 1 as compared to Flow 2. One important point that they make is that
> >> port number is not the only parameter that ISPs use to differentiate
> >> services, in fact ISPs also employ techniques based on the content and
> >> protocol behaviour to find out the type of the service. This is
> something
> >> that we should consider as well.
> >>
> >> So, this is what I propose. We should use the same mechanism for our
> >> service connectivity tests. But that leads to a architectural question.
> What
> >> would the measurement servers be in our case. Well that's something that
> we
> >> need to decide. I think we have three options for the measurement
> servers:
> >> 1) The super peers, 2) Server code hosted on M-Lab like platforms, 3)
> >> Existing Glasnost servers.
> >>
> >> What do you guys think?
> >>
> >> --
> >> Best,
> >> __
> >> Zubair
> >>
> ------------------------------------------------------------------------------
> >> EditLive Enterprise is the world's most technically advanced content
> >> authoring tool. Experience the power of Track Changes, Inline Image
> >> Editing and ensure content is compliant with Accessibility Checking.
> >>
> >>
> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> >> Umit-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/umit-devel
> >>
> >>
> >> ---
> >> Adriano Monteiro Marques
> >>
> >> http://www.thoughtspad.com
> >> http://www.umitproject.org
> >> http://blog.umitproject.org
> >> http://www.pythonbenelux.org
> >>
> >> "Don't stay in bed, unless you can make money in bed." - George Burns
> >>
> >>
> >
> >
> > --
> > Best,
> > __
> > Zubair
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Umit-gsoc mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/umit-gsoc
>
> ---
> Adriano Monteiro Marques
>
> http://www.thoughtspad.com
> http://www.umitproject.org
> http://blog.umitproject.org
> http://www.pythonbenelux.org
>
> "Don't stay in bed, unless you can make money in bed." - George Burns
>
>
--
Best,
__
Zubair
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
