True.
What if all desktop agents act as servers. But the catch would be that each
desktop agent will only have a X distinct number of ports open.
If the aggregator assigns Service Y to mobile agent Z, then the aggregator
will also assign a desktop agent to Agent Z based on, 1) That the desktop
agent has ports for that particular service open, 2) The desktop agent and
mobile agent are behind different ISPs, 3) The desktop agent isn't serving a
threshold number of mobile agents already (to ensure load balancing).
On Sat, Jun 18, 2011 at 7:28 AM, Adriano Marques <[email protected]>wrote:
> Hi Zubair,
>
>
> On Jun 16, 2011, at 8:12 PM, Zubair Nabi wrote:
>
> Can't we use something like m-lab or planet lab to deploy. We can using to
> mask the fact that we're routing to m-lab or planet lab.
>
>
> Not sure I got what you meant here...
> Anyways, on integrating with m-lab, planet lab or glasnost I think that it
> is fine, as long as we can survive *WITHOUT* them. Remember, our major goal
> is to be independent. So I would first pursue our own way being independent,
> and then later write code that would make use of those extra servers.
>
>
> On Thu, Jun 16, 2011 at 8:10 PM, Adriano Marques
> <[email protected]>wrote:
>
>> From glasnost paper, they sad that when they required people to open
>> ports, they got 50 people world wide using their software... Once they
>> lowered that bar, they got 350k. I guess we better find a better solution
>> soon, as Zubair suggested, or our project will be born dead.
>>
>>
>> On Jun 15, 2011, at 10:28 AM, Zubair Nabi wrote:
>>
>> > 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-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
>>
>> "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
>
>
> ---
> Adriano Monteiro Marques
>
> http://www.thoughtspad.com
> http://www.umitproject.org
> http://blog.umitproject.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
