[Ns-developers] GSOC 2012 Path Mtu discovery draft proposal

Tommaso Pecorella tpecorella at mac.com
Mon Mar 26 15:24:41 PDT 2012


Hi Anush,

thanks for the mail, but I have to remember you that all the GSOC application MUST be processed using Melange. Go to this address:
http://www.google-melange.com/gsoc/homepage/google/gsoc2012
and follow the instruction to apply as a student.

Good luck with the application (it's a contest after all).

Best regards,

Tommaso



On 26 Mar 2012, at 21:03, anush vishwanath wrote:

> Hi Tommaso,
> I'd like to apply for the project concerning the Path MTU discovery for ipv6.
> I went through the entire RFC [1981] and understood what exactly has to be done.In the RFC they specify various types of implementations for each module.So i have narrowed down on which i would like to implement for ns-3.
> Also i went through the ipv6-l3-protocol.cc code.
> I admit i did not understand the entire code at one go but i definitely got the hang of it and i am determined to give my best and understand the entire functionality to the last word come what may :)
> I am writing below my 'Approach' and 'Deliverables' as indicated by your application template as being the most important aspects of the proposal.Please do send me your comments on them so i can really make a very god proposal and get selected to work for ns-3 :)
> 
> Approach:
> 
> I.What is your technical plan for achieving the goals of the project?
> What components and functionality will have to be developed, integrated etc.?
> 
> The Path MTU discovery technique is a very tricky procedure as opposed to what meets the eye mainly due to the subtleties involved.
> 
> a)The simple implementation involves sending packets of the size equal to the MTU of the 1st hop till you get a Packet Too Big ICMP message. Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message.This process is carried out iteratively till the actual PMTU is computed.Also while dealing with multicast addresses we must choose the least PMTU value among the PMTU's of all the possible paths.The main thing to consider here is that the paths keep changing over time and the PMTU process must be run at every fixed timesteps.
> 
> b)A node must never be allowed to increase its PMTU value in response to a Packet Too Big message.Also it must not be allowed to decrease the PMTU value beyond the applicable ipv6 minimum link mtu.These boundary conditions will be taken care of in my implementation.
> 
> c)In my implementation the IP layer will store the PMTU information and that the ICMP layer process received Packet Too Big messages.The packetization layers(TCP) may respond to changes in the PMTU, by changing the size of the messages they send.  To support this layering, packetization layers will learn of changes in the value of MMS_S, the "maximum send transport-message size". If the transport layer protocol is such that the packet size cannot be changed then we can look into fragmentation as an option (maybe???).
> 
> d)This implementation will use the destination address as the local representation of a path.The PMTU value associated with 
> a destination would be the minimum PMTU learned across the set of all paths in use to that destination.The set of paths in use to a particular destination is expected to be small, in many cases consisting of a single path. 
> 
> e)Also when a Packet Too Big message is received retransmission of the packet will be supported as it would have been dropped by some node in the path.But here again i will make sure that the retransmissions do not flood the network and congest it wen Path MTU discovery is in progress.
> 
> f)Timestamp based approach will be used to make sure the PMTU value is not stale and that no other better path has arisen in d recent past.
> 
> g)If a TCP implementation is used the it must store the MSS value as mentioned above.The other major aspect is to moderate and maintain the compatibility between the sender's window size and size of the segment.
> 
> h)Finally an interface will be provided to be able to specify that Path discovery need not be implemented for a particular path and to change the PMTU value associated with any path.
> 
> All of the above processes shall be implemented as different modules and integrated to work as a cohesive unit.
> As i went through the ipv6-l3-protocol.cc file i noticed a few methods which are already written which might come in handy for my implementation like 
> 1.uint16_t Ipv6L3Protocol::GetMtu (uint32_t i) const
> 2.Ptr<Ipv6L4Protocol> Ipv6L3Protocol::GetProtocol (int protocolNumber) const
> 3.Ptr<Icmpv6L4Protocol> Ipv6L3Protocol::GetIcmpv6 () const
> 4.void Ipv6L3Protocol::Send (Ptr<Packet> packet, Ipv6Address source, Ipv6Address destination, uint8_t protocol, Ptr<Ipv6Route> route)
> 5.void Ipv6L3Protocol::Receive (Ptr<NetDevice> device, Ptr<const Packet> p, uint16_t protocol, const Address &from, const Address &to, NetDevice::PacketType packetType)
> 6.void Ipv6L3Protocol::IpForward (Ptr<Ipv6Route> rtentry, Ptr<const Packet> p, const Ipv6Header& header)
> 7.void Ipv6L3Protocol::IpMulticastForward (Ptr<Ipv6MulticastRoute> mrtentry, Ptr<const Packet> p, const Ipv6Header& header)
> 8.Ipv6Header Ipv6L3Protocol::BuildHeader (Ipv6Address src, Ipv6Address dst, uint8_t protocol, uint16_t payloadSize, uint8_t ttl)
> Each of the above methods can be used and built upon to implement the required Path MTU discovery functionality.
> 
> II)Which development methodology would you use?
> I shall be using waterfall design methodology to implement this project.This project lends itself naturally to the waterfall model strategy as all the various parameters are interlinked and requires all to be implemented for the proper functioning of the path MTU discovery.
> 
> III)What testing approach are you going to use to ensure the code quality?
> I shall test the code sufficiently and rigorously to try and see if all the parameters to be implemented with repect to path MTU discovery have actually been correctly implemented.
> 
> 
> Deliverables:
> 
> a)Complete understanding of the existing n3-3 code for ipv6 protocol implementation and how to interface this path mtu discovery into this code.
> b)Building of the simplistic implementation of just setting the 1st MTU and receiving the Packet Too Big messages. 
> c)Implementing for multicast addresses and changing the PMTU value depending on the responses received. 
> d)Implementing the proper retransmission so as to not clog the network
> e)Implementing the timestamp based approach to overcome the problem of stale PMTU data
> f)Final integrating of all modules
> 
> sorry for the extremely long mail..hope you can give me good pointers as to what to improve for my main proposal..
> 
> Regards,
> Anush V
> 3rd Year student,
> PES Institute of Technology,
> Bangalore, India
>  

--------------------------------------------------------------

The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait another year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella at unifi.it
       tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569








More information about the Ns-developers mailing list