I have a quick question. If a TCP connection between two host is established and negotiated for ECN, then the sender will be notified of any network congestion by the receiver.
In case if ECN is not negotiated and a packet is dropped by a router,does it send ICMP notification to sender about the dropping packet?
i am just wondering, Why cant cant an intermediate router send icmp message before dropping packets? because it has a way to communicate to sender right. why should sender wait till it receives acknowledgement from receiver?
No. The ECN bit is set and transmitted along with the packet as a mechanism to inform the sender that it should reduce its transmission rate. This should eliminate the dropping of packets.
However, the TCP protocol stack is resonsible for guaranteeing delivery, not the intervening routers. If a packet is dropped it is the responsibility of the receiver to detect this and request the packet again.
Related
UDP is unreliable on packet level.
But, doesn't it provide one response message after recieving all(supposed) packets?
I understand that TCP provide ack for all packets whereas UDP provides one response message for all packets. Am I correct?
UDP is unreliable on packet level.
The qualification is meaningless. UDP is unreliable, period.
But, Doesn't is provide one response message after recieving all(supposed) packets?
No.
I understand that TCP provide ack for all packets
No. It provides enough ACKs so the sender knows where the receiver is up to. This can be accomplished by selective ACKs.
whereas UDP provides one response message for all packets.
No.
Am I correct?
No.
UDP doesn't send any responses at all. The application must do that if required.
TCP connection provides reliable communication between hosts on internet. To ensure reliable communication TCP maintains state information and sequencing of packets in client and server side leading to a duplex connection. This state information is used to provide acknowledgements for received packets. There are variety of techniques of syncing and requesting lost packets according to which number of acknowledgements vary.
UDP is used where reliability is not a requirement so maintaining state information is not required leading to a more light weight protocol operation. One example of its use is streaming applications. No acknowledgement is send in UDP.
I am facing a problem related to the TCP retransmissions.
My Sender starts sending some data to receiver (which is not in the network after opening the connection), after sending 3 packets, it retransmits first packet 3 times (as per the retransmission timeouts)and start sending next packets.
Then it retransmits first packet again. I am not able to understand this behavior and want to know if there is some way I can disable this and force TCP to retransmit first packet and then close the connection if no ack is received.
Thanks.
No there isn't. It's a streaming protocol, not a datagram protocol.
In TCP 3-way handshake, 3 segments will be sent (SYN, SYN ACK, ACK). What if the third segment(ACK) is lost? Is the sender going to resend the segment or give up establishing the connection? And how do the two hosts know the segment is lost?
TCP has a sequence number in all packets. Hence it's easy to know if a packet was lost or not. If a host doesn't get an ACK on a packet he just resends it.
In most cases though, even if that ACK was lost, there will be no resending for a very simple reason. Directly after the ACK, the host that opened the TCP protocol is likely to start sending data. That data will, as all TCP packets, have an ACK number, so the recipient would get an ACK that way. Hence, the sender of the SYN-ACK should reasonably not care that it didn't get the ACK, because it gets an "implicit" ACK in the following package.
The re-send of the SYN-ACK is only necessary of there no data is received at all.
Update: I found the place in the RFC that specified exactly this:
If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
In other words, if the ACK is dropped but the next packet is not dropped, then everything is fine. Otherwise, the connection must be reset. Which makes perfect sense.
I am not an expert on this particular situation, but I suspect what will happen is the client will think it is connected but the server will not. If the client tries to send data to the server, the server will reject it and send a RST packet to the client so it can reset its "connection".
I have a router1-switch-router2 connection. My problem is if I send a packet from router1 to router2, it is not received at router2. I am sure the ipaddress/subnet address are correct. And am also sure that packets are going out the router1. And I am also sure of the internal port connections of the switch. I have access to the onpath switch. Is there any specific command that can be used in the switch to check whether the packet is received or not? ARP itself not getting resolved
You can have a packet capture app running on both the sender and receiver that would tell the incoming and outgoing packets on both boxes.
In this case probably your packet is getting dropped either on the sender or receiver side. There can be million reasons for a packet drop. But this is a good step to start with.
If a TCP connection is established between a client and server, is sending data faster on this connection-oriented route compared to a connectionless given there is less header info in the packets? So a TCP connection is opened and bytes sent down the open connection as and when required. Or would UDP still be a better choice via a connectionless route where each packet contains the destination address?
Is sending packets via an established TCP connection (after all hand shaking has been done) a method to be faster than UDP?
I suggest you read a little bit more about this topic.
just as a quick answer. TCP makes sure that all the packages are delivered. So if one is dropped for whatever reason. The sender will continue sending it until the receiver gets it. However, UDP sends a packet and just forgets it, so you might loose some of the packets. As a result of this, UDP sends less number of packets over network.
This is why they use UDP for videos because first loosing small amount of data is not a big deal plus even if the sender sends it again it is too late for receiver to use it, so UDP is better. In contrast, you don't want your online banking be over UDP!
Edit: Remember, the speed of sending packets for both UDP and TCP is almost same, and depends on the network! However, after handshake is done in TCP, still receiver needs to send the acks, and sender has to wait for ack before sending new batch of data, so still would be a little slower.
In general, TCP is marginally slower, despite less header info, because the packets must arrive in order, and, in fact, must arrive. In a UDP situation, there is no checking of either.