Course: CIS856 TCP/IP & Upper Layer Protocols - Course
Project
Professor: Paul D. Amer
Semester: Fall 2012
Last updated: 8-27-2012
Each student must select a topic from the list below (students must
select a topic that they do NOT already know), and satisfy these requirements:
- immediately perform a literature search and begin becoming an expert on your topic
- do not wait; it is expected that you will be learning your protocol
starting from week one)
- prepare and give a Powerpoint class presentation
- you need to start meeting with the professor at least ten days
before the presentation day to be sure of having your presentation approved beforehand
- design a homework assignment to be done by the other students
- you must meet with the professor at least one week prior to the class presentation and
receive the professor's approval of the assignment
- hand out the assignment at the class presentation
- respond to student questions via email about the assignment
- collect the assignments due one week after the presentation
- correct the submitted assignments within two days, clearly indicating (i) which answers are wrong,
and (ii) what are the correct answers
- meet with the professor, and go over the corrected assignments; the professor will assign grades
- you will be graded on the quality and creativity of the assignment,
and on how well you correct the assignment
- Note: it is the student's responsibility to set up appointment(s) with the professor to gain
advance approval of the presentation and homework assignment.
List of Topics Legend
- [n] - intended for networking MS-thesis and PhD students; open to all students
- [ms] - only open to non-networking students
- [*] - higher priority topics (TRY to PICK ONE of THESE!)
Core TCP/IP Protocols
- [ms - not available to my past 450/650 students] Dynamic Host Configuration Protocol (DHCP)(RFC2131) - provides configuration
parameters to Internet hosts. DHCP consists of two components: a
protocol for delivering host-specific configuration parameters from a DHCP
server to a host, and a mechanism for allocation of network addresses to
hosts. Includes BOOTP. www.isc.org/products/DHCP/
See The DHCP Handbook by Ralph Droms, Ted Lemon
- [*][ms] File Transfer Protocol (FTP) (RFC959,1415) -
Of particular interest here is the interaction
with the 2MSL wait state. Also see RFC2640 - Internationalization
of FTP.
- [*] [ms] Simple Mail Transfer Protocol (SMTP) (RFC821,822,1425,1426,1427) -
Electronic mail and its MIME extensions. The book and RFCs are a
good starting point, but this topic should investigate Sendmail and/or
MMDF to fully understand the architecture of MTAs (Message Transfer Agents.)
Includes overview of the differences between IMAP and POP.
- [ms - not available to my past 450/650 students] Hypertext Transfer Protocol
(HTTP) v1.0 (RFC1945); v1.1 (RFC2616,2817) - Clarify differences in the
TCP traffic resulting from non-persistent, persistent w/o pipelining, and
persistent w/ pipelining. Include performance differences, and highlights
of current research activity. (covered in 650, but very important)
Variations to improve TCP performance
- [n - probably taught by Amer] TCP Congestion Control Variations - Tahoe (slow start, congestion avoidance, fast retransmit
- RFC2581), Reno (fast recovery - RFC2581), NewReno (partial acks and modified
fast recovery - RFC2582), and Vegas: focus on the flow/congestion control
differences between various TCP implementations, comparing fast recovery,
partial acks. See chapter 11 in High Performance TCP/IP Networking
by Hassan and Jain, and papers by Peterson www.cs.arizona.edu/protocols/
and Floyd www.aciri.org/floyd/
- [*][n] MPTCP Multipath TCP - a set of TCP extensions that implements a
multipath transport and achieves these goals by pooling multiple
paths within a transport connection, transparent to the application. See Internet draft: draft-ietf-mptcp-architecture, and https://datatracker.ietf.org/wg/mptcp/charter/
In supporting the use of multiple paths, MPTCP has two functional goals:
-
Improve Throughput: Multipath TCP MUST support the concurrent use
of multiple paths. To meet the minimum performance incentives for
deployment, a Multipath TCP connection over multiple paths SHOULD
achieve no lesser throughput than a single TCP connection over the
best constituent path.
-
Improve Resilience: Multipath TCP MUST support the use of multiple
paths interchangeably for resilience purposes, by permitting
packets to be sent and re-sent on any available path. It follows
that, in the worst case, the protocol MUST be no less resilient
than regular single-path TCP.
- [*][n] HSTCP HighSpeed TCP - aims at improving the loss recovery time of standard TCP by changing standard
TCP's AIMD algorithm. This modified algorithm retains TCP's slow start phase, and only take effect with higher congestion
windows (i.e, if the congestion window is smaller than a given threshold, a TCP sender uses the Standard
AIMD algorithm, else the TCP sender uses HighSpeed AIMD algorithm.) See RFC3649, and also Scalable TCP
- [*][n] BIC, CUBIC - variation of TCP with an optimized congestion control algorithm for high speed networks with high latency (LFN: Long Fat Networks). See http://netsrv.csc.ncsu.edu/twiki/bin/view/Main/BIC.html
CUBIC is a less aggressive and more systematic derivative of BIC TCP, in which the window is a cubic function of time since the last congestion event, with the inflection point set to the window prior to the event. Being a cubic function, there are two components to window growth. The first is a concave portion where the window quickly ramps up to the window size before the last congestion event. Next is the convex growth where CUBIC probes for more bandwidth, slowly at first then very rapidly. CUBIC spends a lot of time at a plateau between the concave and convex growth region which allows the network to stabilize before CUBIC begins looking for more bandwidth.
Another major difference between CUBIC and standard TCP flavors is that CUBIC does not rely on the receipt of ACKs to increase the window size. CUBIC's window size is dependent only on the last congestion event. With standard TCP, flows with short RTTs will receive ACKs faster and therefore have their congestion windows grow faster than other flows with longer RTTs. CUBIC allows for more fairness between flows since the window growth is independent of RTT.
- [n] Flow Rate Fairness - A proposed 'revolutionary' TCP congestion control that argues
to judge the fairness of transport mechanisms on how flow rates
share out the cost of each user's actions on others, not the current
approach of evaluating fairness mechanisms in terms of sharing out
flow rates. See A Fairer, Faster Internet Protocol
by Bob Briscoe, and its rebuttal RFC5290 by Sally
Floyd and Mark Allman. This topic should include a solid discussion of the term "TCP-friendly."
-
[n] TCP Vegas - TCP Vegas is a TCP congestion control, or network congestion avoidance, algorithm that emphasizes packet delay, rather than packet loss, as a signal to help determine the rate at which to send packets. It was developed at the University of Arizona by Lawrence Brakmo and Larry L. Peterson (now at Princeton).
TCP Vegas detects congestion at an incipient stage based on increasing Round-Trip Time (RTT) values of the packets in the connection unlike other flavors like Reno, NewReno, etc. which detect congestion only after it has actually happened via packet drops. The algorithm depends heavily on accurate calculation of the Base RTT value. Note: while TCP Vegas has been implemented, it has not "caught on" in 15 years. However the ideas of TCP Vegas are quite interesting and valuable.
- [n] Data Center TCP (DCTCP) - designed for data center networks, DCTCP
leverages Explicit Congestion Notification (ECN) in the network to provide
multi-bit feedback to the end hosts. DCTCP delivers the same or better throughput
than TCP, while using 90% less buffer space. Unlike TCP, DCTCP also provides
high burst tolerance and low latency for short flows. In handling workloads
derived from operational measurements, DCTCP enables applications
to handle 10X the current background traffic, without impacting foreground traffic.
Further, a 10X increase in foreground traffic does not cause any timeouts, thus
largely eliminating incast problems. (see paper in SIGCOMM 2010)
- [*][n] Selective ACKs (SACKs), Reneging, and Non-Renegable Selective ACKS
(NR-SACKS)
- TCP may experience poor performance when multiple
packets are lost from one window of data. With the limited information
available from cumulative acks, a TCP sender can only learn about a
single lost packet per round trip time. SACKs (RFC2018) combined with a selective
repeat retransmission policy can help overcome these limitations.
Non-Renegable Sacks (NR-SACKs) - an extension to
SACKs semantics. NR-SACKs acknowledge TCP (or SCTP) PDUs that a
receiver guaranteess will never be reneged.
-
[ms] Several small topics: pick two or three to be considered one project
- [n] Appropriate Byte Counting (ABC) (RFC3465) - calls for TCP implementations
to maintain and increment the congestion window for a TCP connection in
bytes rather than packets. Developed in part to prevent "ack-splitting"
where a receiver sends back multiple acks for one received data packet
in order to 'cheat' TCP's congestion control and open up the sender's window
faster than is TCP-friendly. Also RFC3565 on Appropriate Byte Counting
defines a limit L for increasing the congestion window of a TCP connection
per Ack.
- Limited Transmit option for TCP (RFC3042) - allows TCP senders to send
new data on duplicate acks.
- Early Retransmit for TCP (Internet draft draft-allman-tcp-early-rexmt-??.txt) - allows TCP senders to retransmit
data earlier than having received three duplicate Acks. Early retransmit
was developed for application-limited flows that are unavailable to use
Limited Transmit.
-
Increasing TCP's Initial Window (RFC2414) - specifies an increase in the
permitted initial window for TCP from one segment to roughly 4K bytes.
Discuss the advantages and disadvantages of such a change, and outline
experimental results that indicate the costs and benefits of such a change.
Present results on OSes that already implement a larger initial window (even
larger than 4K bytes.)
- [n] TCP Extensions for High Performance
- a set of TCP extensions including "window scaling" to improve performance over large
bandwidth*delay product paths and to provide reliable operation over
very high-speed paths.
New TCP options allow a receiver window larger than 64K. These extensions
are designed to provide compatible interworking
with TCP's that do not implement the extensions. The timestamps are
used for two distinct mechanisms: RTTM (Round Trip Time Measurement)
and PAWS (Protect Against Wrapped Sequences). See RFC1323.
Alternate Transport Protocols
- [*][n] UDT - a reliable UDP-based application level data transport protocol for distributed data intensive applications over wide area high-speed networks. UDT uses UDP to transfer bulk data with its own reliability control and congestion control mechanisms. The new protocol can transfer data at a much higher speed than TCP does. UDT is also a highly configurable framework that can accommodate various congestion control algorithms. (PPT presentation available)
- [*][n] Micro Transport Protocol (uTP) -
an open source cross-platform protocol used in Bittorrent. uTP
is designed to provide reliable, ordered delivery while maintaining minimum extra
delay. Implemented on top of UDP protocol, uTP was devised to
automatically slow down the rate at which packets of data are transmitted between
users of peer-to-peer file sharing torrents when it interferes with other applications.
uTP uses "low, extra delay background transport" (LEDBAT) congestion control.
see LEDBAT papers here
- [*][n] Transport Layer Security (TLS) - not really a new transport protocol,
rather TLS provides a way to enhance TCP with security services, including
confidentiality, data integrity, and end-point authentication. This enhanced
version of TCP is commonly known as Secure Sockets Layer (SSL). TLS is a slightly
modified verion of SSL v3 [RFC2246]. See Section 8.5 of Kurose and Ross
textbook.
- [*][n] (2 students allowed) Stream Control Transmission Protocol (SCTP)
(RFC2960,3860,4460) - SCTP is a recently proposed transport protocol
that provides a QoS in between UDP and TCP. See www.sctp.de/
and pel.cis.udel.edu/
- [n] Datagram Congestion Control Protocol (RFC4336,5334) (DCCP,
previously DCP) - DCCP implements a congestion-controlled, unreliable
flow of datagrams suitable for use by applications such as streaming
media. DCCP is intended for applications that require the flow-based
semantics of TCP, but which do not want TCP's in-order delivery and
reliability semantics, or which would like different congestion control
dynamics than TCP. DCCP is intended for applications that do not
require some features of SCTP such as sequenced delivery within
multiple streams.
- Delay Tolerant Network (DTN) protocols - Only one of the following
protocols to be presented per semester. The presentation should begin
with a solid introduction to DTNs in general.
- [n] Licklider Transmission Protocol (LTP) - provides an ARQ
mechanism designed to operate over extremely long and/or variable round-trip times.
Convergence layer protocols enable transmisison of "bundles" in an
overlay network. The target RTT is in the range of eight to 40
minutes. The design tolerates lengthly, irregular interruption of a
link, as would occur if a spaceraft went behind a planet.
See the LTP home page: http://masaka.cs.ohiou.edu/ltp
- [n] Saratoga: Efficient Transport over Short-Lived Links -
a transport protocol designed for high utilization of short-lived and extremely
asymmetric links.
Saratoga has been used since 2002 in low-earth orbiting satellites taking images of the earth.
LEO satellites have severe link capacity asymmetry.
The current set has 40Mbps down, with 9.6kbps up; the next revision
is set to have 210Mbps down, with 38.4k up, which is a worse ratio.
These are point to point links, but they encompass the entire path,
and the traffic is scheduled -- congestion control by TDMA.
There is potentital for corruption-based loss, and the data
is large (on the order of several gigabytes).
Other Topics
-
[*][n] Streaming Stored Video - see Sections 7.1 and 7.2 of Kurose & Ross, 6th
edition.
-
[*][n] Session Initiation Protocol (SIP) - a signaling protocol, widely used
for controlling multimedia communication sessions such as voice and video
calls over IP. SIP can be used for creating, modifying and terminating
two-party (unicast) or multiparty (multicast) sessions consisting of
one or several media streams. See RFC 3261. In 11/2000, SIP was
accepted as a 3GPP signaling protocol and permanent element of the
IP Multimedia Subsystem (IMS) architecture for IP-based streaming
multimedia services in cellular systems.
- [*][n] RTP/RTCP/RTSP: Transport Protocol for Real-Time Applications
(RFC3550,3551) (RTP, RTCP, RTSP) - RTP provides end-to-end network
transport functions suitable for applications transmitting real-time
data, such as audio, video or simulation data, over multicast or
unicast network services. RTP does not address resource reservation and
does not guarantee quality-of-service for real-time services. The data
transport is augmented by a control protocol (RTCP) to allow monitoring
of the data delivery in a manner scalable to large multicast networks,
and to provide minimal control and identification functionality. RTP is
a transport protocol for the delivery of real-time data, including
streaming audio and video. RTCP is a part of RTP and helps with lip
synchronization and QOS management, among others. RTSP (RFC2326) is a
real time streaming control protocol for initiating and directing
delivery of streaming multimedia from media servers, the "Internet VCR
remote control protocol". RTP and RTSP will likely be used together in
many systems, but either protocol can be used without the other.
See Section 7.4 of Kurose & Ross, 6th edition.
-
[ms] Skype or Voice over IP (VoIP) - explain how Skype works (a good place to
start is the following paper which reverse engineers Skype -
An Analysis of Skype...
), or more generally provide technical details of how VoIP is implemented.
The emphasis of
this presentation should be on what is done at the transport layer.
See Section 7.3 of Kurose & Ross, 6th edition.
- [*][n] Choose a Peer-to-Peer protocol, e.g., Kaaza, Gnutella, LimeWire,
BitTorrent. The focus is to introduce the general architecture of
the P2P protocol with an emphasis on what transport layer connections are
created and maintained. Presenting a P2P protocol is potentially
a large and challenging topic, and will help a student stand out from the
rest of the class.
- [n] Explicit Congestion Notification (ECN) - Active queue management mechanisms
in routers may use one of several methods for indicating congestion to
end-nodes. One is to use packet drops, as is currently done. However, active
queue management allows the router to separate policies of queuing or dropping
packets from the policies for indicating congestion. Thus, active queue
management allows routers to use ECN as an indication of congestion, instead
of relying solely on packet drops. This has the potential of reducing the
impact of loss on latency-sensitive flows.
www.aciri.org/floyd/ecn.html
Also consider Robust ECN Signaling with Nonces (RFC3540) - an optional
addition to ECN to improve its robustness against malicious or accidental
concealment of ECN-marked packets.
-
[n] TCP Behavior Inference Tool (TBIT) - www.icir.org/tbit/
- TBIT is a tool for inferring the TCP characteristics of a remote system,
answering questions such as "Does the remote system implement Tahoe, Reno,
Vegas, NewReno?", "Does the remote system use SACKs, timestamps?" and "What
is the RTO value of a remote system?"
SCTP extensions (for individuals already familiar with SCTP)
- [*][n] PR-SCTP (RFC3758) - an extension that provides partially reliable
data transmission service to an upper layer, by allowing an SCTP endpoint
to signal to its peer that it should move the cumulative ack point forward.
This ID describes (1) the protocol extensions, which consist of a new parameter
for INIT and INIT ACK, and a new FORWARD TSN chunk type, and (2) one example
partially reliable service that can be provided to the upper layer via
this mechanism.
- [*][n] Dynamic Address Reconfiguration (AddIP) - an extension
that provides a method to dynamically reconfigure IP address information
on an existing association, (RFC 5061),
Literature Search
Each student must do an extensive literature search of the topic studied.
The following places are suggested starting points for finding information
on your topic.
- The course textbook.
- Other networking books available on the professor's bookshelf.
- RFCs, BCPs (Best Current Practices) and Internet Drafts (see www.rfc-editor.org)
- A thorough Web search.)
- A search of the end2end mailing list archives (see ftp://ftp.isi.edu/end2end).
Files are listed by year except the current year is in end2end-interest.mail.
- Networking journals: ACM/IEEE Transactions on Networking, ACM Computer
Communication Review (CCR),IEEE Transactions on {Computers, Communications,
Selected Areas of Communication}, IEEE {Network, Computer, Communications}
Magazine
- Networking conferences: SIGCOMM (proceedings published in CCR), INFOCOM,
GLOBECOM, International Conf on Distributed Computing Systems (ICDCS),
International Conf on Network Protocols (ICNP),
International Conf on Computer Communication (ICCC), Network and Operating
System Support for Digital Audio and Video (NOSSDAV)
Class Presentation Preview
(DUE ONE WEEK BEFORE THE PRESENTATION)
After extensively reading about the topic, each student must select
the most important features of the topic and construct an outline and Powerpoint
slides for a class presentation. The student must schedule a meeting
with the professor. At that meeting, the slides should be in draft
form.
At least half of the slides should be filled with meaningful diagrams
and figures. Slides filled with bulleted lists of text are boring.
Figures reproduced from the textbook or a paper should be enlarged or redrawn.
Slides should never contain characters smaller than 20 point size; only
in rare instances is a smaller font appropriate. Capitalization and
grammar must be consistent. Roughly 15-20 slides are appropriate; never
more that 25.
The presentation grade, in part, will be based on how well the slides
are prepared and the material organized. In this meeting, ways to
improve the slides and talk will be discussed.
Reference materials or handouts that the students need to read before
the presentation should be discussed during this meeting so that arrangements
can be made to notify the class and distribute copies.
Class Presentation
Each student must present a 60-65 minute lecture leaving time for 10-15
minutes of questions and discussion. This activity provides experience
with researching and preparing a lecture at the graduate level. For
the class, the presentation should educate and initiate, motivate, and
guide some amount of questioning and discussion.
The presentation must begin with a good overview including simple
examples in real-life terms (i.e., not in ISO or TCP/IP terminology) giving
the class an understanding as to the general purpose of the topic. No
details should be discussed until it is certain that the class understands
the basic motivation for the topic. Analogies with the Postal System
or the telephone system are often helpful.
While this is not a course in public speaking, the ability and experience
in giving polished presentations is a required skill in the working world.
Many past graduates have indicated that the practice and feedback in making
their 856 class presentation were extremely useful in preparing them for
presentations they later had to make in their jobs. The professor
shall do his best to provide critical, yet constructive individualized
feedback on each student's presentation. The class presentation
grade will be based on:
-
quality (i.e., readability, creativity) and management of the presentation
(e.g., overheads, timeliness)
-
ability to generate class discussion and the handling of questions from
the audience and professor
-
clarity of presentation - how well the student has identified and clearly
presented the important points of the protocol/service.
-
amount of extra preparation (e.g., handouts) - how much pertinent information
has been presented that is not in the textbook or in materials provided
by the professor. To repeat: it is assumed that every student will
do a thorough library and web search.
The key to a good presentation is PRACTICE. (Note: Non-native-English-speaking
students will not be penalized for English mistakes; the professor has
lived and taught in France, and knows first hand the difficuly in presenting
material in a second language!)
My intention in evaluating the presentations is to give them a sense
of importance so that each one is well-planned and done competently.
The professor will spend time with each student prior to the presentation
to discuss and review the overheads and important points.
Homework Assignment
(DRAFT DISCUSSED WITH PROFESSOR DURING WEEK BEFORE CLASS PRESENTATION
;
FINAL VERSION HANDED OUT AT CLASS PRESENTATION)
Each student must prepare a homework assignment for the other students
(and an answer key for the professor!) covering the class lecture and any
assigned readings. This task requires the presenter to consider the important
points that all students should understand and remember after the course
is over.
The homework assignment should preferably be a Wireshark
monitoring experiment. If a live capture in not possible, then the student
can provide a capture (i.e., a .pcap file) for the students to use.
If a hands-on experiment is not possible,
the assignment may consist of three or four essay questions/problems, and/or a small
programming project. As a general guide, the time required for an
average student in the class to complete the assignment should be approximately
2 hours. The assignment must be agreed upon with the professor before the
class presentation.