We can't always reproduce the conditions of a given region through the
aggregator...
I guess we should use it to confirm that the site is down, rather than being
blocked.
On Jun 14, 2011, at 9:39 AM, Zubair Nabi wrote:
> 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.php and
> >> 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
---
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
------------------------------------------------------------------------------
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
