Why do we have or should have keep-alive packets?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This email is to start a discussion on the use and requirements for protocol
keep-alive packets in DCCP. This is a follow-up to discussing the RTP/DCCP
draft.

A keep-alive packet is defined here as a packet that is sent when the
protocol has no data to send. Such packets provide no specific protocol
function, except to indicate that the protocol end points still have
protocol state.

The notes below capture some of the ideas inspired by the DCCP WG meeting in
Prague. Please add more ideas and thoughts...

1. Uses of Keep-Alive at the Network Layer:
    a) To refresh network-layer soft state (e.g. NAT, Firewall pinholes)

2. Uses of Keep-Alive at the Transport Layer:
    a) To verify network path (rtt change, loss indication)
        - to modify congestion parameters.
    b) To verify remote reachability (end host transport still there?)
        - to terminate/reset connection.
    c) To verify transport state (application died? no loss?)
        - to retransmit or reset peer lost protocol state.

3. Uses of Keep-Alive at the Application Layer:
    a) To verify receiver state (socket open, application died?)
        - to terminate/reset connection.
    b) To verify network path (path changed?)
        - to modify flow-control/session parameters.

Do these lists have missing things, how clear is the suggested separation in
functions between the two layers?

How often should we probe in this way?

Thoughts and comments are welcome!

Gorry


    




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux