Hey Alan,
Yeah I agree. Opening so many ports will demotivate people. But what other
options do we have? We need to come up with a solution soon.
On Tue, Jun 14, 2011 at 9:07 PM, Zhongjie Wang <[email protected]> wrote:
> Hi Zubair,
> That's a fancy way to detect service differentiating. So I guess our
> testing flows will
> have different payloads, and against different port numbers, right?
> It's a higher requirement to the super peer. It will open lots of
> ports on user's computer.
> So maybe some user will dislike it. They will feel it like a risk, will
> cause their computer unsafety.
> If so, we need to let user choose whether they are willing to be a
> super agent. I guess
> most of them will choose no... and we need to think about how to motivate
> them to be super peers.
> Another way is deploying some target servers for testing. A drawback
> is that they may be blocked.
>
>
> On Tue, Jun 14, 2011 at 8:39 PM, Zubair Nabi <[email protected]>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.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-gsoc mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/umit-gsoc
>>
>
>
>
> --
> Zhongjie Wang
> Master Candidate
> Computer System Architecture
> Peking University, China
>
--
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
