Sounds good. I'm a bit concerned yet, though, on having more than one port open
at a time... Not sure that really is necessary, and sums up to the complexity
of it.
On Jun 20, 2011, at 8:58 AM, Zubair Nabi wrote:
> 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
---
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
------------------------------------------------------------------------------
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
