Andrei-
I think your suggestions are good ones.
> For 2.5g/3g my suggestion is to
> add it to the paragraph of section 2 that also mentions other possible
> reasons of delay spikes (link outages, handovers, priority blocking).
Yes. IMO, we should find a way to make 2.5g3g representative of as large
a set of service provider links as reasonable. I'd like to see some draft
text on this.
> Avoiding unnecessary retransmissions when delay spikes occur can be done
> ... by implementing some response method to avoid unnecessary
> retransmissions when detecting a spurious RTO. There is some on-going
> work on these.
Can you clafify or provide references? Are you talking about using a
control channel or heuristics to notify stacks that link characteristics
have changed? If so, this might be too large a topic to squeeze into
2.5g3g. But it is still interesting.
> What could be the contribution to the LINK document? Since this method of
> radio resource allocation seem to cause problems for TCPs, then the link
> designers should avoid it or at least use the parameters that minimize the
> delay spike and bandwidth oscillation?
There is a rather weak section on Bandwidth on Demand in LINK (I wrote it a
couple years and a couple employers ago). This is really the issue it
should be dealing with. Some proposed text to replace or enhance that
would be good as well. The current text is more descriptive regarding
mechanisms for managing BoD and only hints at interactions with TCP. But,
again, this should be in summary form. A seperate document might be good,
as we did for ASYM, if there's some meat here.
We'll have time on the agenda in SLC to discuss this further.
--aaron
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST