|
|
Lars Eggert wrote:
Joe Touch wrote:
Lars Eggert wrote:
We saw the same last year, using Linux and Intel Gigabit NICs (I can
dig up exact specs on both on request.) This was during the
evaluation of the TCP "retransmit now" hack. We were kinda surprised
that such a hack apparently wasn't needed on Linux, from what we
observed in the tcpdump. Turns out that either Linux or the NIC don't
flush their respective outbound queues when the link remains down for
longer than the MSL...
As I mentioned about a year back at TSVWG, the TCP "retransmit now"
hack violates MSL limits. While Tim and Lars show that it can occur
with real systems, and others have pointed out that there's no current
way to _enforce_ it, we should discourage it.
Deliberately putting packets in with lifetimes longer than MSL can
cause connection _data_ corruption. And that's one that nothing short
of real authentication can prevent - no amount of window checking
helps if the data is in the window, but from a previous connection on
those ports.
For the record (I know I'm getting off-topic here), our "retransmit now"
hack doesn't cache/inject old packets past the MSL, that was Spencer
Dawkins' "linkup" draft. Ours triggers TCP retransmits at the end
systems when connectivity is restored, i.e., it generates "fresh"
segments. We know there are some problems with our idea, but violating
the MSL is not one of them.
That was proposed when linkup was; the largest problem I recall was
knowing the endpoint to trigger. There is current work in the DNA WG
aimed at doing this on a local system, but it's much harder - if not
impossible - to do at intermediate hops that bounce down then up.
Joe
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|