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.
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
