At 06:06 16/02/2005 -0800, Joe Touch wrote:
>> >> Sure (we're still talking about non-malicious routers for this case).
>> >> However, that's not to say it won't shift sufficiently that the sent
>> >> ICMP will be outside the receive window (it may not wrap, but it may
>> >> shift enough that you can't use the 'window' to check it).
>> > And what's the problem with this? ICMP is not reliable, after all.
>> If the ICMP source is sufficiently out of sync, it will always generate
>> ICMPs that end up outside the window. Not reliable != never works.
> I disagree.
> You assume that TCP window will move, when it won't.
Why not? what if packets find another path?
If packets find another path and there's progress on the conenction, it
means that the connectivity problem being reported by those ICMP error
messages is not true anymore... so why would you abort the corresponding
connection, lower the PMTU, or whatever?
It would be extremely nonsensical to do so.
> The ICMP source can't be "sufficiently out of sync". Think about ICMP
> "don't fragment", for example. When a segment elicits an ICMP don't
> frgament, that segment will be dropped. Thus, the window won't move,
> regardless of how long the network queues the ICMP packet. By the time
> it arrive (whenever), it will be "in window" (considered to be "in
> flight" to destination).
> The same thing applies to other errors.
> Porbably the only ICMP error message that could get out of sync are
> ICMP Source Quench, as, IIRC, a router may send an ICMP Source Quench
> without dropping the packet that elicited it.
> And use of ICMP Source Quench is deprecated in the IETF specs themselves.
Any ICMP message can get out of sync if packets are duplicated (which
they are) and multipath occurs.
Again, I disagree (for the reasons stated above and in other e-mails).
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
tcpm mailing list