Aaron-
> > 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.
In that case Farid would be the best source of this text?
>
> > 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.
I mostly meant our joint work with Reiner. A technical report on some
fixes to the retransmit timer will be available shortly. Later, possibly
a draft based on this report and the draft that specifies Eifel response
to spurious timeouts.
>
>
> > 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.
I think BoD text in LINK is quite informative. It's a nice idea to have a
separate document on this, if there are people interested in contributing.
>
> We'll have time on the agenda in SLC to discuss this further.
>
> --aaron
>
-- Andrei
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST