|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Gont wrote:
> At 22:27 07/04/2005 -0700, Joe Touch wrote:
>
>> > Well, I think this is an issue in which we clearly disagree.
>> > The point is that if your data gets acked, it is getting to the remote
>> > endpoint, so you can still communicate with your peer, and thus there's
>> > no reason for which the connection should be aborted.
>>
>> There is no indication of that anywhere in 792 or 1122 - i.e., no
>> indication that you should ignore single ICMP errors, since
>> retransmissions on alternate paths might get through.
>
>
> While I agree this is not explicitly stated, the idea of aborting a TCP
> connection upon receipt of a hard error is based on the assumption that
> the error condition will remain over and over again.
That is an assumption of your approach, but not the reason for the
abort, as per below.
> From the point of view of the transport protocol, you don't care what
> path your packets take, but whether you make progress, or not.
YOU care whether you make progress; it's very clear that if progress
were the criteria, then single ICMP errors wouldn't be considered hard
errors. 792 and 1122 would discuss accumulation of such errors and
threshholds, even in general terms, but they do not.
> Aborting a connection because packets cannot get to the remote endpoint
> through a *specific* path (packets *do* get to the remote endpoint
> through some other path) would not make sense, IMHO.
>
>> I.e., if the
>> intent is to allow connections to proceed if they can, even in the
>> presence of ICMP errors, we need to revisit all ICMP processing, even
>> when in-window.
>
> Not sure what you mean by "even when in window".
Inside the window you are checking (sender unacknowledged). I.e.., just
because the ICMP is inside the unack'd window doesn't mean the
connection has ceased to make progress. You would need to wait to see if
progress continued; if so, then ignore the abort. Given that
requirement, there is no need to check the seq number at all.
I.e., is this about 'ceasing to make progress' (which it does not test)
or trying to infer an attack (which it gives false positives for
multipath, and won't detect on-path anyway)?
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVqMJE5f5cImnZrsRAhHoAKDjOIwvLrrnGmBvW5wBcSgDrMp38wCgju8a
xK890Xd32J815vuWhYgPf7U=
=D9Ho
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|