Lord Mandelson of Foy and Hartlepool is a descendant of which Labour leader? 1.Harold Wilson 2.George Brown 3.Gordon Brown 4.Herbert Morrison 5.Clement Attlee

Herbert Morrison Not entirely obvious, I admit. Morrison was Mandelsons mothers father, and Labour leader of London County Council.

That was the warmup Now to check clickers against groups IF your group name is shown, please press the associated number on each individual clicker AND the group clicker ELSE wait for next slide(s)

Please select a Team: If youre not here, wait. 1.Team A 2.Team B 3.Team C 4.Team D 5.Team E

Please select a Team: If youre not here, wait. 1.Team F 2.Team G 3.Team H 4.Team I 5.Team J

Please select a Team If youre not here, you should have been done already 1.Team K 2.Team L 3.Team M 4.Team N

Now for your questions Im going to show the individual slide please answer as individuals. Then Ill ask you to start conferring. Part way through this, Ill show the individual answers. Then Ill put up the group slide, and ask groups to vote using the group clickers only A group should vote on its own question

I: What would be the biggest impact of removing the ACK field from TCP? 1.Without ACKs reliability benefits, TCP would become obsolete. 2.Reliability would always need to be implemented at application level. 3.Fewer small packets would result in a faster Internet. 4.Lack of self clocking would result in a slower Internet.

G: What would be the biggest impact of removing the ACK field from TCP? 1.Without ACKs reliability benefits, TCP would become obsolete. 2.Reliability would always need to be implemented at application level. 3.Fewer small packets would result in a faster Internet. 4.Lack of self clocking would result in a slower Internet.

What would be the biggest impact of removing the ACK field from TCP? 2. Reliability would always need to be implemented at application level. By losing the option to use TCP for reliability, the feature would need to be implemented at application level (as in UDP). Guaranteed Delivery would become less common as it would be down to the developer to implement it. The quality of alternative reliability systems would vary significantly. Lack of protocol would make inter-application communication difficult.

I: When a user performs a DNS query, they often get back more information than they asked for. Why? 1.Its faster because the DNS server doesnt have to work out which specific DNS record type the user needs. 2.It figures youll ask subsequent questions based on the same information so it gives you the answers in advance. 3.It reduces the likelihood of DNS spoofing, because we can check that the additional information backs up the information we did want. 4.Its useful for debugging purposes, in case there are errors resolving the address. 5.Networking enthusiasts find this information interesting, and it doesnt add much additional traffic by including it.

G: When a user performs a DNS query, they often get back more information than they asked for. Why? 1.Its faster because the DNS server doesnt have to work out which specific DNS record type the user needs. 2.It figures youll ask subsequent questions based on the same information so it gives you the answers in advance. 3.It reduces the likelihood of DNS spoofing, because we can check that the additional information backs up the information we did want. 4.Its useful for debugging purposes, in case there are errors resolving the address. 5.Networking enthusiasts find this information interesting, and it doesnt add much additional traffic by including it.

When a user performs a DNS query, they often get back more information than they asked for. Why? 1.Its faster because the DNS server doesnt have to work out which specific DNS record type the user needs. - The user has already told the DNS server what record it needs. 2.It figures youll ask subsequent questions based on the same information so it gives you the answers in advance. 3.It reduces the likelihood of DNS spoofing, because we can check that the additional information backs up the information we did want. - The whole DNS record could still be spoofed. 4.Its useful for debugging purposes, in case there are errors resolving the address. - Debugging is not its primary purpose. 5.Networking enthusiasts find this information interesting, and it doesnt add much additional traffic by including it. - It wont add much additional traffic, but it isnt specifically there just to please networking enthusiasts.

I: Which of these criteria need to be considered when deciding if an autonomous system is needed? 1.You manage a collection of networks 2.You have a different routing policy to your border gateway peers. 3.You need to send ICMP redirects. 4.You need to exchange external routing information.

G: Which of these criteria need to be considered when deciding if an autonomous system is needed? 1.You manage a collection of networks 2.You have a different routing policy to your border gateway peers. 3.You need to send ICMP redirects. 4.You need to exchange external routing information.

Answer Slide The most appropriate criteria is 2. This is because an AS is only required in this circumstance. 1 & 4 can also be considered. There are scenarios when ASs can be created. 3 is incorrect. It isnt relevant.

I: What is the most important algorithm for preventing packet timeouts occurring in TCP? 1.Fast recovery 2.Jacobson RTO calculation 3.Karns algorithm 4.Fast retransmit

G: What is the most important algorithm for preventing packet timeouts occurring in TCP? 1.Fast recovery 2.Jacobson RTO calculation 3.Karns algorithm 4.Fast retransmit

Answer Fast recovery and fast retransmit work together to ensure lost packets are dealt with more quickly than allowing the default timeout to occur. Jacobson RTO calculation is used to calculate the default timeout but this does not directly prevent them occuring. Karns algorithm is relevant to packet timeouts but does not directly impact them.

I: Which of the following situations is the trivial file transfer protocol (TFTP) best suited for? 1.Transferring small files quickly on a secured network 2.Transferring files securely over a LAN 3.Bootstrapping a networked diskless system 4.Transferring a file to multiple clients at once 5.Use on systems with limited memory

