|
|||||||||||
|
[IMRG] Re: [e2e] TCP Traffic Measurement Studies
From: Filipe Abrantes <fla(at)inescporto.pt>
Date: Fri Jan 20 2006 - 09:59:04 EST Hello Detlef, Vijay, all: (Inline)
Detlef Bosau wrote:
>>On Sat, 24 Dec 2005, Detlef Bosau wrote: >> >> >>>Vijay Erramilli wrote: >>> >>> >>>>I am trying to get a sense of what typical ratios of forward/reverse >>>>byte traffic is in TCP. This will of course vary depending on the >>> >>>Is there a reason why this should be different from two simplex >>>connections, at least as long as there is no asymmetric bandwidth / load >>>somehwere in the network? >> >>shared media - traditional Ethernet (now rare),> > However, I think Vijay´s question was more related to the transport > layer. > > And I don´t see a "pure L4" reason for different throughput in both > directions of a TCP connection. Well, the loss of an ACK pkt is forgotten by receiving the subsequent ACK, while the loss of a data pkt cannot be forgotten - it always halves the cwnd. This means that if the bottleneck queue is in the downlink, uploads will not slow down (because only some of their ACKs are lost), while downloads do slowdown (because these flows lose data pkts). This might be OK in duplex links, but in shared-media (and non-duplex imagine 802.11) this causes the starvation of downloads when the media reaches saturation (this can only happen if the "next" link has higher capacity than the shared media). Well, at least this is what I could experience through some simulations, I need to check if real-world TCP implementations also ignore ACK losses if they receive an higher seqno ACK pkt. Does this make sense? I could share a simulation script that shows this phenomenon. Filipe >
-- Filipe Lameiro Abrantes INESC Porto Campus da FEUP Rua Dr. Roberto Frias, 378 4200-465 Porto Portugal Phone: +351 22 209 4266 E-mail: fla@inescporto.pt _______________________________________________ IMRG mailing list IMRG@ietf.org https://www1.ietf.org/mailman/listinfo/imrgReceived on Fri Jan 20 10:58:34 2006 This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:43:04 EDT |
||||||||||
|
|||||||||||