Subject: RE: PILC ASYM document

From: "Falk, Aaron" <[email-masked]>
Date: Fri, 3 Mar 2000 09:03:01 -0500

Vernon wrote: 
> 
> The practice followed by Van Jacobson, Sally Floyd, and 
> others has worked
> pretty well over the years.  They do lots of simulating, 
> testing, and more
> than prototype implementing before publishing anything, or at 
> least before
> announcing solutions or proposing IETF sanctioned changes in widely
> deployed implementations.  A recent example is the change in 
> the initial
> TCP window, which was done at least partly under the auspices 
> of the TCP
> Implementors working group.  

Vernon-

You've made an excellent point. Actually, getting researchers of the caliber
you mention is part of the goals of this group. (Sally, Van: are you
listening?) However, to get networking researchers engaged in a problem
there needs to be a clear articulation of exactly what the problem is. Part
of that discussion would be to propose some candidate solutions. This is why
PILC isn't developing any protocols -- we are supposed to be bringing
together user/developer communities
_who_may_not_be_experienced_in_Internet_protocol_R_&_D_ to document the
problems they see on links of interest. One possible outcome is that an
Informational RFC is published. Getting to that point will require a rough
consensus on the issues. The dialog will likely be of greater value than the
document. These dialogs can have profound influence decisions on IETF
activities in the future.

Some might say (& I heard it about TCPSAT), that this isn't relevant work
for the IETF, since the IETF develops protocols for the Internet. My
understanding is that the IETF's charter is not quite that narrow. PILC is
doing the advance work to identify whether a new protocol(s) needs to be
developed. Part of that process is requirements definition (such as is going
on in ECM). But before you can define requirements you need agreement on
what the issues are and whether they require fixing. *That* is what we are
doing now. 

(I might add that TCPSAT was very effective in giving the satellite
community a clue on issues surrounding TCP performance. This was/is a
community where most designers didn't have a background in Internet
protocols and didn't understand the performance/design tradeoffs. To a
certain extent, PILC is a generalization of the TCPSAT goals to a wider
community of interest.)

--aaron

---

From: mukul goyal <[email-masked]>
Date: Fri, 3 Mar 2000 10:20:44 -0500 (EST)

Hi All,

THis is a diversion from the topic on hand but I am confused about the
meaning of the term "self-clocking". Recently, I posted this query on
tcpsat list and Dr. Partridge sent a reply which I am pasting below:

Date: Sat, 26 Feb 2000 16:01:55 -0500
From: Craig Partridge <[email-masked]>
To: mukul goyal <[email-masked]>
Cc: [email-masked]
Subject: Re: Lack of TCP self-clocking in practical networks 

    I feel that TCP's self-clocking as illustrated in Van Jacobson's 1988
    paper exists only if bottleneck link is a link of lower capacity (i.e.
    bandwidth) than other links. However, if bottleneck link has higher
    capacity than other links (i.e. the link is bottlenecked because a
    large number of flows are using it simulateneously), there is no
    self-clocking any more. 

I don't think it is that simple

Self clocking always occurs -- you inject a packet  in response to an ack
and the ack is telling you when the network has capacity for your new
packet.

The issue raised in your note is whether the spacing of the acks reflects
the available bandwidth at the bottleneck.  In most cases the answer is
that it reflects bandwidth only imperfectly.  Ack compression, queueing
disciplines, etc., all conspire to muddy the spacing.

Craig 

****************************************************

This gives me an impression that self-clocking refers to the property
that a new packet will be injected into the network when an old one has
left it and ACK basically conveyes this information to the sender.

Another interpretation of self-clocking that I have seen in many places
including PILC ASYM draft is that temporal spacing of ACKS reflect the
_bottleneck_ bandwidth in forward (or reverse) direction.

FInally, self-clocking might be interpreted as TCP's property that
temporal spacing of ACKs reflect _available_ bandwidth at bottleneck for a
flow. (I know that this is not true.)

I would like to know what is the accepted definition of Self-Clocking and
if some IETF document talks about it.

It might be a good idea to have a document that lists accepted definition
of concepts like this.

Thanks,
Mukul