Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying NewCongestion Control Algorithms) to BCP

From: "todd glassey" <[email-masked]>
Date: Mon, 4 Jun 2007 08:40:51 -0700

----- Original Message ----- 
From: "Erblichs" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Pekka Savola" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 30, 2007 4:46 PM
Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying 
NewCongestion Control Algorithms) to BCP

> Mark Allamn,
>
> I always have a "internal fight" when I read these
> documents as whether they are meant as a BCP type
> document or...
>
> So, if I can add my thoughts..
>
> 1) Architecture design and implementation can be two completely
>    different items for acceptance criteria. Thus, I might propose
>    the floowing items:
>
>   - two or more implimentations using a new alternate cc algorithm
>     could be used as interoperability against each other and another
>     cc algor..

As long as they both use the same CC Alg's then this is OK...

>
>   - if possible, a Linux, xBSD, etc public reference should be
>     available,

This isnt relevant to the Standard Process from the IETF but rather in how 
its used.

>
>   - experiences using the new cc algorithm should be available,

You mean like formal testing or 'use reports' from those involved with the 
Standards Process?

>
>   - ALL new CC algorithms SHOULD pass through a preliminary
>     experimental stage..

This means that any implementations that used those Alg's would also be 
'Experimental' in nature - how does that fit in with the above rule you 
proposed on 'that there must be two implementations' - certainly when there 
is more than one implementation done, that would qualify the protocol as 
"implemented" and not "experimental" in nature.

>
>
> 2) What is the expected consequences if a private entitity
>    implements a private/IP CC algorithm that is unfair, etc..

This is a political issue and would embroil the IETF in actions which can 
get the IETF and those involved sued. I would suggest that there is nothing 
to say about private entities actions here.

>
> 3) Classification (ordering) of a CC algorithm that is used
>    as a TCP option, so two endpoints can determine which
>    CC algorithm is used at each endpoint,

I suggested this to PKIX as part of a "policy negotiation and selection 
process" and was slammed for it.

>
>
> 4) Support for a CC algorithm in one environment, ie LFN..
>
> 5) Well known TCP CC algorithms that may use non-standard options:
> ie: 10 Dup-ACKs for a fast re-xmit..
>
> 6) Specifiying a minimum inter-packet gap based on recent history
>    to minimize ANY CC alg from implmenting say a 100 seg burst,
>    from a non-slow start re-start...
>
> Mitchell Erblich
> -----------------
>
>
> Mark Allman wrote:
>>
>> >      For other guidelines, i.e., (2), (5), (6), and (7), the author
>> >      must perform the suggested evaluations and provide recommended
>> >      analysis.  Evidence that
>> >      the proposed mechanism has significantly more problems than those 
>> > of
>> >      TCP should be a cause for concern in approval for widespread
>> >      deployment in the global Internet.
>>
>> Looks OK to me.  I have incorporated it, modulo comments from Sally.
>>
>> As for the non-BE stuff: This document is a no-op.  But, why is that an
>> issue?  The IETF would have to grapple with the non-BE case just as it
>> does today (i.e., without a set of guidelines).  This one document does
>> not need to solve all the world's problems.  If you want to write a
>> document about how the IETF should handle non-BE congestion control
>> proposals, I think that'd be fine.  And, again, I am not hearing outcry
>> on this point so I think the document is fine (even if the consensus on
>> this one point is not completely 'smooth').
>>
>> Thanks,
>> allman
>>
>>   ------------------------------------------------------------------------
>>    Part 1.2Type: application/pgp-signature
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf