transferring large data - UDP/TCP

[eddievu]

hi there,

i understand that when transfering data from A to B in a gerarl way would be like this

with UDP:

Application send data to the transport layer. The data won't be chop to smaller pice and numbered and the the data will be encasulates a headers, containing source port number, destination port number, total length, checksum if required and send to the next layers. if a packet is drop, the sender will continue to send the next packet, and won't resend the packet that was dropped.  if the packet is succesfully delivered , it will  goes through all layers decapsulate headers and wont send an acknowledgement. there is no flow control and no error control in udp

With TCP:

Connectoin beteen is establish. application layer send a pakcet, reaches transport layer, headers contains source address, destination port, sequence number, acknowledgement number, header length and control will be added and will send to the next layers. after data reaches the other end, it will be send an acknowledgement, and decapsulate the packet in all the layers. if a packet is dropped, the sender will resend it

SO my question is, will all the steps be excatly the same with massive volume of data? will there any changes? what does that mean to flow control and error control in TCP

[Flavio Miranda]

Hello,

  It is the same thing. Look, When someone develops such protocols, about 40 years ago, the amount of data transfered back and forth was redicously smaller than today, right?  But, the beauty of those protocols is that, they do their jobs for 40 years dont matter how much data it is necessary to transfer. They work with a packet at a time, on and on.

 Would be very complicate change protocol behavior based on the amount of traffic. Protocol even dont know about how many packet they have to transfer.

 Flow control is very simple. You can have an high end server full of memory and CPUs exchanging data with an old PC. Of course, server will be able to send much more data than the old PC is able to process. Then, Flow control helps the slow side to receive and process all the packet sent by faster server.

 Error control is even more simple. Many factors can impose some error on the packet and those packet should be identified and re-sent.

 Is that making sense?

[eddievu]

hi there,

thank you so much for your answer,

i do have a follow up question about packet drop,

why packets drop are happening with both tcp and udp, and how to resolve it

[Flavio Miranda]

I'd say that the most common reason for packet drop is layer 1 problem. Specifically is not possible to point but most case comes from bad links.

 Other possibility is resource exhaustion on ends like high CPU usage.

Anyway, can be many things so if you need to figure out, start looking at Layer 1.

[Joseph W. Doherty]

Well, first you need to ascertain why the drops are happening, then see if the cause can be resolved or mitigated.

As Flavio has noted there can be many causes, such as Flavio mentioning you might have a network L1 or host resource issue causing drops, but you might also have a network congestion issue that causes drops. Flavio suggests that a L1 issue is the most common cause, and if we're on a LAN, he might be correct. However, when dealing with WAN links, I've often seen congestion being the most common issue as WAN links often don't provide the bandwidth of LAN links.

[Joseph W. Doherty]

With UDP, volume of data makes no difference, at least as far as the protocol is concerned. (BTW, applications built on UDP might perform some kinds of error recovery.)

With TCP, volume of data can and/or may make a difference to TCP behavior.

With TCP, volume of data interacts with receiving host's RWIN. Also with TCP, more data being sent, at one time, could get TCP out of slow start and might also be more likely to congest and trigger TCP's flow control and/or error recovery.