At 17:08 19.07.00 +0100, Lloyd Wood wrote:
> > Subnets that do not distinguish between delay sensitive (e.g.,
> real-time or
> > streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast)
>
>how would you recommend that such subnetworks distinguish between
>these two reliably?
Good question. The protocol-ID field in the IP header can be used as an
approximation to at least separate TCP flows from the rest. However, this
has some problems:
- IPsec overwrites the proto-ID field, and
- other reliable flows (NFS, Reliable Multicast) run on top of UDP and can
thus not be identified as reliable flows.
It would be so much better to have the old TOS definitions deployed ...
which unfortunately is not the case.
>Aren't 'delay-sensitive' and 'reliable' entirely
>orthogonal criteria?
Not when it comes to the question about how persistent link layer ARQ
should be.
> > should implement a low retransmission persistency (on the order of a
> few 10
> > milliseconds) [IS95] [GSM]. This is necessary to not interfere with the
> > delay requirements of delay sensitive flows. On the other hand,
> subnetworks
> > that are capable of separating reliable flows should implement a high
> > retransmission persistency for such flows.
>
>hey, that would really kill TCP over satellite's performance;
I don't believe that. Has it ever been shown?
>RTT
>estimates would be thrown right off.
Clearly, the measured RTT may vary more than without link layer ARQ. But
that's what it should do for such a path because it only reflects the true
RTT for sending packets reliably e2e. It will lead to a more conservative
RTO which is exactly what should happen on such a path. Also, note that the
RTO will drop quite sharply back closer to the "real RTT" after a sudden
RTT spike so it's not a real problem.
BTW, the draft's proposal to counter link outages (holding on to packets
until after the outage and then to forward them) is basically the same
thing as highly persistent link layer ARQ. That mechanism will also cause
considerable RTT spikes. I don't see a problem with that. It merely
reflects the path's properties.
///Reiner
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:24 EST