On Fri, Jul 31, 2009 at 08:59:29AM -0400, Doug Graham wrote: > This patch seems to do the job. I applied it in a UML instance and ran > my server in that. The client is still unpatched. I see this: > > 13 2.002638 10.0.0.15 10.0.0.249 DATA (1452 bytes data) > 14 2.204041 10.0.0.249 10.0.0.15 SACK > 15 2.204090 10.0.0.15 10.0.0.249 DATA (2 bytes data) > 16 2.204428 10.0.0.249 10.0.0.15 SACK > 17 2.204822 10.0.0.249 10.0.0.15 DATA (1452 bytes data) > 18 2.204856 10.0.0.249 10.0.0.15 DATA (2 bytes data) > 19 2.204890 10.0.0.15 10.0.0.249 SACK > > So 10.0.0.249 (the patched UML server) did send back-to-back data > packets without waiting for the SACK, > > I have not applied your MTU patch yet, so the server also sent a > separate SACK immediately. This is less than ideal, since it could have > piggybacked the SACK on the second DATA fragment (frame 18), which has > lots of room. I think your MTU patch might accomplish that. Here's what it looks like after I apply your V2 MTU patch: 12 2.002750 10.0.0.15 10.0.0.249 DATA 13 2.204164 10.0.0.249 10.0.0.15 SACK 14 2.204204 10.0.0.15 10.0.0.249 DATA 15 2.204926 10.0.0.249 10.0.0.15 DATA 16 2.204950 10.0.0.249 10.0.0.15 SACK DATA 17 2.204974 10.0.0.15 10.0.0.249 SACK Starting to look pretty good! --Doug -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
