UDP socket

Hi,

what will happen, when the UDP socket application is sending the data
at the speed greater than the receiver speed. Both the system are
connected via cross cable. Ethernet flow control is ON.

My understanding is as follows:-
1) receiver socket buffer will get full and then ethernet flow control
will come in to picture.
2) Sender will slow down its speed.
3) buffer at sender ethernet will get full
4) then sender IP buffer will get full

Is this right?

Now what happen when we send a data on UDP socket?
Will IP layer drop this packet without error return?
or will send/sendto call failed?


Thanks
Gaurav

Gaurav wrote:
> Hi,
>
> what will happen, when the UDP socket application is sending the data
> at the speed greater than the receiver speed. Both the system are
> connected via cross cable. Ethernet flow control is ON.
>
> My understanding is as follows:-
> 1) receiver socket buffer will get full and then ethernet flow control
> will come in to picture.
> 2) Sender will slow down its speed.
> 3) buffer at sender ethernet will get full
> 4) then sender IP buffer will get full
>
> Is this right?
>
> Now what happen when we send a data on UDP socket?
> Will IP layer drop this packet without error return?
> or will send/sendto call failed?
>
AFAIK, UDP by itself does not do error checking. So, you need
somebody else doing the packet integrity check at the application layer.
Can't you use TCP?

--
Mauricio raub-kudria-com
(if you need to email me, use this address =)

Mauricio Tavares <(E-Mail Removed)> wrote:
> AFAIK, UDP by itself does not do error checking.

That is incorrect. UDP includes a checksum covering the data. Now,
in _theory_ the checksum is optional, so in theory an application
which did not need data integrity from the Internet Checksum could
disable it. However, it is "required" that checksums for UDP be
enabled by default.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rick Jones wrote:
> Mauricio Tavares <(E-Mail Removed)> wrote:
>> AFAIK, UDP by itself does not do error checking.
>
> That is incorrect. UDP includes a checksum covering the data. Now,
> in _theory_ the checksum is optional, so in theory an application
> which did not need data integrity from the Internet Checksum could
> disable it. However, it is "required" that checksums for UDP be
> enabled by default.
>
> rick jones

And the ethernet layer checks a CRC

Robert

2006-10-5, 06:49(-07), Gaurav:
> what will happen, when the UDP socket application is sending the data
> at the speed greater than the receiver speed. Both the system are
> connected via cross cable. Ethernet flow control is ON.
>
> My understanding is as follows:-
> 1) receiver socket buffer will get full and then ethernet flow control
> will come in to picture.
> 2) Sender will slow down its speed.
> 3) buffer at sender ethernet will get full
> 4) then sender IP buffer will get full
>
> Is this right?
>
> Now what happen when we send a data on UDP socket?
> Will IP layer drop this packet without error return?
> or will send/sendto call failed?
[...]

By ethernet flow control, you mean "PAUSE" frames, right?

This is how I understand things, but I'm no expert.

the PAUSE frames, for ethernet NICs (network cards) working in full
duplex is a way for a receiver to tell a sender "hold on a moment, my
buffer is full, I can't take any more frame".

It's important to consider that this is happening at data link level and
in the ethernet card (not even the ethernet driver).

When an ethernet card receives a pause, and assuming it is configured to
accept the pause, it will stop transmitting for a moment. An ethernet
card has a transmit ring buffer (same thing for the receive side). The
ethernet driver typically writes ethernet frames to that buffer (or more
likely pointers for the ethernet card to know where to find the frames
in memory to avoid copying the whole frames).

If the ethernet card is "paused" for a moment and the ethernet driver
keeps filling that ring buffer, there'll come a moment where it will
become full. In that case, the ethernet driver will /stop/ the device
(that will be waken up when the card resumes its transmission), that
means that no packet will be dequeued from your device egress discipline
(the bottom-most part of the network stack that prioritise and shape
network traffic).

If you do a ifconfig eth0, or cat /sys/class/net/eth0/tx_queue_len,
you'll see the size of that queue. By default, you get a pfifo_fast
discipline. That discipline has three bands, so three queues of
increasing priority to classify packets of decreasing importance.

If a packet is classified to go on one of those queues and if that queue
is full, then the packet is dropped. If you do a "tc -s qdisc ls",
you'll see the drop counter being incremented.

That doesn't only happen for pause, this happens as well when you send
data faster than your current link speed.

You need to realise we are still at link level here. The qdisc shapes
the traffic going to one interface.

On the receive side, the PAUSE are sent not because the application at
the other end doesn't do "recv" fast enough, that would penalise the
other applications, but when the ethernet driver does not read the
incoming frames from the ethernet card fast enough (when the ethernet
card receive ring buffer is full).

At link level, you've got no guarantee of delivering a packet.

When you do a sendmsg() on a UDP socket, many things happen, a UDP
packet is created that goes through various firewall filters at
different stages, that goes through routing, that is possibly
fragmented, that is sent via a discipline queue to a ethernet driver,
that puts it on an ethernet card ring buffer that eventually transmits
it on a wire.

But when you do the sendto, I beleive (but I may be wrong) that the
system calls returns after that the corresponding packet has been put on
the corresponging link level device's queue (if we forget about the
UDP_CORK thing and unless it has been rejected/dropped by the firewall
or couldn't be routed...). But I think that though you may get error
codes such as EPERM (for fw drop) or ENETUNREACH (for no route to
destination), you don't get an error if the packet is dropped because
the queue is full.

In other words, if there is congestion at link level, packets are
dropped when not queued and your application doesn't know about it, it
might as well be dropped by the ethernet card (for instance because of a
collision) or by the next router...

Transport layers are responsible for avoiding congestion and dealing
with lost packets. UDP is a very simple transport protocol, it only
gives you a source and destination port and content integrity (using a
checksum). So, the application on top of it should do the checking that
the packets are correctly delivered and in the right order. The
introduction of an acknowledgment based mechanism should guarantee that
you don't overflow your links with packets.

If you look at a more complex transport protocol such as TCP, TCP uses a
complex algorithm and information stored in the TCP header to find out
how much data is can send at a time and when to send it and when and how
to retransmit it.

--
Stéphane

Robert Harris <(E-Mail Removed)> wrote:
> Rick Jones wrote:
>> Mauricio Tavares <(E-Mail Removed)> wrote:
>>> AFAIK, UDP by itself does not do error checking.
>> That is incorrect. UDP includes a checksum covering the data.
> And the ethernet layer checks a CRC

Yes, although hop-by-hop rather than end-to-end for UDP.

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...