s********k
发帖数: 6180 | 1 【 以下文字转载自 EE 讨论区 】
发信人: silverhawk (silverhawk), 信区: EE
标 题: UDP能否和TCP在wireless 情况下公平分享信道资源？
发信站: BBS 未名空间站 (Thu Jun 11 15:23:54 2009, 美东)
比如802.11情况下，UDP是否一点rate control都不做，而且UDP对packet loss没有TCP
敏感。最后会不会dominate整个MAC资源？实际系统中是怎么操作的呢？ |
n********e
发帖数: 30 | 2 according to my old knowledge, the application controls UDP rate. UDP will
win against TCP.
TCP
【在 s********k 的大作中提到】
: 【 以下文字转载自 EE 讨论区 】
: 发信人: silverhawk (silverhawk), 信区: EE
: 标 题: UDP能否和TCP在wireless 情况下公平分享信道资源？
: 发信站: BBS 未名空间站 (Thu Jun 11 15:23:54 2009, 美东)
: 比如802.11情况下，UDP是否一点rate control都不做，而且UDP对packet loss没有TCP
: 敏感。最后会不会dominate整个MAC资源？实际系统中是怎么操作的呢？
|
n******t
发帖数: 4406 | 3 这个和wireless没什么关系吧。。。
TCP和UDP肯定没得抢的，如果udp想抢的话。
TCP
【在 s********k 的大作中提到】
: 【 以下文字转载自 EE 讨论区 】
: 发信人: silverhawk (silverhawk), 信区: EE
: 标 题: UDP能否和TCP在wireless 情况下公平分享信道资源？
: 发信站: BBS 未名空间站 (Thu Jun 11 15:23:54 2009, 美东)
: 比如802.11情况下，UDP是否一点rate control都不做，而且UDP对packet loss没有TCP
: 敏感。最后会不会dominate整个MAC资源？实际系统中是怎么操作的呢？
|
s********k
发帖数: 6180 | 4 那实际系统中UDP是怎么控制避免过多占用TCP带宽呢？
【在 n******t 的大作中提到】
: 这个和wireless没什么关系吧。。。
: TCP和UDP肯定没得抢的，如果udp想抢的话。
:
: TCP
|
r****o
发帖数: 1950 | 5 use TCP-friendly protocol at host side, or use packet drop/queuing mechanism
in routers.
【在 s********k 的大作中提到】
: 那实际系统中UDP是怎么控制避免过多占用TCP带宽呢？
|
z*****n
发帖数: 7639 | 6
我认为这个问题本身是个伪问题。
tcp，udp都是操作系统的不同进程下的任务。在多任务
操作系统中，各个进程被轮流调用，不管是tcp还是udp，
都是向网络层即IP deamon写入tcp或者udp包。IP的工作
方式是fifo，谁先来谁排在前面被推出去。所以，如果
你有两个进程，同时向外发送，tcp和udp的发送速率一
样，包大小一样，进程优先度一样，它们会有相同的传
输结果。
下面的链路和物理层跟这个先后次序没有任何关系。
【在 s********k 的大作中提到】
: 那实际系统中UDP是怎么控制避免过多占用TCP带宽呢？
|
z***e
发帖数: 5393 | 7 嗯，差不多是这样。
如果说实现的话，差不多是：
if (packetToSend.Protocol == UDP)
{ }
else
if (packetToSend.Protocol == TCP)
{}
这两者没有优先级。
【在 z*****n 的大作中提到】
:
: 我认为这个问题本身是个伪问题。
: tcp，udp都是操作系统的不同进程下的任务。在多任务
: 操作系统中，各个进程被轮流调用，不管是tcp还是udp，
: 都是向网络层即IP deamon写入tcp或者udp包。IP的工作
: 方式是fifo，谁先来谁排在前面被推出去。所以，如果
: 你有两个进程，同时向外发送，tcp和udp的发送速率一
: 样，包大小一样，进程优先度一样，它们会有相同的传
: 输结果。
: 下面的链路和物理层跟这个先后次序没有任何关系。
|
s********k
发帖数: 6180 | 8 那比如两个laptop同时连接到一个AP，一个发送TCP一个发送UDP，发送UDP的是怎么控
制它的速率避免完全挤占TCP的信道资源？
【在 z*****n 的大作中提到】
:
: 我认为这个问题本身是个伪问题。
: tcp，udp都是操作系统的不同进程下的任务。在多任务
: 操作系统中，各个进程被轮流调用，不管是tcp还是udp，
: 都是向网络层即IP deamon写入tcp或者udp包。IP的工作
: 方式是fifo，谁先来谁排在前面被推出去。所以，如果
: 你有两个进程，同时向外发送，tcp和udp的发送速率一
: 样，包大小一样，进程优先度一样，它们会有相同的传
: 输结果。
: 下面的链路和物理层跟这个先后次序没有任何关系。
|
z*****n
发帖数: 7639 | 9 这个跟上层是udp还是tcp完全没有关系。发udp的那个laptop在
信道竞争上没有任何优势。
【在 s********k 的大作中提到】
: 那比如两个laptop同时连接到一个AP，一个发送TCP一个发送UDP，发送UDP的是怎么控
: 制它的速率避免完全挤占TCP的信道资源？
|
s********k
发帖数: 6180 | 10 从MAC信道分配上来看，如果两者尝试发送几率相等，确实两个完全公平，但是TCP会因
为信道冲突掉包减少自己的发送窗口甚至重置为1从而减少MAC层尝试发送的概率，这样
的话UDP岂不是逐渐会dominate整个信道。TCP要想再抢回来非常困难
【在 z*****n 的大作中提到】
: 这个跟上层是udp还是tcp完全没有关系。发udp的那个laptop在
: 信道竞争上没有任何优势。
|
|
|
z*****n
发帖数: 7639 | 11 you mixed MAC layer and transport layer.
If there are two processes, 1 tcp 1 udp, they are both sending
to the network layer with same rate. How come a "channel collision"
will affect only tcp?
If the udp process keeping pushing packets to the network layer,
it will blow the IP packet buffer, not the channel. But we are
not talking that the UDP process is greedy and the tcp is not,
right?
silverhawk (silverhawk) 的大作中提到: 】 |
X*****r
发帖数: 2521 | 12 yes, he is
【在 z*****n 的大作中提到】
: you mixed MAC layer and transport layer.
: If there are two processes, 1 tcp 1 udp, they are both sending
: to the network layer with same rate. How come a "channel collision"
: will affect only tcp?
: If the udp process keeping pushing packets to the network layer,
: it will blow the IP packet buffer, not the channel. But we are
: not talking that the UDP process is greedy and the tcp is not,
: right?
: silverhawk (silverhawk) 的大作中提到: 】
|
z*****n
发帖数: 7639 | 13 In that case it is totally fair for 2 stations...
802 MAC works in such a way:
if a transmission is sensed when counting down the
backoff slots, halt the counting until the channel
is clear again.
if collision happens, double the contention window.
if a successful transmission confirmed, contention
window resets to minimum.
All the nodes have equal chance to access the channel,
no matter how many packets are pending in upper layer.
UDP
【在 s********k 的大作中提到】
: 从MAC信道分配上来看，如果两者尝试发送几率相等，确实两个完全公平，但是TCP会因
: 为信道冲突掉包减少自己的发送窗口甚至重置为1从而减少MAC层尝试发送的概率，这样
: 的话UDP岂不是逐渐会dominate整个信道。TCP要想再抢回来非常困难
|
s********k
发帖数: 6180 | 14 那这个unfairness应该准确的说是UDP相对TCP而言，那么实际系统中怎么使用UDP使得
UDP和TCP能够尽量公平？UDP是否也会做一些类似TCP的控制？一般来说怎么做的（UDP
一般没有接收端的反馈）
【在 z*****n 的大作中提到】
: In that case it is totally fair for 2 stations...
: 802 MAC works in such a way:
: if a transmission is sensed when counting down the
: backoff slots, halt the counting until the channel
: is clear again.
: if collision happens, double the contention window.
: if a successful transmission confirmed, contention
: window resets to minimum.
: All the nodes have equal chance to access the channel,
: no matter how many packets are pending in upper layer.
|
z*****n
发帖数: 7639 | 15 where is unfairness? I don't think there is any
and never said it.
UDP
【在 s********k 的大作中提到】
: 那这个unfairness应该准确的说是UDP相对TCP而言，那么实际系统中怎么使用UDP使得
: UDP和TCP能够尽量公平？UDP是否也会做一些类似TCP的控制？一般来说怎么做的（UDP
: 一般没有接收端的反馈）
|
s********k
发帖数: 6180 | 16 比如两个laptop共享一个PHY为1M的无线带宽，其中一个用UDP按照500K/s发送（buffer
无限大并且只有UDP一个session）。另外一个开TCPsession（同样buffer无限大并且只
有TCP一个session），没有RTS/CTS,其中TCP和UDP的包collision之后掉包，
congestion window 减半，或者超时之后congestion window重启，从TCP层面来看，
有效带宽（goodput）只有100K（去掉各种其他开销，比如包头的overhead）。这种情
况可能出现吗？
【在 z*****n 的大作中提到】
: where is unfairness? I don't think there is any
: and never said it.
:
: UDP
|
n********e
发帖数: 30 | 17 According to my old knowledge:
When congestion occurs:
TCP vs TCP is fair.
TCP vs UDP is not fair because UDP doesn't have congestion control. The
degree of unfairness is decided by the process that generates the UDP
datagrams.
There are many reasons for congestion. It doesn't matter the physical
network is wifi or ethernet or PPP.Even if you have super fast wifi,
congestion can still happen. |
z*****n
发帖数: 7639 | 18 I think it won't happen.
If the UDP station has a Constant Bit Rate (CBR) of 500kbps, and the
radio channel capacity is 1Mbps, then it will leave about 50% of
time that the channel is idle. Collision will not occur frequently
and both stations will stay in small contention-window state.
Even both the stations have an application layer bit rate of 1Mbps,
the channel is still fair for both of them, i.e., they will get
500kbps each. The TCP one will shrink the rate according to
the ACK arrival rate
【在 s********k 的大作中提到】
: 比如两个laptop共享一个PHY为1M的无线带宽，其中一个用UDP按照500K/s发送（buffer
: 无限大并且只有UDP一个session）。另外一个开TCPsession（同样buffer无限大并且只
: 有TCP一个session），没有RTS/CTS,其中TCP和UDP的包collision之后掉包，
: congestion window 减半，或者超时之后congestion window重启，从TCP层面来看，
: 有效带宽（goodput）只有100K（去掉各种其他开销，比如包头的overhead）。这种情
: 况可能出现吗？
|
z*****n
发帖数: 7639 | 19 TCP's congestion control will just let the process to adjust
its outgoing rate so that the congestion will be alleviated.
As long as there are outgoing message pending at the network
layer in both stations, even only one. They have equal chance
to send it. Congestion control only shrinks the window, not
pends the sending.
【在 n********e 的大作中提到】
: According to my old knowledge:
: When congestion occurs:
: TCP vs TCP is fair.
: TCP vs UDP is not fair because UDP doesn't have congestion control. The
: degree of unfairness is decided by the process that generates the UDP
: datagrams.
: There are many reasons for congestion. It doesn't matter the physical
: network is wifi or ethernet or PPP.Even if you have super fast wifi,
: congestion can still happen.
|
n******t
发帖数: 4406 | 20 UDP will win over TCP when both of them try to saturate the bandwidth. But i
f you limit the udp sending rate, this is another story.
buffer
【在 s********k 的大作中提到】
: 比如两个laptop共享一个PHY为1M的无线带宽，其中一个用UDP按照500K/s发送（buffer
: 无限大并且只有UDP一个session）。另外一个开TCPsession（同样buffer无限大并且只
: 有TCP一个session），没有RTS/CTS,其中TCP和UDP的包collision之后掉包，
: congestion window 减半，或者超时之后congestion window重启，从TCP层面来看，
: 有效带宽（goodput）只有100K（去掉各种其他开销，比如包头的overhead）。这种情
: 况可能出现吗？
|
n******t
发帖数: 4406 | 21
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So it will slow down while udp does not care.
【在 z*****n 的大作中提到】
: TCP's congestion control will just let the process to adjust
: its outgoing rate so that the congestion will be alleviated.
: As long as there are outgoing message pending at the network
: layer in both stations, even only one. They have equal chance
: to send it. Congestion control only shrinks the window, not
: pends the sending.
|
