Re: Satellites running IP

[Lloyd Wood <[e-mail]>]

On Fri, 14 Jun 2002, William Ivancic wrote:

> At 08:26 PM 6/14/02 +0100, you wrote:
> >On Fri, 14 Jun 2002, William Ivancic wrote:
> >
> > > >  When rate-based, SCPS-TP is still sending TCP-style packets, so the
> > > >protocol identifier is valid.
> > >
> > > I disagree.  IMHO, one should not knowingly advertise a protocol number if
> > > one is not conforming to those protocol characteristics.
> >
> >well, that would be enough to kill pwe3 work entirely if anyone there
> >agreed with that.
>
> If I read the workings of this group correctly, it is more like gateway
> implementations were one knows the network between the gateways and is
> controlling things appropriately.

the network between those gateways is an IP cloud, with all the
possibility for reordering, jitter, loss etc. that that implies. In
particular, the timing expectations for the tunnelled protocol traffic
may be imperfectly met and outside the specification of the emulated
network and its applications - and those changes in timing form the
analogy with changes in TCP timing here.

Timing changes, but things are still made to work.


> > > IMHO, SCPS should advertise it's own protocol number when
> > > running rate-based, no congestion control.
> >
> >just so that any assumptions made by intermediate systems hold true?
> >not very e2e of you.
>
> ??? I don't understand the comment.  I'm taking SCPS-TP end-to-end, not
> SCPS-TP as a gateway.

likewise.

You stressed the importance of preserving e2e behaviour, and gave the
example of something in the middle was inspecting protocol type and
using assumptions about expected e2e bahviour for queuing behaviour at
that point. Dangerous, as you said.

(and a similar argument doesn't work for UDP, or indeed other
 protocols whose behavior is not specified as TCP's is.)


> >And I don't see
> >http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.ps
> >http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.txt
> >advocating a new protocol number either, even though it modifies the
> >congestion control mechanisms.
>
> If I interpreted the draft correctly, congestion control is still used
> here, just modified.

So how much modification do you demand before you define it as 'no
longer congestion control' and demand a new protocol type?

I've given a number of examples of modified timing where the protocol
type/identity/bits on the wire remain the same, and given the general
slackness of TCP system timers and their specification in general I
think it's a moot point.

Especially in an Internet where uncontrolled UDP traffic can run amok,
and where the same intermediate fairness/limiting/queuing mechanisms
to control such traffic can also be applied to TCP traffic. Every UDP
application behaves differently with the UDP packets it sends; every
UDP application should get its own protocol type!

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]>