[p2pi] TANA proposed charter -- packet marking question

[John Leslie <john at jlc.net>]

Stanislav Shalunov <shalunov at shlang.com> wrote:
> 
> A refreshed working copy of the draft charter...
> 
> The TANA WG is chartered to standardize a congestion control mechanism  
> that should saturate the bottleneck, maintain low delay, and yield to  
> standard TCP.
 
   Nicely stated!

   However, I wonder how many of us are on the same page when it comes
to the question of packet marking.

   Some of us quite clearly see this as a question of _how_ to use
DiffServ; others of us see this as how to _avoid_ DiffServ.

   That is not necessarily a problem...

> TANA is a transport-area WG that will focus on broadly applicable  
> techniques that allow large amounts of data to be consistently  
> transmitted without substantially affecting the delays experienced by  
> other users and applications.

   By the nature of a packet-forwarding internet, there will be delays
due to queues filling. Thus marking packets as eligible for dropping
as queues fill is a fundamental tool for controlling delay.

   In the particular cases that are driving this work, a majority of
end-systems involved will have uplink bandwidth configured to be less
than downlink bandwidth. Thus, uplink queues may tend to fill first;
and packet marking for the benefit of the first uplink router would
have an obvious payback...

> The WG will work on the following:
> 
> (1) An experimental congestion control algorithm for less-than-best- 
> effort "background" transmissions, i.e., an algorithm that attempts to  
> scavenge otherwise idle bandwidth for its transmissions in a way that  
> minimizes interference with regular best-effort traffic.

   This language calls for something other than DiffServ, which is fine
by me -- DiffServ will not always be available.

> Desired features of such an algorithm are:
> * saturate the bottleneck,
> * eliminate long standing queues and thus keep delay low when no other  
>   traffic is present,
> * quickly yield to traffic sharing the same bottleneck queue that uses  
>   standard TCP congestion control,
> * add little to the queueing delays induced by TCP traffic,
> * operate well in networks with FIFO queueing with drop-tail discipline,
> * where available, use explicit congestion notification (ECN), active  
>   queue management (AQM), and/or end-to-end differentiated services  
>   (DiffServ).

   ... which raises the question of _how_ to determine which of these
(ECN, AQM, DiffServ) are available...

   It occurs to me that for the uplink, the ISP will tend to have the
best information on which are available _and_ if several are available,
which would serve best. Thus, having the ISP provide such information
is something I wouldn't want to rule out.

   IMHO, the proposed charter is silent on that question, which is OK...

   But, this work is closely allied to the work in ALTO, which could
in principle collect such information and pass it (unevaluated) to the
p2p application. It's not instantly obvious whether the TANA and ALTO
charters allow for this, and I'd be happier if that were obvious enough
to prevent arguments after the WGs are formed.

--
John Leslie <john at jlc.net>
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi