Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.


tp4: question on cwnd (page 10), if you can not solve it how to go on with tp
we give you a lot of hints for this question (see blog), but if still you can not find what limits cwnd at value 91 (or 92), in order to do the rest of the tp successfully you can just assume for this question that:

- cwnd is limited by value 91 (or 92) and can not go above this value even if congestion control mechanisms and very small losses or no-losses would let cwnd goes above this value
-RTT is not cause for cwnd limitation, but RTT is a consequence - in experiment 1 and 2! In experiment 4 it will not be like this!

Also be aware (we already told this to you) that in this tp system and experiments main RTT component comes from queuing, other components are almost negligable.
Posted by Slavisa Sarafijanovic at 8:30
tp4 experiment 1
We've just tried to apply the command "echo 0 > /proc/sys/net/ièv4/tcp_bic" (p.9) but the file tcp_bic wasn't present in the system (of the Workstation). Did we miss something? Can we just pass through it and continue the TP?
Thanks in advance,
The Quang.
Posted by The Quang Nguyen at 11:04
Comments (2)
tp4: additional hint for question on cwnd
For the Question (page 10):

Explain what limits the value of cwnd in this experiment? Refer to appropriate lines of code and observed
parameter values that matter for the explanation. Show the computation that confirms your answer, and
explain your conclusion. (Hint: think about sending window, cwnd, offered window, scale option(mentioned
in the introduction), and in_flight variable (also mentioned in the introduction). )

Additional hint: to find the answer and proper explanation, you have to take into account _ALL_ things we (already) suggested: sending window, cwnd, offered window, scale option(mentioned in the introduction), and in_flight variable (also mentioned in the introduction).
Posted by Slavisa Sarafijanovic at 14:01
exercise 3

In the exercise 3, when we set up the preferences of the routers, all the routing tables converged. The paths chosen weren't the optimal ones that the routers would like, but they looked correct. For example, R1 had a direct path to R4 and not one going through R2 and R4.
Everything looked correct to us, so we don't know what's the problem that we need to fix. Any help?

Thanks a lot.

Have a nice vacation

Ghita Mezzour
Posted by Ghita Mezzour at 21:53
Comments (1)
ip as-path!!!

There's something we don't get. If we try some filtering with a simple acess-list and IP prefixes everything works as expected. Now if we simply replace the lines access-list with ip as-path access list, it simply denies everything, even if we have a permit any..... HELP!

Group A19
Posted by Christophe Gudin at 13:52
Comments (2)
TP3 - Changes on TP deadline and in Problem 3
Hi all,
the new dedline for TP3 is on January 11, 2007.
You can hand it in either during the office hours on January 11, or just before the beginning of the lecture, in INM 202, always on January 11.
Please note that the deadline is sharp: reports that are handed in
after will be accepted for grading but 20 points (out of 100) will be taken off. Reports for TP3 will not be accepted after Monday 15 january 2007.
Also, Problem 3 is now an optional part of TP3: if well done, it gives you bonus points for the grade of that TP.
Posted by Gianluca Rizzo at 13:33
TP3 Report Submission
Next week I will not be in Lausanne therefore cannot hand-in the TP3 report on paper, can I submit it via email instead? If so, to whom should I send it to? Thank you.
Posted by Roberto Cardona at 10:35
TP3 - Problem 1 - recommendation
Hi all,
in Problem 1, we recommend you to assign to all network interfaces which are on the same hub Ip addresses on the same subnet.
Also, on page 18, for the question "How many paths exist....", you should answer according to what you observe at router R1.
Posted by Gianluca Rizzo at 17:19
Tp3, redistribute...

We have a little hesitation. If we understood correctly, the command "redistribute connected" will only tell the neighboring bgp routers about the on-link subnets of a given router. i.e. R4 will only tell R2 about the subnet going towards R6 but not anything it learned from R6. (It is at least what we seamed to experiment). Is this correct?

If so, how can we make routers forward information they received avoiding the use of the "network" command which would require a router to know exactly in advance what he will be advertised?

Thanks for your help,

Group A19.
Posted by Christophe Gudin at 17:13
Comments (1)
TP3 - precisation
Hi all,
in the pictures for problem 1 (p. 15) and 2 (on p.20), when you have to configure a BGP speaker, and you have to decide with which BGP speaker of a neighboring AS it has to estabilish a TCP connection for BGP data exchange, you must choose the one which is geographically closer (according to the picture) to the one you are configuring.
As an example, as the figure on p.15 suggests, router R5 will choose as neighbor router R3 of as 65341, and not router R4.
Posted by Gianluca Rizzo at 17:44
Page : 1 2 Next »