G: Which of the following situations is the trivial file transfer protocol (TFTP) best suited for? 1.Transferring small files quickly on a secured network 2.Transferring files securely over a LAN 3.Bootstrapping a networked diskless system 4.Transferring a file to multiple clients at once 5.Use on systems with limited memory

Answer Best: Bootstrapping a networked diskless system The main use of TFTP is for booting multiple networked devices such as thin clients. Possibly: Transferring a file to multiple clients at once Despite using UDP TFTP does support parallel access to a file by using multiple ports. Possibly: Systems with limited memory TFTP can fit in read only memory and is therefore useful where resources are limited. Possibly: Transferring small files quickly on a secured network There is no real speed increase using TFTP other than the fact it is lightweight, and the timeouts are lousy. Incorrect: Transferring files securely over a LAN TFTP has no security features and therefore should only be used over a network where the security is carefully controlled, or via another secure method such as a VPN.

I: The triggering of fast retransmission of data is based on a key assumption: "if three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost (Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2003). Is this assumption safe? A.Yes, it's always true - its even written in an RFC. B.Yes, although this could signal reordered rather than lost segments, the consequences are not serious C.No, although it's unlikely the ACKs could signal something else, such as reordering of segments, unnecessary retransmissions could potentially flood the network. D.No, it's a completely flawed assumption that has yet to be removed from implementations of TCP.

G: The triggering of fast retransmission of data is based on a key assumption: "if three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost (Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2003). Is this assumption safe? A.Yes, it's always true - its even written in an RFC. B.Yes, although this could signal reordered rather than lost segments, the consequences are not serious C.No, although it's unlikely the ACKs could signal something else, such as reordering of segments, unnecessary retransmissions could potentially flood the network. D.No, it's a completely flawed assumption that has yet to be removed from implementations of TCP.

And the most likely answer is…B A duplicate ACK may be a sign of segments getting reordered or a packet being lost. In the case of reordering however, it is unlikely that more than two would be received. Even if a packet was mistakenly retransmitted it would not be processed more than once - the receiver would send out a duplicate ACK thereafter.

I: Which is the more suitable option out of the following: 1.All Multicasting should be handled at the Network layer 2.All Multicasting should be handled at the Application layer 3.Either is fine and both layers should be able to handle multicasting 4.Either is fine and if it cant handle multicasting, then the loss is acceptable

G: Which is the more suitable option out of the following: 1.All Multicasting should be handled at the Network layer 2.All Multicasting should be handled at the Application layer 3.Either is fine and both layers should be able to handle multicasting 4.Either is fine and if it cant handle multicasting, then the loss is acceptable

No right answer! Any one of them can be justified. Currently performed in Network layer, but does not have to be. Just as justifiable to use Application Layer, which is used for Mobile Devices. Can argue that separation is important, but can also argue that depends on context. Forcing all network layer components to handle it would be expensive though.

I: Historically Nagles algorithm was developed to reduce network congestion for applications like rlogin and telnet. With today's networks why would someone wish to disable it? 1.It increases network latency 2.It conflicts with other TCP congestion avoidance techniques 3.It is not relevant anymore with todays high bandwidth connections 4.A newer algorithm has been developed that is now used

G: Historically Nagles algorithm was developed to reduce network congestion for applications like rlogin and telnet. With today's networks why would someone wish to disable it? 1.It increases network latency 2.It conflicts with other TCP congestion avoidance techniques 3.It is not relevant anymore with todays high bandwidth connections 4.A newer algorithm has been developed that is now used

Answer – more than one correct 1) Yes it can increase latency but only when the network is lightly loaded. For heavily loaded networks Nagles algorithm is relevant. 2) Yes, Nagle algorithm can cause extended waiting when used in combination with the delayed ACK algorithm 3) No, bandwidth does not play a part. It depends on the load of the network (see point 1) and the type of data being sent. Small packets which require a fast response time (interactive such as mouse movements in x-windows) are unsuitable for Nagles algorithm. An unloaded network can often lead to many delayed ACKs not being sent until the timer fires, again useless for highly interactive applications. 4) No, no newer algorithm has been widely accepted. However, newer propositions and enhancements to Nagles algorithm have been suggested, like for example Minshalls algorithm.

I: Given the current technology, should Delayed ACKs be used? 1.No, because advances in technology have rendered them obsolete. 2.Yes, because they reduce the number of segments sent. 3.Yes, because it says so in RFC Yes, but only on WANs. 5.No, because they can disturb round-trip timing and packet clocking algorithms.

G: Given the current technology, should Delayed ACKs be used? 1.No, because advances in technology have rendered them obsolete. 2.Yes, because they reduce the number of segments sent. 3.Yes, because it says so in RFC Yes, but only on WANs. 5.No, because they can disturb round-trip timing and packet clocking algorithms.

Given the current technology, should Delayed ACKs be used? 1.Wrong. WANs can still suffer congestion. 2.Delayed ACKs can reduce the number of segments sent over a network. 3.Wrong. RFC2581 only states that an acknowledgment must be sent within 500ms, thus making a delay possible, not enforcing it. 4.Delayed ACKs can reduce congestion on WANs by reducing the number of segments sent. 5.Wrong. Only seriously delayed ACKs will cause trouble like this. RFC2581 says that ACKs should be sent within 500ms so this should not be a problem.