Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03

[Randy Bush <[e-mail]>]

>>>>> 3. When the protocol applies fragmentation, should there be a note on
>>>>> preventing bursts?
>>>> likely part of this is our fault, as we did not mean 'fragmentation' in
>>>> the classic "oops!  we found a hop with a small mtu."
>>> I didn't take it to mean classic fragmentation but rather ALF-style
>>> operation.  Still, this could generate bursts depending on how much
>>> information there is to 'fragment'.
>> yes, it is app level framing.  perhaps we should call it that explicitly
>> or even segmentataion or some term less well known.
>> do you perhaps have a specific suggestion?
> Not really.  This all appears artificial if you need two or three
> packets for app layer fragmentation.  Maybe one could write something
> substantially improved along the lines of:
> To prevent packet bursts, a sender SHOULD pace the transmission of
> application layer fragmented data units as follows: A sender MAY
> transmit up to K packets containing fragments in a burst and SHOULD
> pace bursts ... (but how?)

ok.  i have stared at this three times today and have no bright ideas.
i do not want to start pacing by measuring rtt or other known deep
holes.  so i will try to think some more.

>>> So misconfig could be bad unless there is some delay built in.
>> so i added
>> 
>>      Although delay and jitter in responding with an OPEN were specified
>>      above, beware of load created by long strings of authentication
>>      failures and retries.
>> 
>> but i am unsure of what action to recommend.
> 
> Count to N, raise an alert, pause.  Or something like this?

    A confugurable failure count limit (default 8) SHOULD result in giving
    up on the connection attempt.

randy