Sorry, I am way behind.
> IMO if you want to follow the true spirit of RFC3390 and RFC2581 then
> yes.. you should ONLY use RFC3390 (or 2581) to set your initial
> cwnd.
>
> I am adding Mark Allman on this to get his opinion.. Mark, here
> is your big chance to chime in on
(1) We have released some traces from LBNL at:
http://www.icir.org/enterprise-tracing/
(2) See datcat.org for an index.
(3) The CRAWDAD traces from:
http://crawdad.cs.dartmouth.edu/
allman
pgpk1PAPx7ern.pgp
Description: PGP signature
> That sounds like an option... but is it worth it? Can you give us
> access to your testbench that shows eifel to be an important
> improvement over the current eifel-less stack we have right now? My
> guess is that SACK nullified most of eifel's importance.
SACK doesn't help in the domain whe
n internet-draft (and, in fact, needs rev-ed
because we have a better idea in mind):
Josh Blanton, Ethan Blanton, Mark Allman. Using Spurious
Retransmissions to Adapt the Retransmission Timeout. December
2006. Internet-Draft draft-allman-rto-backoff-04.txt (work in
progress).
The probl
> I know there is some relationship between the packet size and the TCP
> throughput. But what if two TCP Sack flows have the same MTU size,
> but different header size (hence different payload size) ? Is there
> any work that model this issue before?
Yeah ... the TCP model that Padhye, et.al. w
Bruce-
> > Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of
> > Transport Protocols in the Internet. ACM Computer Communication
> > Review, 35(2), April 2005.
> > http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
>
> What a trip,
quite widely deployed. See:
Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of
Transport Protocols in the Internet. ACM Computer Communication
Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
allman
pgpEhv9cl87Vx.pgp
Description: PGP signature
> Actually, TCP is a single sliding window protocol, which limits its
> performance on seriously lossy and long delay transmission media.
> We assume that a sender has sent packets [A] [B] [C] [D] [E] while
> the receiver has received packets [A] [C] [E]. With TCP the receiver can
> only
> 1. Receiver should tell sender to re-send as soon as possible.
>(But TCP makes receiver purely passive)
This isn't really going to help you at all. With SACK (especially, but
even without it) the receiver isn't really in a whole lot better
position than the sender to judge when a packet is
>
> > You can take a look at SCPS - http://www.scps.org/ Their protocol is
> > used on lossy links with big latency and packet loss (such as
> > satellites) and overcomes shortcomings of TCP. It works with divert
> > mechanism of FreeBSD and I ported the tap device part as well to both
> > NetBSD
> You can take a look at SCPS - http://www.scps.org/ Their protocol is
> used on lossy links with big latency and packet loss (such as
> satellites) and overcomes shortcomings of TCP. It works with divert
> mechanism of FreeBSD and I ported the tap device part as well to both
> NetBSD / FreeBSD (
> Its capture file editor, bittwiste, allow you to change most fields
> in Ethernet, ARP, IP, ICMP, TCP, and UDP headers and you can specify
> your own payload. It is possible for the payload to cover the ICMP,
> TCP, or UDP header itself (checksum is corrected
> automatically). Tcprewri
are some
measurements given in:
Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of
Transport Protocols in the Internet. ACM Computer Communication
Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr2005.ps
Also, I think there is wide community consensus th
don't suppose this is the problem (since it's
freebsd everywhere, right?). But, while folks are messing about in the
SACK code this RFC might be something to think about including.
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
pgptnfSZiNJEp.pgp
Description: PGP signature
e retransmitted.
I do not understand why receiving 3 dupacks would cause a retransmit of
3 segments. One retransmit I can understand. But, then we shouldn't be
in packet conservation for a bit while some of the segments drain from
the network to effectively halve the sending rate (because w
tial for increased burstiness.
We don't think this is a terribly big deal. We have recent results that
say that small scale bursting doesn't hurt the connection all that
much. See:
Ethan Blanton, Mark Allman. On the Impact of Bursting on TCP
Performance. Proceedings of the Workshop f
Folks-
> > The SYN side of the equation, however, is a bit more tricky. The
> > proposed RFC recommends ACKing SYN packets in the window, just like
> > we do to SYN packets to the left of the window right now.
> >
> > For the life of me, I can't figure out why SYN packets (other than
> > delaye
ackets left of the window will no longer receive an ACK, and
> SYN packets in the window will no longer reset the connection. In
> all states other than ESTABLISHED, SYN packets are handled as they
> were before, in case there's some edge case where that could happen.
This sounds OK
st) and work to get it "productionized" (even though I don't
> feel it needs much work in this vein)...
I do not prefer xor.
I agree that it'd be nice if SCTP was rolled into freebsd. But, these
things seem orthogonal to me.
allman
--
Mark Allman -- ICIR -- http://www.ic
efully this will happen in a couple weeks
-- right after i-d submission opens after the IETF meeting in DC.)
Thanks,
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
pgp7YunUyjNtW.pgp
Description: PGP signature
uot; data --- i.e., send it and then decide
that you don't really care if it gets across the network (say, because
it got lost and has taken too long to retransmit and so the data is out
of date). Without a Big Hack, I cannot envision TCP doing something
like this. What am I missing?
Th
> Sure. To make you sleep better it will be disabled by default (like
> T/TCP) and possibly even not compliled in by default (#ifdef'd).
Part of your argument against T/TCP. :-)
> A writeup will follow once I get there. I made this request before I
> start working on it to prevent to waste my
t;Make Sense" often don't and
likely would have benefitted by a bit more thought and a bit more
vetting. I would be happier if something like this were vetted out a
bit more (written up, digested by folks, etc.) before it went into
anything but someone's experimental kernel. Just my two
> On Wed, Mar 10, 2004 at 02:38:40PM -0500, Mark Allman wrote:
> > > I looked for the paper I paraphrased, I'm pretty sure if was one by
> > > Sally Floyd.
> >
> > I don't have the paper reference handy, but it's Sally's HighSpeed TCP
>
er
you employ SACK. (The world would be worse than described above if you
didn't use SACK. But, if you have to take at most one loss every 100
minutes that's pretty bad already.)
There is an experimental change to TCP's algorithms specified in
RFC3649 (that only applies when you a
(And, I'll plug RFC3517 as a very heavily vetted method for
using SACK information. I am probably biased. But, I think it is very
nice. I have grown to like it more and more since it was published.
Its robustness keep surprising me!)
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
pgp0.pgp
Description: PGP signature
rt is that you need a new data structure (a
scoreboard) to track the peer's status if you're going to do something
intelligent (e.g., rfc3517) with the information you're being sent.
And, you have to add hooks to update the scoreboard, consult it when
sending, consult it when making c
company
can say "we'll throw 5K in if you get committments for the 50K you need
to make X happen". It might be worth the modest investment to setup
something like that and keep it maintained. That way it's a bit more
official than some random person running around and try
o figure out what to do to all the connections
when there is not enough memory for such socket buffer sizes.
But, fundementally, that seems like a much better approach to me.
And, thanks for taking this all on! It sounds wonderful!
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
ne, I think.). Any thoughts in this area?
Thanks!
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
I
think it would be nice if that were fixed.
Back to the drawing board... (Joe is digging through the TCP code
and chasing a couple of things.)
Thanks again!
allman
--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &
oking?
Thanks!
allman
--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
uld indicate
that either we should continue slow start (exponential cwnd growth)
or stop growing cwnd when we hit the advertised window. But, we do
neither of these. At some point the cwnd just stops growing -- even
though we have plenty of advertised window left and no loss.
Hm.
allman
--
Mark All
> > From: Mark Allman [mailto:mallman@;grc.nasa.gov]
> > Thanks! Other ideas?
>
> What MSS is advertised on each end?
1500 byte packets (from looking at the trace file).
allman
--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
To Unsubscribe: s
equest. All looks fine.
Thanks! Other ideas?
allman
--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
35 matches
Mail list logo
